Images do not boot

[OleksandrK]

I know this sounds strange, but I cannot get any of the images to boot.  
I have an R3S non-LTS + SD card. It works well with the stock images from FriendlyElec, but none of the Armbian images I tried will boot.  

I tried different tools to write the SD (BalenaEtcher, USBImager, Rufus), but nothing changed. When I tried to read the SD card with Armbian on my x86 laptop running Debian, the system didn’t recognize any proper partitions (maybe that’s normal, maybe not—I don’t know). But when I write an Armbian image for Allwinner NanoPi, the partitions are detected correctly.  

And finally, I can’t connect to the debug UART, so I can’t get any logs.  

I feel the solution should be simple, but I need help with this.

[laibsch]

Armbian's archives can be uncompressed with 7-Zip on Windows, Keka on OS X and 7z on Linux.

 

Images shall only be written with imaging tools that validate burning results.  This saves you from corrupted SD card contents.

 

Approved Tools:

• USBImager a lightweight cross-platform imaging tool
• Balena Etcher an electron / node.js based cross-platform imaging tool (may contain spyware)

Did the validation of you burning the image succeed?

[OleksandrK]

Yes, validation always succsess.
I tried even different SD cards (brand new Sandisk). After Armbian fails to boot I write stock friendlyelec image by the same tool and stock image always properly boot

[laibsch]

@c0rnelius is the maintainer of the board.  Maybe he has something to say.

[c0rnelius]

@OleksandrK

3 hours ago, OleksandrK said:

the system didn’t recognize any proper partitions (maybe that’s normal, maybe not—I don’t know)

I wrote both the Bookworm and Noble img and in both cases the partition table looked fine.

 

I booted the Noble img;

    _             _    _           
   /_\  _ _ _ __ | |__(_)__ _ _ _  
  / _ \| '_| '  \| '_ \ / _` | ' \ 
 /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|
                                   
 v25.8.1 for NanoPi R3S LTS running Armbian Linux 6.12.41-current-rockchip64

 Packages:     Ubuntu stable (noble)
 IPv4:         (LAN) 10.0.0.xxx (WAN) xx.xxx.xxx.xx 
 IPv6:         2601:xx:xxx:a200::b05b, 2601:xx:xxx:a200:510c:3033:d120:7b0d (WAN) 2601:xx:xxx:a200:e489:6cce:bd44:57dc 

 Performance:  

 Load:         25%           	 Uptime:       1 min	
 Memory usage: 8% of 1.92G  	
 CPU temp:     30°C           	 Usage of /:   10% of 29G    	
 RX today:     127 KiB        	
 Commands: 

 Configuration : armbian-config
 Monitoring    : htop

Last login: Fri Aug 22 09:00:15 2025 from 10.0.0.36
root@nanopi-r3s-lts:~# 

 

As asked before, did you decompress the img before writing? 

[OleksandrK]

1 hour ago, c0rnelius said:

As asked before, did you decompress the img before writing? 

Yes I tried. With no result. I even tried to write (decompressed) image by "gnome disks" graphic tool on Debian. With no result also.
Board behaves like no system on SD (blink red led and no activity led on ethernets, except one on WAN).
So the question is: if to insert properly recorded Armbian SD to x86 Debian, system have to recognize partition and read content of it, right? 

Edited Friday at 10:41 AM by OleksandrK

[c0rnelius]

3 minutes ago, OleksandrK said:

system have to recognize partition and read content of it, right

 

Yes.

 

I also used gnome-disks and didn't bother to decompress, as it is not required to do so. Which img are you writing exactly?

 

[OleksandrK]

10 minutes ago, c0rnelius said:

Yes.

OK. So solution is to properly writing SD.
 

 

10 minutes ago, c0rnelius said:

Which img are you writing exactly?

Armbian_25.5.2_Nanopi-r3s-lts_bookworm_current_6.12.34_minimal
and the same result
Armbian_25.5.2_Nanopi-r3s-lts_noble_current_6.12.34.

Edited Friday at 10:57 AM by OleksandrK

[c0rnelius]

4 minutes ago, OleksandrK said:

Armbian_25.5.2_Nanopi-r3s-lts_bookworm_current_6.12.34_minimal

 

Try the following: Armbian_25.8.1_Nanopi-r3s-lts_bookworm_current_6.12.41_minimal.img

https://dl.armbian.com/nanopi-r3s-lts/Bookworm_current_minimal

[Igor]

I have deployed Debian Trixie from download pages - with success. Moved my HA instance on it without any troubles.

[Werner]

Debug boot issues: https://debug.armbian.de

[OleksandrK]

Hi everyone, and thanks a lot for the help.  
I found the solution: the problem was Windows 11 on my laptop.  

After writing the Armbian image, if the SD card stays inserted, it becomes corrupted within a few seconds.  
This happens only with Armbian and only with R3S images. I have no idea why.  

So, to get a proper SD card, I need quick hands to remove it immediately after the writing finishes (no matter which software is used to write).

[MaxT]

the problem was Windows 11 on my laptop.  
After writing the Armbian image, if the SD card stays inserted, it becomes corrupted within a few seconds.  
This happens only with Armbian and only with R3S images.

It would be interesting to compare corrupt and non corrupt cards, including partition tables, etc.

Windows might be playing bad with partition tables - if one only inserts ESXi boot disk into windows machine, such disk becomes non bootable.

AFAIR this is because ESXi relies on records order in the gpt table of the disk, while windows strips away blank records so that if eg second and third records are blank then windows will move the fourth record to the second place, while ESXi relies on the fourth record in a table.

I personally met this issue a few years ago and it took a while to find the solution of reordering gpt table records back to restore ESXi boot.

[Vlad Kuzin]

I also encountered this trouble with image corruption.

Here's my small research I've made:
1. This appears to be for newer images witch use GPT schema instead of MBR one. I've tried to flash same SD cards (Transcend 1x A1 & 2x A2 class) with orangepi zero2w image from community support build which still comes with MBR schema and had no trouble at all. I've used Rufus 4.9, USBImager and dd from WSL2 for tests. Whoever, images for orangepi 3b & orangepi 5plus already comes with GPT partition schema and flashing them with any software in all combinations of eject time or way (safe or not) always lead to broken GPT table and initramfs on SBC boot.

2. I'm using WSL2 with Ubuntu 24 LTS and usbipd for linking USB devices. After SD flash on Windows side with Rufus or USBImager I'm attach SD card to WSL2 and check it state immediately (on attach windows side does not see usb device anymore). Here's log of this actions (I'm out of free SD cards so first part with image will be from regular USB flash drive).

Rufus output:

Opened \\.\PhysicalDrive2 for exclusive write access
Requesting logical volume handle...
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Opened \\.\PhysicalDrive2 for shared write access
Timeout while waiting for logical drive

Found USB 3.0 device 'Kingston DT microDuo 3C USB Device' (0951:16AE)
No logical drive found (unpartitioned?)
1 device found
No volume information for drive 0x82
Disk type: Removable, Disk size: 64 GB, Sector size: 512 bytes
Cylinders: 7538, Tracks per cylinder: 255, Sectors per track: 63
Partition type: GPT, NB Partitions: 1
Disk GUID: {61DF6BA5-465D-4529-80C4-5D4BB9D0852F}
Max parts: 128, Start Offset: 1048576, Usable = 62007524864 bytes
Partition 1:
  Type: Linux Boot Partition (ARM64)
  Name: 'rootfs'
  Detected File System: ext4
  ID: {22DE0E86-86CD-4366-AF3C-07E25D0E77FA}
  Size: 5.9 GB (6382682112 bytes)
  Start Sector: 32768, Attributes: 0x0000000000000000

WSL2 bind & attach process:
 

PS C:\Users\mevep> usbipd list
Connected:
BUSID  VID:PID    DEVICE                                                        STATE
2-8    0403:6001  USB Serial Converter                                          Not shared
2-23   0951:16ae  USB Mass Storage Device                                       Shared

PS C:\Users\mevep> usbipd bind --busid 2-23

PS C:\Users\mevep> usbipd attach --wsl --busid=2-23
usbipd: info: Using WSL distribution 'Ubuntu-20.04' to attach; the device will be available in all WSL 2 distributions.
usbipd: info: Loading vhci_hcd module.
usbipd: info: Detected networking mode 'nat'.
usbipd: info: Using IP address 172.21.16.1 to reach the host.

Rufus output after attach to WSL2:

0 devices found

WSL2 sudo parted -l output:

/mnt/c/Users/mevep$ sudo parted -l
Error: The primary GPT table is corrupt, but the backup appears OK, so that will
be used.
OK/Cancel? OK
Model: Kingston DT microDuo 3C (scsi)
Disk /dev/sdg: 62.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name    Flags
 1      16.8MB  6399MB  6383MB  ext4         rootfs

Trying to mount:

/mnt/c/Users/mevep$ sudo mount /dev/sdg1 /mnt/mp
mount: /mnt/mp: special device /dev/sdg1 does not exist.
       dmesg(1) may have more information after failed mount system call.

gdisk output:

/mnt/c/Users/mevep$ sudo gdisk /dev/sdg
GPT fdisk (gdisk) version 1.0.10

Caution! After loading partitions, the CRC doesn't check out!
Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!
Main header: OK
Backup header: OK
Main partition table: ERROR
Backup partition table: OK

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

Recovery/transformation command (? for help): v

Problem: The CRC for the main partition table is invalid. This table may be
corrupt. Consider loading the backup partition table ('c' on the recovery &
transformation menu). This report may be a false alarm if you've already
corrected other problems.

Warning: There is a gap between the main metadata (sector 1) and the main
partition table (sector 2016). This is helpful in some exotic configurations,
but is generally ill-advised. Using 'j' on the experts' menu can adjust this
gap.

Identified 1 problems!

Output after gdisk r c w commands (everything is ok now):

Recovery/transformation command (? for help): c
Warning! This will probably do weird things if you've converted an MBR to
GPT form and haven't yet saved the GPT! Proceed? (Y/N): Y

Recovery/transformation command (? for help): W

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): Y
OK; writing new GUID partition table (GPT) to /dev/sdg.
The operation has completed successfully.

/mnt/c/Users/mevep$ sudo parted -l
Model: Kingston DT microDuo 3C (scsi)
Disk /dev/sdg: 62.0GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start   End     Size    File system  Name    Flags
 1      16.8MB  6399MB  6383MB  ext4         rootfs

/mnt/c/Users/mevep$ sudo mount /dev/sdg1 /mnt/mp
/mnt/c/Users/mevep$ ls /mnt/mp
bin                boot  etc   lib                lost+found  mnt  proc  run   sbin.usr-is-merged  snap  sys  usr
bin.usr-is-merged  dev   home  lib.usr-is-merged  media       opt  root  sbin  selinux             srv   tmp  var

Also I have UART logs of trying to boot from SD card SBC without any changes after image burn, but nothing interesting there - it just goes initramfs after kernel boot start process. Added log file to this post for orangepi 3b. Same appears for orangepi 5plus. Image built with armbian-build commit 1d89b0e1e0e6a8b053a94a41a8d0b961f38a9fae by me.
COM6_2025_08_21.txtCOM6_2025_08_21.txt 

3. After SD card recovery everything boots and works fine. Tested on custom build images with armbian-build commit 1d89b0e1e0e6a8b053a94a41a8d0b961f38a9fae for orangepi 3b & 5plus.

4. I'm on Windows 11 24H2

Maybe it will help somehow :^)

Edited 5 hours ago by Vlad Kuzin