Rocky 9.6 - Raspberry cannot boot after dnf update

Hi there,

Install an SD card with Rocky 9.6 and boot a Raspberry 3B+ or a 4B with it.
All is fine and the RPI work just fine.

Then, call dnf update -y and reboot.
Then, the RPI is no more able to boot:

  • 3B+ will show a black screen
  • 4B will show “firmware not found”

I digged a bit and found that kernel-rpi-firmware-6.6.77-7.el9.altarch.aarch64.rpm comes with the update. Its content show the following:

[root@prod-049-arm64 ~]# rpm -qplv ./kernel-rpi-firmware-6.6.77-7.el9.altarch.aarch64.rpm | head
-rw-r--r--    1 root     root                     1594 Jan 27 14:41 /boot/efi/LICENCE.broadcom
-rw-r--r--    1 root     root                    52476 Jan 27 14:41 /boot/efi/bootcode.bin
-rw-r--r--    1 root     root                       29 Feb 18 12:29 /boot/efi/config.txt
-rw-r--r--    1 root     root                     7330 Jan 27 14:41 /boot/efi/fixup.dat
-rw-r--r--    1 root     root                     5459 Jan 27 14:41 /boot/efi/fixup4.dat
-rw-r--r--    1 root     root                     3232 Jan 27 14:41 /boot/efi/fixup4cd.dat
-rw-r--r--    1 root     root                     8457 Jan 27 14:41 /boot/efi/fixup4db.dat
-rw-r--r--    1 root     root                     8457 Jan 27 14:41 /boot/efi/fixup4x.dat
-rw-r--r--    1 root     root                     3232 Jan 27 14:41 /boot/efi/fixup_cd.dat
-rw-r--r--    1 root     root                    10300 Jan 27 14:41 /boot/efi/fixup_db.dat
...

the firmware and all come under /boot/efi which is normal for a standard Raspbian,
but the Rocky 9.x raspberry images are built with the firmware under /boot.

Got 2 workarounds, so far:

  • If ever /boot/efi is present, move its content to /boot/. (under testing).
  • Exclude this package from DNF update mechanism (tested OK) :
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
best=True
skip_if_unavailable=False

exclude=kernel-rpi-firmware-6.6.77-7.el9.altarch.aarch64
3 Likes

1st workaround is confirmed working.
If you ever have this installed, move /boot/efi/* to /boot and RPI is able to reboot.

1 Like

My guess is that this particular package is supposed to come only on Rocky 10, not Rocky 9.x
If it’s removed from the servers/mirrors, all should be fine.

my 2 cents.

Rocky 9 has been rock solid on my Raspberry Pi 3 for years. No problems with any updates at all. Then yesterday it did nearly the same thing thing to me. After the dnf update it’s dead. I can’t even get any video with the card plugged in after the update either. I decided to just reimage with Rocky 10, but I get the same thing there as well. Just for grins to makes sure it wasn’t my Pi at fault I imaged it with Raspberry Pi OS, and it booted up with no problems. Something goofy may be going on with the current 9.6 / 10 images for Raspberry Pi. At least when it comes to these models. The Rocky 10 README link on the main downloads page is currently broken too.

The Rocky 10 raspberry pi image wont work on a pi 3 as it requires an mbr disk layout and as of 10, its gpt. There’s currently an issue with the kernel-rpi-firmware package. The best fix is the one suggested above. 1. copy the contents of /boot/efi to /boot and reboot. Also, blocking it from further dnf updates is a good workaround as well. We’re working on a better fix with no ETA at this point.

Thanks for reporting this with your workaround.
No, it is indeed meant for RL9. part of the problem is, there’s a newer rpi kernel that that firmware package matches too. I’ve yet to confirmed why the newer firmware package got installed as the name changed and nothing requires it that i can see.

We’re currently working on a fix but unfortunately dont have an ETA.

Thanks for the quick response. That’s good to know. I’ll reinstall with the 9 image, and perform this workaround before doing the dnf update.

Side question. Where are the requirements for Rocky 10 posted for the Raspberry Pi? As mentioned earlier, README link is broken.

10 will work on Raspberry Pi 4 and newer.

1 Like

Hazard of running nearly 10 year old $25 hardware I suppose. :grinning_face:
Completely understandable due to the GPT requirement.

Keep up the great work and thanks again!

No problem at all. When it just works, there’s no reason to throw it out. I suspect one could generate an image for 10 that would work on a pi 3, but itd take a bit of work. We use kiwi to generate our images. As of 10, gfdisk isnt available and thus gpt disks are easiest. I’m not saying mbr isnt possible, just will take a bit of extra work. kiwi descriptions are here

Ok.
If you need some external tester, just ping me here.

1 Like

Thanks for finding and sharing this workaround.

1 Like

Glad to see this helped not only me :wink:

1 Like

You are my savior, Thank you sir.

I found this workaround after I extracted and cut my micro SD card which was not booted…

1 Like