ChrisO Posted Tuesday at 02:11 PM Posted Tuesday at 02:11 PM (edited) Hi Installed Armbian_25.2.3_Rpi4b_bookworm_current_6.12.17-homeassistant_minimal.img To work around broken packages dependency run: apt update dpkg --remove --force-all libraspberrypi0 armbian-bsp-cli-rpi4b-current apt --fix-broken install At the end I got this: update-initramfs: Generating /boot/initrd.img-6.12.17-current-bcm2711 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156a-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153c-1.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153b-2.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-4.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-3.fw for built-in driver r8152 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8153a-2.fw for built-in driver r8152 ERROR: Unsupported initramfs version (6.12.17-current-bcm2711) Armbian_25.2.4_Rpi4b_bookworm_current_6.12.22_minimal.img the same. Any idea anyone what is wrong here? Thanks Chris Edited Tuesday at 09:18 PM by ChrisO edit 0 Quote
Werner Posted yesterday at 03:58 AM Posted yesterday at 03:58 AM 13 hours ago, ChrisO said: ERROR: Unsupported initramfs version (6.12.17-current-bcm2711) I've seen this error before. I think that's some incompatibility from rpi own packages that have some regex checking if its their own kernel or not. Did not get any further though. 0 Quote
eselarm Posted 23 hours ago Posted 23 hours ago This reminds me of old issue on rpi forum, back to Debian10 times more or less when RPL did not support initramfs and I have been using Btrfs for RPis since Buster (or for sure Bullseye) timeframe. I loop mounted Armbian rolling rpi4 trixie image and ran it via systemd-nspawn -b -D <mountpoint> Then it turns out what I thought: the installed firmware package includes the script same as on Raspberry Pi OS from RPL themselves to copy/rename standard Debian kernel+modules install patch to the FAT boot partition. root@localhost:~# apt list | grep raspi raspi-config/trixie,trixie,now 20221214-0ubuntu1 all [installed] raspi-firmware/trixie,trixie,now 1:1.20250430-1 all [installed] raspi-gpio/trixie 0.20231127 arm64 raspi-utils/trixie,trixie 20250314-1 all root@localhost:~# dpkg -L raspi-firmware | grep z50 /etc/initramfs/post-update.d/z50-raspi-firmware /etc/kernel/postinst.d/z50-raspi-firmware /etc/kernel/postrm.d/z50-raspi-firmware And it is this part of z50-raspi-firmware flavour="$(echo "$initrd_version" | rev | cut -f1 -d- | rev)" case $flavour in v6|v7|v7l|v8|2712) ;; *) echo "ERROR: Unsupported initramfs version ($initrd_version)" exit 0 ;; esac On 1 of my RPi4 I had also the standard Debian kernel 'linux-image-arm64' besides the RPi kernel 'linux-image-rpi-v8' and grub-efi. So when the bootFAT parttition is tagged 0xEF00 (ESP) I could run the image/SD-card unmodified in virt-manager selecting the vanilla Debian kernel in GRUB. I have thought a lot about what to do with those hook scripts in /etc/initramfs, also created various own ones, for Raspberry Pi OS and Raspbian and Armbian. The latter as it is U-Boot (on Rockchip/Allwinner) but just recently I put EDK2-UEFI v1.1 in SPI-flash and that makes all the efforts void as I now use default grub to load Armbian (and Opensuse) on RK3588. For RPi (3, 4, 5) this won't work unless some intermediate efi binary loader is used like is done in Opensuse, for Fedora maybe as well, I don't know. Still this won't work for RPi5 (yet) as its RP1 chip is a bottleneck for upstream support (complex PCI-E DeviceTree handling, see patches efforts done by Suse people AFAIR). With introduction of Bookworm, the RPi firmware can load standard names for initramfs for all RPi HW variants back till 2012. But still no way to select a specific kernel adhoc at boot time via serial console for example (like extlinux.conf for U-Boot). The U-Boot v.s. RPI-firmwarebootloader feels a bit like UNIX pathnames v.s. MS-DOS pathnames, e.g. "/tmp" v.s. "C:\TEMP" or "Image" v.s. "kernel8.img" or "uInitrd" v.s. "initramfs8". Maybe the option is to patch z50-raspi-firmware, maybe remove it from the .deb package. But also it is just a warning, so who cares one could think. Other option is to use the vanilla Debian variant of raspi-firmware root@localhost:/etc/apt/sources.list.d# apt list -a raspi-firmware raspi-firmware/trixie,trixie,now 1:1.20250430-1 all [installed] raspi-firmware/testing 1.20240424+ds-6 all That older version has other script implementation (very different), also uses upstream_kernel=1 in config.txt, which selects other firmware DTB names for Pi3. Now writing this, I think 'vendor' could be downstream RPL based, so new firmware package and 'current' and 'edge' could be upstream mainline. But that also would mean almost no RPi5 functionality as long as that RP1 I/O chip functionality is not upstreamed. I don't know what status is, latest I know is that the wired ethernet still does not work, workaround is to use a RJ45 USB2 dongle on the USB-C connector. 1 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.