RPi5 Armbian_25.2.x upgrade: Unsupported initramfs version

[ChrisO]

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

[Werner]

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.

[eselarm]

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.

[ChrisO]

I started from scratch.
Installed Armbian_25.2.2_Rpi4b_bookworm_current_6.12.15_minimal.img

Having in mind what @eselarm suggested as culprit, I put raspi-firmware on hold

root@rpi5b:~# apt-mark hold raspi-firmware
then

dpkg --remove --force-all libraspberrypi0 armbian-bsp-cli-rpi4b-current
apt --fix-broken install
apt install armbian-bsp-cli-rpi4b-current

everything OK

apt upgrade

everything OK

Reboot
root@rpi5b:~# uname -a
Linux rpi5b 6.12.31-current-bcm2711 #1 SMP PREEMPT Wed Jun  4 14:00:53 UTC 2025 aarch64 GNU/Linux

Tried the same with raspi-firmware unhold and got this
.
.
Setting up raspi-firmware (1:1.20250430-1) ...
ERROR: Unsupported kernel version (6.12.15-current-bcm2711)
Setting up libraspberrypi0:arm64 (1:2+git20231018~131943+3c97f76-1) ...
Setting up libraspberrypi-bin (1:2+git20231018~131943+3c97f76-1) ...
Processing triggers for libc-bin (2.36-9+deb12u9) ...
Processing triggers for man-db (2.11.2-2) ...
Processing triggers for initramfs-tools (0.142+deb12u1) ...
update-initramfs: Generating /boot/initrd.img-6.12.15-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.15-current-bcm2711)

I then did

apt-mark hold raspi-firmware
apt purge raspi-firmware
and
apt upgrade
went through but the system is not in a good shape.
root@rpi5b:~# uname -a
Linux rpi5b 6.12.15-current-bcm2711 #1 SMP PREEMPT Wed Feb 19 13:49:50 UTC 2025 aarch64 GNU/Linux
The /boot/firmware/initrd.img was not updated.

Then I installed Armbian_25.2.4_Rpi4b_bookworm_current_6.12.22_minimal.img
First thing after boot:

root@rpi4b:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.12.22-current-bcm2711
ERROR: Unsupported initramfs version (6.12.22-current-bcm2711)

The same with Armbian_25.5.1_Rpi4b_bookworm_current_6.12.28_minimal.img
I don't have anymore a clean 25.2.3 but the homeassistant_minimal.img one has the same problem.
No idea how to fix it.
raspi-firmware has status optional and the 25.2.2 works OK without it, I think I will go this way
hoping somebody with better skills then me will fix it one day.

 

Regards,

Chris

[Werner]

Without any research I assume this firmware package contains some fw files that are just there in case somebody wants to reflash some otherwise inaccessible fw storage.

Similar to u-boot packages which on upgrade will store the necessary binaries for reflash on fs but does not actually reflash itself in the boot sector. Needs to be done manually.

 

So tl;dr: having this optional makes sense.

[eselarm]

On my up-to-date RPi4 server (Raspberry Pi OS 64-bit), dpkg -L lists all files in the (RPL variant of) raspi-firmware package. There are control files, scripts, hooks, license, readme, but the essential files are:

/usr/lib/raspi-firmware/bootcode.bin
/usr/lib/raspi-firmware/fixup*.dat
/usr/lib/raspi-firmware/start*.elf

 

Now RPi 3 4 5 differ what is needed. RPi3 only has ROM and uses bootcode.bin as sort of replacement/overlay/patch. PPi4 has this in EEPROM, so does not need bootcode.bin but I am not sure if it boots if the file is missing. RPI5 is radically different and AFAIR, does not need any of those 3 files, all bootloader code etc should be in EEPROM, I guess much like e.g. ROCK5B or so with U-Boot in SPI-flash. So that is also a reason that an RPI5 keeps booting/working even if you purged raspi-firmware (and that also deletes the copy on the bootFAT, check that, there were bugs in the .deb install script in the past).

 

apt hold of the package keeps all the files original in the rootfs (and also the copies on bootFAT) so also /etc/initramfs/post-update.d/z50-raspi-firmware will still be there. It will be called every time a kernel version of initramfs is generated. For every kernel that is not from RPL, you hit the line:

    echo "ERROR: Unsupported initramfs version ($initrd_version)"

in that script. As I indicated it is harmless if you happen to know what is in the script, but of course a bit of panic if not. A quick hack would be to comment out that line

 

In the past (pre-Bookworm), for RPi3 and RPi4 I had an own extra script/hook that fetched 'latest version' of those 3 types of RPi files for 'firmware OS Linux Testing Opensuse' experiments and copied those to bootFAT. The core problem is that it is closed source, the only thing more or less sure is that steady improvement because RPL/RPT has long-term support even for their old 2012 Pi1. So how to do version control / management?

 

I see there is also a settings file:  /etc/default/raspi-firmware
Maybe put several 'no' in there if your kernel is not the one from Raspberry Pi OS, which is the case for Armbian.

 

[eselarm]

I just updated a raspios64 virtual machine with grub-efi and vanilla Debian kernel added:

Settings in: /etc/default/raspi-firmware  
KERNEL=no
INITRAMFS=no
SKIP_INITRAMFS_GEN=yes

Still:

update-initramfs: Generating /boot/initrd.img-6.1.0-37-arm64
ERROR: Unsupported initramfs version (6.1.0-37-arm64)

 

So it is not working as I hoped/thought.