The officially official Devuan Forum!

You are not logged in.

#1 Re: ARM Builds » [SOLVED] Apt demands armmp dependencies in place of RPi kernel images. » 2022-09-22 20:00:32

The kernels used by the Devuan Pi Images are built from source, pulled from the Foundation github. The only changes I make to the build is a few modules ticked on here or there. Sometimes by request. The major difference between these builds and say a typical pi or debian kernel package, is we are using custom packaging. What the post and pre scripts of the deb package does during the install. Things like this.

What the wireguard package is trying to do is beyond my control and yes, these kernels support wireguard out of the box. My guess would be that Bullseye/Chimaera's default kernel doesn't have built in wireguard support, so the default packaging for this is pulling in garbage not needed in this use case.

Speaking of packaging. I have some thoughts on changing it, which would provide optional UEFI / Grub support for future PI images. Unfortunately the change would also render kernel upgrades on current Chimaera images not supported due to the changes.

The new boot layout would be as such and would come with a "use if you want too" u-boot.bin. This would support arm64, as well as arm to a degree.

 Devuan GNU/Linux 4 (chimaera) 5.15.68 #1 Tue Sep 20 22:07:00 EDT 2022 aarch64

                                            Raspberry Pi 3 Model B Plus Rev 1.3

== DISK
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2   30G  1.0G   28G   4% /
/dev/mmcblk0p1  253M   72M  182M  29% /boot/efi

== NETWORK
Hostname:    raspberrypi
Wireless:    wlan0 UP 10.0.0.98 

== SYSTEM
Processor:   Cortex-A53 @ 1400MHz 45.6°C
Governor:    performance
Memory:      910M 76M
Entropy:     256
Uptime:      21:01:20 up 6 min, 0 users, load average: 0.00, 0.05, 0.02

Last login: Thu Sep 22 20:57:51 2022 from 10.0.0.252
patrick@raspberrypi:~$ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk0     179:0    0 29.7G  0 disk 
├─mmcblk0p1 179:1    0  253M  0 part /boot/efi
└─mmcblk0p2 179:2    0 29.5G  0 part /
zram0       254:0    0    1G  0 disk [SWAP]
patrick@raspberrypi:~$ sudo blkid
/dev/mmcblk0p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI" LABEL="EFI" UUID="E7A2-D2DC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="81fee591-01"
/dev/mmcblk0p2: LABEL="ROOTFS" UUID="3120022f-ddcc-40d3-85f8-5c598f5e6ee4" UUID_SUB="f4c78c7d-9cd5-42a9-8729-1d21709cb0c9" BLOCK_SIZE="4096" TYPE="btrfs" PARTUUID="81fee591-02"
/dev/zram0: UUID="c29fee97-5599-47cf-9db5-54fcc1790ed4" TYPE="swap"
patrick@raspberrypi:~$ ls /boot
config-5.15.68  grub   initrd.gz           System.map-5.15.68
efi             Image  initrd.img-5.15.68  vmlinuz-5.15.68
patrick@raspberrypi:~$ ls /boot/efi
bcm2710-rpi-2-b.dtb       cmdline.txt    fixup_x.dat       start_db.elf
bcm2710-rpi-3-b.dtb       config.txt     Image             start.elf
bcm2710-rpi-3-b-plus.dtb  COPYING.linux  initrd.gz         start_x.elf
bcm2710-rpi-cm3.dtb       EFI            kernel8.img       u-boot.bin
bcm2710-rpi-zero-2.dtb    fixup_cd.dat   LICENCE.broadcom
bcm2710-rpi-zero-2-w.dtb  fixup.dat      overlays
bootcode.bin              fixup_db.dat   start_cd.elf
patrick@raspberrypi:~$ ls /boot/efi/EFI/BOOT
BOOTAA64.EFI

By editing the /boot/efi/config.txt, one could enable uefi support "grub".

kernel=u-boot.bin

If its not enabled, the boards just boot as normal.

#2 Re: ARM Builds » [SOLVED] Pi Zero - No output on hdmi. » 2022-09-16 20:19:27

That's a pretty old image, so i'm not going to pretend to know whats going on with it. You could try messing with some of these rpi specific options: https://www.raspberrypi.com/documentati … figuration

I just spun this and tested it (worked fine for me): https://github.com/pyavitz/rpi-img-buil … -16.img.xz
First boot and general usage: https://github.com/pyavitz/rpi-img-builder#usage

I also included a default passwd for root: toor

#3 Re: ARM Builds » [RPI2] SSH through Android Mobile Hotspot » 2022-09-08 23:01:28

SSH is enabled out of the box. I would 'think?' this is possible if the computer you are using is also on the same hotspot as the Pi. I'm able to ssh into devices on the local network using Android as long as I'm connected to wifi, so it should be doable the other way around as well.

#4 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2022-04-24 15:26:52

alimoche wrote:

the kernel is very modular it will only load the drivers for your SBC, the netboot installer was working very well except it stopped at the error message with a no matching kernel (version 5.10.70-1 used by the current installer image might have been removed for chimaera repositories?). How to build a netboot image for an unsupported SBC in devuan  is described at the end of the README file, it might work if there is a specific device tree for your SBC, see e.g. https://pkgmaster.devuan.org/devuan/dis … vice-tree/, so the problem reduces to build and configure u-boot which is far easier than making a custom kernel and to build a custom image for the whole distribution for every SBC

Not gonna disagree. Would be easier.

#5 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2022-04-24 00:17:24

U-Boot is diff for every board, so I'm not sure how that's really doable, but if it works for you, have at it.

As for kernels than sure... Someone could make a super bloated kernel for just about all the SoCs and have them run some what OK. But even that depending on the SoC would not be a great idea.

#6 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2022-04-23 21:57:30

if you feel like putting in the effort you can build an OrangePi PC img for Devuan here: -> https://github.com/pyavitz/debian-image-builder

#7 Re: ARM Builds » Any Chimaera Rpi3/4 builds in the pipeline? » 2022-03-29 13:56:23

For whatever reason that version of Chromium is broken and has been for months. I believe its actually missing depends.

I've been using the following:

chromium_90.0.4430.212-1_arm64.deb
chromium-common_90.0.4430.212-1_arm64.deb
chromium-sandbox_90.0.4430.212-1_arm64.deb

You can find them here

#8 Re: ARM Builds » [Raspberry Pi 400] Why is wifi interface named wlan1 on the Pi400? » 2021-11-25 23:41:09

Well if you were using systemd you could just add net.ifnames=0 to the cmdline. But as this isn't an option on Devuan, you would need to play around with the udev rules.

sudo tee /etc/udev/rules.d/80-net-setup-link.rules <<EOF

SUBSYSTEM!="net", GOTO="net_setup_link_end"

IMPORT{builtin}="path_id"

ACTION!="add", GOTO="net_setup_link_end"

# IMPORT{builtin}="net_setup_link"

NAME=="", ENV{ID_NET_NAME}!="", NAME="wlan0"

LABEL="net_setup_link_end"
EOF

I use a rule like this to insure the ethernet interface comes up as eth0 on Pi3's.

#9 Re: ARM Builds » Any Chimaera Rpi3/4 builds in the pipeline? » 2021-11-13 14:24:35

The builders have now been updated to work on both Debian and Ubuntu. Although I haven't added Devuan as a supported Distro, I see no reason why reviewing the package list and installing manually wouldn't work.

https://github.com/pyavitz/rpi-img-builder
https://github.com/pyavitz/debian-image-builder

Cheers

#10 Re: ARM Builds » Any Chimaera Rpi3/4 builds in the pipeline? » 2021-11-03 13:43:41

batmore wrote:

>They need testing: https://github.com/pyavitz/binary/releases/tag/images

Here to tell you that the  rpi-devuan-chimaera-5.10.76-ext4-2021-10-30.img.xz  image worked a charm for my RaspberryPi Zero W stick.
I had to comment out the hardline lan eth0 stanza before the wifi worked, but after that it worked well.
Kudos to you on providing those images. Thanks much.

I tried your rpi-img-builder, but it refused to install/run on my Ceres box, said 'The OS you are running is not supported'.   
I'll install Chimaera and try again.  I'd be good to generate my own images with your tool to help.

I'm not sure why eth0 would be interfering with it, considering it doesn't have an ethernet port, but I'm happy you got it working.

As for the builder, because of the different versions of GCC and compilers it currently supports and will support in the future, I ended up moving it over to Ubuntu as the Host. Debian and Devuan stable for example only support GCC-9/10. The builder currently supports GCC-8/9/10 and by the start of next year will also support GCC-11 and CLang-13. Basically, Ubuntu unfortunately provides more options.

If need be docker is an option?

You can also install depends manually on Debian and Devuan, but just know certain options won't be available to you. Such as Clang and anything gcc-8 related if building on Bullseye or Chimaera.

#11 Re: ARM Builds » Any Chimaera Rpi3/4 builds in the pipeline? » 2021-10-31 15:11:25

They need testing: https://github.com/pyavitz/binary/releases/tag/images

I also included support for the Zero 2 W, but as I don't own the board yet, I'm not sure it boots and if it does, how well it works.

#12 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2021-10-29 16:42:15

att2 wrote:

Well, that is my problem, because, on the officially supported Ubuntu image, these overlays do exist, and I have them in my "config.ini" file, and they work neatly ; but Ubuntu is booting terribly slow. Any recommendations of what, exactly, to do to get these overlays working in Devuan?

My suggestion would be to ask tobetter if he could please include the said overlays. I've only chit-chatted with him a few times concerning problems in the linux source, but he has always been really kind and receptive. He does include them for the Odroid N2/+ so i don't see why it would be that much of a stretch?

tobetter --> https://github.com/tobetter/linux

#13 Re: ARM Builds » Installer images for armel, armhf and ppc64 need testing » 2021-10-26 19:51:33

Is it possible to install Devuan on a Odroid C4 and use the tobetter kernel source which includes the overlays, yes. But I don't see all the overlays you are asking about?

ls /usr/lib/meson*/amlogic/overlays/odroidc4
hifishield2.dtbo  hktft35.dtbo  spi0.dtbo         w1-gpio_p15.dtbo
hktft32.dtbo      pcf8563.dtbo  sx865x-i2c1.dtbo  w1-gpio_p22.dtbo

Also the current imgs I build use extlinux and although it does have overlay support now, I have personally never tried to use it.

#14 Re: ARM Builds » Beowulf 3.1.0 arm64 rpi4 image fails to boot on recent RPI4 » 2021-10-05 16:28:01

The image you are using was made with the following builder: https://github.com/pyavitz/rpi-img-builder

I've made lots of changes to the builder since that img was created, one of those changes is in relation to firmware, how its installed and where its located. I don't use the firmware provided by Debian, Devuan or Ubuntu as its usually outdated and incomplete.

The firmware used --> https://github.com/pyavitz/firmware
The firmware function --> https://github.com/pyavitz/rpi-img-buil … ersal#L291
The line now added to the /boot/cmdline.txt --> firmware_class.path=/lib/firmware/updates/brcm

The script used to update kernels, firmware and userland: fetch -h

The gist of it in my opinion is that the imgs on the site need to be updated. I have no access and did not make those imgs myself, so there isn't anything I can do except point out the problem.

The reason the deb install is failing is because the firmware wasn't installed using apt, so you would need to remove the firmware by hand and then run the apt install.

#15 Re: ARM Builds » Beowulf 3.1.0 arm64 rpi4 image fails to boot on recent RPI4 » 2021-10-03 17:45:13

Why a 2GB model wouldn't boot I don't know, but as for the firmware error?

As for why it hit an error is due to the fact the firmware is already in place and apt doesn't like to replace files that it didn't install its self.

#16 Re: ARM Builds » Any Chimaera Rpi3/4 builds in the pipeline? » 2021-09-20 18:01:48

Assuming you have a Pi4 and an extra SDCARD you can produce them yourself without much effort.

Go here, download the pre-made Hirsute IMG and write it to said SD. From there follow the instructions on the README.

When creating an IMG you have 3 options, but only two will probably be of interest. That being make config and make admin, depending on which you choose, fill in the information of choice and create the userdata file.

You can speed up the process by pulling a pre-made kernel, using make helper.

So for example, if you wanted a quick rpi4 img... Create the userdata file and run: make 2711; make rootfs; make image

I'm not in the know of when there will be an official release, plus I'm still waiting to find out what the official sources.list file will look like.

#18 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 17:33:49

You are missing the point.

Device Tree files
There are various Device Tree blob files, which have the extension .dtb. These contain the hardware definitions of the various models of Raspberry Pi, and are used on boot to set up the kernel according to which Pi model is detected.

https://www.raspberrypi.org/documentati … _folder.md

The keyword here is: Detected.

The DTB file should not be defined, as the bootloader detects which version of the pi and loads it accordingly. You can however define it inside the /boot/config.txt file, but that is usually only done if it's not in its default location or someone is using a custom DTB. Either way, this is done during the normal boot process of the Pi and has nothing to do with u-boot ==> {boot.scr,extlinux,grub}

So the problem still becomes, how does each kernel know which DTB to load if it is not definable when using u-boot and only takes place after the fact? I believe you had mentioned before that it may be/is possible for grub to copy the correct dtb into place during the boot process and if so I assume this would be doable. But then we still have the problem of Kernel packaging, which at this time isn't suitable.

You are more than welcome to work out the logistical elements of this and contribute if you wanna make this happen. You can find me on irc @ libera: #devuan-arm or #arm-img-builder

#19 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 13:25:17

On other SoCs the device tree blob/binary needs to be loaded with the kernel in Extlinux and is defined by using

fdtdir /location

and

fdt /location/file

but on the PI this can't been done. Not sure why Grub would be able to handle this, but ok? I'll read over ur post further when I have some time.

#20 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 03:07:45

So if I'm reading that correctly it depends highly on kernel packaging, yes? I believe I've already went over this and suggested that the current packaging isn't adequate. It simply isn't suitable for multi kernel boot and I never set it up to do so.

#21 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 02:52:06

Extlinux can load device-trees. It is the next stage of the bootloader on the Pi that gets confused, which is really just the first stage. That's the So what? As you so finely put it.

If you've had it working for 6 months why are you keeping it a secret and being a jerk about it here? Why not just contribute?

#22 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 02:26:45

ehem

Lets say we use u-boot. The DTB file can't be defined in extlinux, as the next stage of the bootloader will get confused and at worst not boot at all. If it did boot by chance, it would be all out of whack and certain onboard things wouldn't work. How do I know this? I've experimented with it smile

Your hate of the device-tree doesn't change how the bootloader works. In all honesty it would probs be easier to get a multi OS boot before a multi kernel boot on the same medium.

As for the device-tree, its essential. There are no if and or buts about it. This is not your Dads x86 computer smile Not all DTB files are gonna support the next kernel exactly the same and there isn't much any of us can do about it and unfortunately defining that DTB using extlinux and or grub is gonna create a headache in the boot process.

Of course, I'm just going on my own testing. I welcome you to play with it and see if you can get further.

Edit:
I'll extend an olive branch. How would one define which DTB to use for each kernel, if the DTB is undefinable?

#23 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-27 01:20:50

ehem wrote:
c0rnelius wrote:
ehem wrote:

You use U-Boot's UEFI support to have it load GRUB (SuSE uses this approach).  While wasteful due to having an extra bootloader stage, you gain GRUB's massively better functionality.

You aren't taking under account kernel packaging and the problems therein. Not to mention overlays and whatnots are gonna be different between kernel revisions, so now that would also need to be taken under consideration. Grub would also need to be scripted to know what to look for, which presents even more headaches.

Even other SBCs that use grub aren't trying to boot more than one kernel, as there is a lot of things to account for. But hey, if you feel like looking into it and investing the time and effort to make it work, go for it.

There was some discussion on Debian bug #824954.  Some of the necessary scripting can be found as GRUB wishlist #52939.

This though is only needed for covering the most extreme case, where GRUB needs to load a kernel-specific device-tree.  This isn't needed if you're switching between kernel patch levels, which is adequate if you're switching between 5.10.0-1 and 5.10.0-2 (which would be security update versions).  This is also overkill if you're simply rebuilding Devuan's kernel source with custom configuration.


You're also yet again ignoring the other highly important case.  It is possible, but quite difficult to boot Xen directly from U-Boot.  Whereas, GRUB will boot Xen out of the box.

In other news I find device-trees rather underwhelming.  Most UEFI implementations will boot Linux kernels from 3.0 to 5.10 with the exact same implementation.  The same implementation will also boot *BSD, or other closed OSes from Redmond.  Yet a device-tree implementation is only likely to work with one kernel version of one OS.

I'm not ignoring it, I just don't care smile I find it at this time to be a bit fruitless, hence why I suggested if you wanna put in the work to make it happen. Have at it!

You can simply review the latest changes in mainline to find what ur saying about kernel revisions isn't accurate at this time: https://git.kernel.org/pub/scm/linux/ke … 10.52&dt=2

I'm not against getting this working, I'm simply saying that the effort needed to get that done would be very time consuming.

Cheers!

#24 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-26 22:24:04

ehem wrote:
c0rnelius wrote:
ehem wrote:

Is there any hope Raspberry PI 4B images with U-Boot => GRUB will show up?

I like being able to easily boot previous kernels when the latest fails (modified kernels do fail and sometimes security update kernels have introduced severe reversions).  Also the Raspberry PI 4B has hardware suitable for running Xen and recent versions of GRUB (2.02 has the module, but only >=2.04 has an appropriate /etc/grub.d/20_linux_xen) will load Xen/ARM64 out of the box.

This would be easier to accomplish using u-boot and extlinux, with extlinux you can add an optional menu. One problem though, would be the current kernel packaging, as currently it purges the old kernel, dtbs, initrd, overlays and headers during install.

That doesn't seem easier except for the first time setup.  Maintenance is harder since it means spinning everything by hand, whereas GRUB has everything scripted out of the box.

More importantly, you missed the second part.  I don't believe extlinux can load Xen (two kernels plus an initial ramdisk).


c0rnelius wrote:

As for Grub, I've played around with it on other SBCs, but am not 100% sure how to set that up correctly on a Pi.

You use U-Boot's UEFI support to have it load GRUB (SuSE uses this approach).  While wasteful due to having an extra bootloader stage, you gain GRUB's massively better functionality.

You aren't taking under account kernel packaging and the problems therein. Not to mention overlays and whatnots are gonna be different between kernel revisions, so now that would also need to be taken under consideration. Grub would also need to be scripted to know what to look for, which presents even more headaches.

Even other SBCs that use grub aren't trying to boot more than one kernel, as there is a lot of things to account for. But hey, if you feel like looking into it and investing the time and effort to make it work, go for it.

#25 Re: ARM Builds » Is any work planned for devuan on the raspberry pi 4? » 2021-07-26 14:49:03

ehem wrote:

Is there any hope Raspberry PI 4B images with U-Boot => GRUB will show up?

I like being able to easily boot previous kernels when the latest fails (modified kernels do fail and sometimes security update kernels have introduced severe reversions).  Also the Raspberry PI 4B has hardware suitable for running Xen and recent versions of GRUB (2.02 has the module, but only >=2.04 has an appropriate /etc/grub.d/20_linux_xen) will load Xen/ARM64 out of the box.

This would be easier to accomplish using u-boot and extlinux, with extlinux you can add an optional menu. One problem though, would be the current kernel packaging, as currently it purges the old kernel, dtbs, initrd, overlays and headers during install.

As for Grub, I've played around with it on other SBCs, but am not 100% sure how to set that up correctly on a Pi.

Board footer

Forum Software