The officially official Devuan Forum!

You are not logged in.

#1 Re: ARM Builds » Raspberry Pi 5 » 2024-01-25 13:52:16

@vortex Technically new ARM64 images generated by the builder for the pi4 "bcm2711" can be used to boot the pi3, pi4 and pi5 and any other variant using the same SoC. If you make pi5 "bcm2712" specific images, they can only be used on the pi5.

#2 Re: ARM Builds » Help, upgrading fails » 2023-11-30 13:50:40

Did you make changes to anything? I can't think of any reason why that would not be working if there is a /boot/initrd.img-6.1.63 file present.

#3 Re: ARM Builds » Obsolete packages in Raspberry Pi image » 2023-10-11 20:05:43

The kernel can be updated if you build it ur self using the github repo. There is also a deb-eeprom script on the pi4 images that can be used to update the eeprom package. Warning: I no longer have a Pi4, so I have no idea how well it works anymore and honestly I'm sure the script needs to be updated and made easier to use.

As for pi-bluetooth and sys-mods. There isn't much to do there, as they are basically just debs that install scripts and udev rules and such.

#4 Re: ARM Builds » Obsolete packages in Raspberry Pi image » 2023-10-11 17:08:26

It's a community build. The packages aren't obsolete, but custom made. Meaning, they aren't officially supported.

Devuan fork;

#5 Re: ARM Builds » Which Raspberry Pi ? » 2023-08-12 21:47:30

vladomiro wrote:

Hi to everyone,

I'm not sure if I should create a new topic or it's OK to get back to life this one.

I'm unable to boot the devuan rpi4 64 bits image in the raspberry pi zero 2w. I understand that's the right one for that version of raspberry.

Is it right or I should use the 32 bits image instead?

The Zero2W is basically a PI3 in a Zero form factor, so use a Pi3 img.

#6 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

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

Hostname:    raspberrypi
Wireless:    wlan0 UP 

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
patrick@raspberrypi:~$ lsblk
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 
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

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


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

#7 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: … figuration

I just spun this and tested it (worked fine for me): … -16.img.xz
First boot and general usage:

I also included a default passwd for root: toor

#8 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.

#9 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. … 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.

#10 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.

#11 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: ->

#12 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:


You can find them here

#13 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"


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

# IMPORT{builtin}="net_setup_link"

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


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

#14 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.


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

batmore wrote:

>They need testing:

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.

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

They need testing:

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.

#17 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 -->

#18 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.

#19 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:

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 -->
The firmware function --> … 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.

#20 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.

#21 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.

#23 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. …

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

#24 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


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.

#25 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.

Board footer

Forum Software