Creating a bug report/issue
I have searched the existing open and closed issues
Required Information
- DietPi version |
?? - Distro version |
?? - Kernel version |
?? - Architecture |
arm64 - SBC model |
Orange Pi 5B - Power supply used | Ugreeen 65W
- SD card used | SanDisk Ultra 64GB
Additional Information (if applicable)
- Software title | (EG: Nextcloud)
- Was the software title installed freshly or updated/migrated?
- Can this issue be replicated on a fresh installation of DietPi?
← If you sent a “dietpi-bugreport”, please paste the ID here → - Bug report ID |
echo $G_HW_UUID
Steps to reproduce
Honestly not sure, but…
- Flash DietPi on SD card using Balena Etcher.
- Try to boot
Expected behaviour
- It should boot
Actual behaviour
- It doesn’t boot, the dietpisetup partition is not touched, the red power LED is on, the blinking green LED does not come on.
Extra details
Honestly I don’t know where I went wrong, but:
- Tried to move my DietPi install from SD to eMMC
- When shrinking my partition with GParted Live it encountered an error
- I thought, no big deal, let’s try again, and it succeeded.
- Tried booting it to move to eMMC, booted to an old install of DietPi I had forgotten was on the eMMC.
- Booted a live Ubuntu USB to check the SD card
- Ran e2fsck -f -y multiple times. It fixed loads of errors but kept finding more and more every time I ran it.
- Checked block/sector math (tune2fs -l vs fdisk). Boundaries matched perfectly.
- Wrote a file (test.txt), power cycled, and it persisted. The SD card flash memory is 100% healthy in my opinion.
- Disabled/re-enabled the ext4 journal (tune2fs -O ^has_journal). Did not break the fsck loop.
- Restored from backup superblock (e2fsck -b 32768). No progress there.
- Checked U-Boot: Ran hexdump -C on Sector 64. Found RKNS signature.
After that, I tried to evacuate the data that was intact from the SD by using tar to to back up the entire OS to an exFAT USB drive. Successfully extracted a 28.6GB archive (with some orphaned files ending up in lost+found).
Next attempted a fresh DietPi install:
- Flashed a new image I got from the DietPi website to the SD card via BalenaEtcher and failed to boot (black screen, no green LED)
- Added fdtfile=rockchip/rk3588s-orangepi-5b.dtb to /boot/dietpiEnv.txt in hopes of fixing something. Still failed to boot. Previously it would boot without this fix but wouldn’t see the eMMC.
- Randomized the ext4 root partition UUID (tune2fs -U random) and updated fstab/dietpiEnv.txt to ensure the old eMMC OS wasn’t hijacking the mount process. Still failed to boot.
- Flashed the official Orange Pi Android and Orange Pi Debian images. Both official images booted flawlessly from both the SD card and the eMMC.
- Attempted to use RKDevTool to EraseAll the eMMC, but encountered a “check ddr” error
- Booted Orange Pi Debian from the SD card and manually wiped the eMMC bootloader
- With the eMMC blank, put the fresh DietPi SD card back in. Still failed to boot.
- Installed working Orange Pi Debian natively on the eMMC. Ran the DietPi conversion script to hijack the working vendor kernel/U-Boot. dpkg error on orangepi-firmware (conflicting over /lib/firmware/brcm/BCM4345C0.hcd); dpkg error on linux-u-boot-orangepi5b-current (conflicting over /usr/lib/u-boot/LICENSE) Dropped to subshell, purged vendor packages with dpkg -P --force-all, ran apt-get --fix-broken install, and resumed the script.
- Before the final reboot, copied dietpiEnv.txt to orangepiEnv.txt to appease the vendor U-Boot. System halted on reboot. Completely unbootable.
I’m at a loss on what to try next. My biggest question is why, when I flash a fresh install of DietPi on my SD card, it just refuses to boot. Orange Pi provided Debian boots from the SD.