peacepenguin

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.