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.

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

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 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?

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.