Unsupported kernel version while updating raspi-firmware on Debian 13

[lovenemesis]

Recently, when I run `armbian-upgrade`, I was greeted with an update to raspi-firmware. However, this version of firmware doesn't seem to work with the corresponding intramfs with kernel 6.12.44.

 

sudo armbian-upgrade
Hit:1 https://mirrors.ustc.edu.cn/armbian trixie InRelease
Hit:2 https://mirrors.ustc.edu.cn/debian trixie InRelease
Hit:3 https://mirrors.ustc.edu.cn/debian trixie-updates InRelease
Hit:4 https://mirrors.ustc.edu.cn/debian-security trixie-security InRelease
Hit:5 https://github.armbian.com/configng stable InRelease
Get:6 https://apt.syncthing.net syncthing InRelease [24.2 kB]
Fetched 24.2 kB in 2s (14.8 kB/s)
2 packages can be upgraded. Run 'apt list --upgradable' to see them.
The following packages will be upgraded:
  armbian-config  raspi-firmware

Summary:
  Upgraded: 2, Newly installed: 0, To remove: 0, Not upgraded: 0
  Download size: 13.2 MB
  Space required/available: 272 kB / 553 GB

Get:1 https://mirrors.ustc.edu.cn/armbian trixie/trixie-utils arm64 raspi-firmware all 1:1.20250915-1~bookworm [13.0 MB]
Get:2 https://github.armbian.com/configng stable/main arm64 armbian-config all 25.11.0-trunk.234.0923.175957 [157 kB]
Fetched 13.2 MB in 2s (5,967 kB/s)
(Reading database ... 46602 files and directories currently installed.)
Preparing to unpack .../raspi-firmware_1%3a1.20250915-1~bookworm_all.deb  ...
Unpacking raspi-firmware (1:1.20250915-1~bookworm) over (1:1.20250430-4~bookworm) ...
Preparing to unpack .../armbian-config_25.11.0-trunk.234.0923.175957_all.deb  ...
Unpacking armbian-config (25.11.0-trunk.234.0923.175957) over (25.11.0-trunk.192.0915.191809) ...
Setting up armbian-config (25.11.0-trunk.234.0923.175957) ...
Setting up raspi-firmware (1:1.20250915-1~bookworm) ...
Installing new version of config file /etc/initramfs/post-update.d/z50-raspi-firmware ...
Installing new version of config file /etc/kernel/postinst.d/z50-raspi-firmware ...
WARNING: Unsupported kernel version (6.12.44-current-bcm2711) - skipping setup
NOTE: Manual boot configuration may be required
Processing triggers for initramfs-tools (0.148.3) ...
update-initramfs: Generating /boot/initrd.img-6.12.44-current-bcm2711
WARNING: Unsupported initramfs version (6.12.44-current-bcm2711) - skipping setup
NOTE: Manual boot configuration may be required
Summary:
  Upgraded: 0, Newly installed: 0, To remove: 0, Not upgraded: 0

 

How exactly should I do in this case? In the past, I normally invoke update-intramfs to perform the  the intramfs update.

 

Thanks,

 

[0jay]

may not help you (i'm running the pi4 build) but i find that putting holds on rpi-eeprom, raspi-firmware and raspberrypi-sys-mods from first boot solves this problem

[Werner]

I think this "unsupported version" thingy when doing initramfs update is just a cosmetical thing. The script comes from upstream and checks for version string included in upstream (directly from Raspberry to say) kernels.  However I believe this has been worked around by our own bsp which is silently executed right after.

Cannot tell for sure if that's the issue I remember it is since I don't have access to hw atm.

[lovenemesis]

@0jay it should also happen for your build as well since I'm using generic Raspberry Pi build on RPi5. Or you never see it because of the "hold"?

 

@Werner That's good to know. May I know if there's any way for me to check for certain? Thanks a lot!

[Werner]

I think there are some directories in /etc which contain initramfs pre/post scripts. I don't have hw on hand to check right now but I believe there was some script starting with z50- filename that contained this check and there should be a 2nd one from Armbian that actually does what the upstream script refuses to do.

[0jay]

6 minutes ago, lovenemesis said:

Or you never see it because of the "hold"?

If I hold those packages I don't see any issues at all.

[Werner]

1 minute ago, 0jay said:

If I hold those packages I don't see any issues at all.

IIRC until like half a year ago this also worked just fine. I assume then this check was introduced upstream which caused this - more or less cosmetical - error.

 

[0jay]

57 minutes ago, Werner said:

more or less cosmetical - error

 

I was having some pretty substantial problems with several different builds before developing this hold pattern, Werner