Orange Pi 5+ no longer boots

Troubleshooting
1
  • DietPi version | cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=5
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
G_LIVE_PATCH_STATUS[0]='not applicable'
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
bookworm
  • Kernel version
# apt list --installed | grep -i linux-image
linux-image-vendor-rk35xx/all,now 24.8.0-trunk-dietpi1 arm64 [installed]
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
Orange Pi 5 Plus (aarch64)

The battery in my UPS decided that night to today was the time to declare retirement, which resulted in an unexpected sudden shutdown of my Orange Pi 5+ which runs DietPi on the integrated NVMe up to date to at least a couple of days ago, but now whenever I try to boot the DietPi-installation on the NVMe it just stands there with the red power-light on but no display output or other apparent activity.
Booting from SD-card I already had flashed with “Orangepi5plus_1.0.8_debian_bookworm_server_linux6.1.43.img” works and from there I can mount and chroot into the DietPi on the NVMe.
Once in that chroot I am told by the post-login message that “A reboot is required to finalise a recent kernel upgrade” and I was told there were upgrades to several upgrades to apply through APT, including if I remember correctly “u-boot-tools”, so since I could not do a normal reboot (see above) I applied those upgrades hoping that would fix the issue but it did not; things remain the same.

So, I don’t know exactly what went wrong but I suspect the unexpected shutdown may have somehow harmed the bootloader-process files, maybe.
For an installation on a PC I would have just reinstalled the GRUB’s bootloader while in chroot as next step, but I don’t know what the proper equivalent steps are for DietPi on an OPi5+, or if there is something else that would make more sense to try first.

Please help?

2

ping @MichaIng maybe you can have a look

3

This is expected, since the “seen” kernel is the one of the host, while the seen kernel modules are the ones from the host. I’ll probably need to add a chroot detection to our container detection function, however, that one you can ignore.

u-boot-tools are just a set of tools, not relevant for boot, unless you actually use them, to generate an initramfs image or boot script.

I guess you do not have a UART adapter to check serial console output? Can you check the boot directory:

ls -l /boot
4

Well, seems I got it working.
I decided that since the post-login message kept saying that “A reboot is required to finalise a recent kernel upgrade”, even though I had not upgraded kernel since my previous intentional reboot, maybe just reinstall the same kernel with a
apt install --reinstall linux-{image,dtb}-vendor-rk35xx
then, after that I reapplied “Update SPI bootloader” and then “Update MMC bootloader” for the seventh time (I counted, retroactively), exited chroot, unmounted all the chroot (dev, proc, sys, tmp and run) filesystems and rebooted and… it worked.

My best guess is that somehow the installed kernel’s uInitrd or similar kernel-related must have somehow gotten damaged by the sudden unexpected reboot, so just updating the bootloader itself alone wasn’t enough, but needed a regeneration of the initrd and/or adjacent files.

Sorry for the false alarm.
My excuse is that my profession had me learn OpenBoot ROM, PC BIOSes and some more similar, but not ARM-related stuff. ;-/

Thanks anyway, @Joulinar and @MichaIng.

5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.