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.

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

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

Not gonna disagree. Would be easier.

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

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.

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.

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

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.

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.

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

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.