[CM4] No longer boots after updating to 1739293213 ("Tue 11 Feb 17:00:13 UTC 2025") #668
Comments
Nit-pick: "l" missing from "Faied to load Device Tree file". Both are present in the source - you are losing characters somewhere. |
|
Re: Nit-pick: e missing from compatibl(e). It looks like the bootloader successfully loaded start.elf from partition1 but start.elf cannot read from the disk. It's GPT partition layout which isn't well supported. What's the partition layout? |
|
Re partition layout. This is possible the same as this issue - there's a pre-release start4.elf attached to that Issue |
Fair - the BMC UART implementation has always been a bit dodgy (to say the least…) |
This has always worked to date, and with firmware releases up to and including 1733575168 (the three other nodes and several other RPi devices have a similar setup, differing only in partition size w.r.t total device capacity). |
Yup, that's fixed it! That's a pretty severe regression between 1733575168 and 1739293213 :( Are all platforms affected - I've got a remote (and hard to access) RPi5 with a very similar partition-scheme which I luckily held off from updating? 😯 |
|
I also got this problem on Pi 4B. I use GPT partition via I see that content of rpi-eeprom, bootloader-2711/default was updated recently, I thought it will be frozen at
|
|
I believe the issue is that the bootloader now correctly passes the partition number (resolves 0 to actual number) and passes it to start.elf. Start.elf has never previously correctly handled non-default partition numbers with GPT partitions. N.B. In any A/B boot-system I would recommend putting all the FAT/EFI partitions together at the start of the GPT or in the MBR world put A/B boot in the first primary partitions and put rootfs as the last or in extended. |
|
The start.elf updates should now be in rpi-update |
|
I see the recent update's ChangeLog states:
… would |
|
PARTITION_WALK shouldn't have any effect - it's specific to the bootloader (not start.elf) and is to handle the case where autoboot.txt is missing e.g. on PARTITION 1 - where the real boot partitions are 2 and 3 |
|
Does the updated start.elf resolve the problem for you? Otherwise, it would be useful to see the logs for a good boot from before. The relevant lines would be 2.74 Matched GUID bootable-part-idx 0 want partition 0 i.e. was a different boot partition matched the bootloader and what was the partition number that was passed to start.elf. Zero means default and in the case of GPT 1 means the first EFI/FAT part in the GPT table. |
|
I also ran into this issue with https://gokrazy.org/: Updating my Raspberry Pi 4’s EEPROM to bad328a resulted in a no-longer booting system. Updating the firmware to raspberrypi/firmware@9995946 does indeed fix the issue for me. Just in case it helps further narrow down/confirm the problem, my partition layout is: (The code which generates the MBR+GPT partition table is at https://github.com/gokrazy/tools/blob/8bcde52fb89a27075b0262fe617a96b5d8a90636/packer/packer.go#L433) |
|
To know for sure I would need to see the UART log from the old bootloader but it does appear that the answer it is to update the RPi 4 firmware first before updating the bootloader. Hopefully, the start4.elf firmware will be in an APT release before too long. |
Describe the bug
After updating to firmware 1739293213 ("Tue 11 Feb 17:00:13 UTC 2025"), one of my CM4 units is no longer booting (from eMMC). It can still be restarted in MSD mode and its filesystems appear to be intact.
I've held-off from updating the other three identical CM4 units in the cluster for fear of them also being affected, but do have these additional nodes which could be used to test a solution if necessary...
Steps to reproduce the behaviour
Nit-pick:emissing fromcompatibl(e).N.B. This cluster has 4x CM4 units with identical configuration - the remainder are still on firmware 1733575168 ("Sat 7 Dec 12:39:28 UTC 2024") but work as expected with the same configuration, and I've confirmed by booting the failing node in MSD mode that the
md5sums of the kernel images are identical across all four nodes.Device (s)
Raspberry Pi CM4
Bootloader configuration.
System
n/a - system won't boot
Kernel is
(/dev/mmcblk0p2)/6.6.74_p20250127/kernel8.img(9337714 bytes, md5sum df21701e93d074637bfa25fe00c88298) withconfig.txt:Where all directives in
overclock.txtandlegacy.txtare commented.Bootloader logs
(See above)
USB boot
n/a
NVMe boot
n/a
Network (TFTP boot)
n/a
The text was updated successfully, but these errors were encountered: