Every now and then some of our devices fail to boot to the SD card. This can happen at first boot or by triggering a reboot from within the device page in info-beamer.
Simply unplugging the device and plugging it back in will resolve this in most cases. However inconvenient. This is not something that I had happen in the past with standard Raspberry Pi OS. Is there a way to resolve this?
Yikes. The issue with the failing reboot popped up with a couple of other Pi4s. The latest release was supposed to fix that. At least the developer messages for changes made to the Pi4 EEPROM suggested that.
The EEPROM firmware you’re using is pretty new (April 2021), so I guess this is already running the latest info-beamer release. c03112 decodes to a Pi 4B rev 2 4096MB, so it’s one of those older revision 2 boards, but according to this statement, the April version of the firmware fixed that.
What’s a bit puzzling is the first screenshot. It suggest that the Pi was able to boot at least a bit before it could no longer read from the SD stopped. For those log message to appear on the screen, at least start_x.elf, kernel8.img and initramfs.lzma must have been read successfully. It’s odd that the SD card then fails. Do all the devices with that problem use the same type of SD card? Do you have another vendor/model you might temporarily try instead? That way we could rule out a bad batch of cards.
Another followup observation: The first screenshot shows a situation that can potentially self-recover: Can’t look it up right now, but I think after 60 seconds, the Pi should reboot in that case.
The second screenshot shows the Pi4 bootloader/HDMI diagnostics screen. The EEPROM configuration applied by info-beamer OS endlessly tries to restart booting from the SD card (It’s the f1 you see in the output, read from right to left, 1 means “try to boot from SD”, f means start from the beginning again). Right now there’s no limit on the number of attempts made. There is a way to maybe change this in a future OS release: The MAX_RESTARTS value can put a limit on the number of boot attempts before the Pi is forcefully rebooted and it might have more luck on its next boot. But of course that’s all not fixing the root cause.
I did read a similar older post but it said it was resolved so I thought this might be a newer issue. Its very intermittent when It happens, I can reboot multiple devices without any issues but then out of nowhere this may happen on one or more devices.
You are right, the first screen will hang for a bit and I often leave it to see if it will recover but it then appears to reboot and display the Raspberry Pi bootloader. I can confirm all the devices are running on the same type SD card. I could get a hold of another brand to try and rule out the card being the culprit.
If the EEPROM could force a reboot after failed attempts that would certainly be better than having someone manually unplug/plug the device at each location this happens in. But as you say, its not a fix for the root cause.
I’ll get a different brand SD and give that a go as soon as I’m able to and post back with the results
Thanks. Meanwhile I’ll revision the decision for not limiting the attempt counter using MAX_RESTARTS. It was set to 16 at some point, but IIRC I figured it wouldn’t make sense to put a limit there as I hoped the Pi’s EEPROM boot process isn’t fragile to need a forced reboot to recover. Seems I was wrong. If you can reproduce the issue with another SD card, I guess it might make sense to open a bug report with Raspberry Pi to see if they have an idea what might happen.
Just thought I’d give an update here regarding this issue. I have replaced a few SD cards in some of the more troublesome devices. However, since doing this I have had less issues with all of the devices, even the ones with the original SD cards. Each morning I check the device list and they all appear online. Was there an update by chance that would have potentially fixed this or have I just got lucky?
With that said, the SD brand I was using was Silicon Power and the SD cards I moved to were San Disk - Just in case anyone else has a similar issue.