Hi Guys,

It seems that I can't boot latest Armbian image from SD-card  - system always boots into "inintramfs". See the screenshot.
SD-card is 100% working (all sectors tested). The image - 25.11.1_noble_6.12.58_gnome_desktop (downloaded from front page of OrangePi5). Checksum is OK.

Please note - I've already tested 3 different prorgams for images:  USB-imager, Rufus, Win32diskimager. Nothing helped))).
I also re-wrote MTD flash (not sata) by "armbian-install" and got nothing (!)

 

I use my main Armbian-server installed on nvme, but I would prefer to run SD-images as well... Unfortunately, as I see, this became very difficult task lately(((.

 

P.S. I don't want to erase mtd0 and boot from SD as I will probably lose my perfectly working boot from nvme if SD-boot fails again. Not sure what to do...
 

Any ideas? Thanks.

 

 

 

 

 

 

Edited December 22, 2025Dec 22 by Last Man

picture seems broken/corrupted

1 hour ago, Last Man said:

I don't want to erase mtd0 and boot from SD as I will probably lose my perfectly working boot from nvme if SD-boot fails again.

But that means you have 2 bootloaders and also 2 bootscripts. That will cause confusion, is it no surprise you end up in initramfs. I do not know which one has priority for the OPI5, maybe it is variable, depending on something in hardware on the board.

On my ROCK3A, I can place an optional jumper that disables mtd0/SPI, so only option is U-Boot from SD-card.

 

You can interrupt U-Boot if you connect serial console cable and then manually load the OS from SD-card or NVME, but it is a lot of commands and you need to know or study what those do.

 

If you want to run a new OS from SD-card, you need to change (all) boot.* + armbianEnv.txt files, such that there is only 1 set (from SD-card or from NVME). Also only 1 U-Boot is best, else it will stay confusing. So wipe the U-Boot on SD-card. Then place the correct UUID in armbianEnv.txt (the UUID from rootfs on SD-card).

 

Alternatively, you can use extlinux.conf boot method, you need to create that yourself, I use it on some SBC's so I can test new kernels etc (select at  power-on in U-Boot via serial console cable).

Or you flash EDK2-UEFI in mtd0/SPI and radically change all to EFI en grub bootmanager. Needs all manual own actions, not an Armbian thing.

1 hour ago, eselarm said:

If you want to run a new OS from SD-card, you need to change (all) boot.* + armbianEnv.txt files, such that there is only 1 set (from SD-card or from NVME). Also only 1 U-Boot is best, else it will stay confusing. So wipe the U-Boot on SD-card. Then place the correct UUID in armbianEnv.txt (the UUID from rootfs on SD-card).

Hm... I never had such problems before. As far as I know, U-boot always overrides SPI as soon as bootable SD-card is inserted. How can I reach U-boot on SD-card if Armbian installation has been interrupted and not finished? When I insert such raw SD-card I do not see there any partitions applicable for mounting...  My apologies for silly questions)))

What is booted also depends on boot scripts (and what is in armbianEnv.txt). This might have changed. And also the U-Boot code on the SD-card (sits invisible between partition table and 1st partition, usually sector 34-32767) might be newer and assume other defaults, I don't know. You need serial console cable and loglevel set to 7 so you can see what is happening after power-on. But maybe something else is wrong, at least make sure you post relevant info here on the forum.

 

You can look in /usr/lib/u-boot/platform_install.sh to see where U-Boot is written. Also if you look there you can find some version string, likely in your mtd0/SPI is older than on the SD-card. 

Hi all, I found where the problem was... My SD-card was not working correctly. My apologies. The system could not read/find ext4 partition on SD-card (because of "unknown" type and mounting point).  I guess this happened when I erased my previous ext4 partitions by Windows disk manager and re-wrote Armbian image later. Problem was resolved as soon as I reformatted/recorded new image by Ubuntu. Thank you all.

Thank you @Last Man I thought i was going crazy. Having the same issue!

 

The accepted solution is a workaround only. There is a real problem with windows here. I was having the exact same issue with my rk3588 device, ROCK 5B, with Armbian images, as well as Batocera. Using linux 'dd' of course solves the issue.

 

But no tool on windows worked to generate bootable images. Armbian imager, win32diskimager, rasp pi imager, rufus, etc. All sd cards came out the same, and corrupt, when imaged on windows.

 

Even worse, and what led me to find the issue finally: I could image on linux, and boot in rock 5b just fine. But if i imaged on linux, then plugged the sd card into a windows machine, just to look at it, it would never boot correctly on the rock 5b again. Would always drop to initramfs on armbian, or no boot at all in batocera.

 

Basically windows doesn't like the images we flash to media, it tampers with ANY of them to 'fix' the backup GPT to be at the end of the drive as soon as you insert it. Since most images are smaller than the media they are being put onto, the backup GPT end up located somewhere in the middle of the drive. Linux doesn't care about this. Windows does, and windows WILL 'fix' it. Usually it doesn't matter. The fix completes, the image is bootable still, and windows did you a 'favor'.

 

But on some of these arm boards, the OS images reserve space ahead of its first partition, and sets a higher value for the FirstUsableLBA. They keep idbloader and u-boot stuff down there. Even though this is 'fine' and 'legal' by GPT standards, windows doesn't know how to deal with it, and corrupts the primary GPT table entirely, by assuming the FirstUsableLBA will always be at the start of the drive after the primary GPT. Then windows pretends everything is fine, since it only uses the backup GPT of disks for some reason, and never notices the mess it made.

 

Full write up and how to validate the bug with VM's and known GPT structures is here:

https://github.com/peacepenguin/win32diskimager/blob/master/TESTING-GPT-BUG.md

 

Claude made a fixed up fork of Win32DiskImager that has a few options to correct the bug, or workaround it.

 

The workaround option in the fork is that it images as normal, then keeps the drive locked, and then ejects, before windows can bork it up, and tells you to unplug it right away. But if you ever plug it back into windows, it'll corrupt.

 

Then the better fix option it has is to check the box to "fix gpt". This way the tool CORRECTLY moves the backup GPT to the end of the disk after imaging, so windows is OK with it, and doesn't launch its buggy fix itself.

 

The fork has some other nice adds, like removing the need to have a drive letter assigned, and the ability to 'show all drives' so any block device can be written to.

https://github.com/peacepenguin/win32diskimager/releases
 

This is a legit windows bug that should be reported upstream. Windows 11 25h2 has the issue, not sure about older or newer win11 builds. Moral of the story remains: Don't use windows; but if you have to use windows, just know that it WILL tamper with your data silently, and sometimes that tampering will corrupt your data.