FS corrupted after burning image to SD card

[ChrisO]

Hi

I dd the Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img to a SD card (/dev/sdc) and then run a
fsck -f /dev/sdc1 and got errors:
sudo fsck -f /dev/sdc1
fsck from util-linux 2.39.3
e2fsck 1.47.0 (5-Feb-2023)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Entry '.' in ??? (1065) is duplicate '.' entry.
Fix<y>? 
....

Tried few SD cards, same result.
Tried those SD cards with other images, i.e. Armbian_24.8.4_Rock-5c_bookworm_vendor_6.1.75_minimal.img
no problems.
Could anybody verify this behavior?

Thanks
Chris

 

Armbian_25.11.1_Rock-5c_trixie_vendor_6.1.115_minimal.img image generates the same problem.

Edited 22 hours ago by ChrisO
typo, added a sentence

[laibsch]

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)

[Werner]

6 hours ago, laibsch said:

Balena Etcher

This is not recommended. https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card

[ChrisO]

I do verify what is written to the SD card. It's a homegrown script I have used for at least ten years. It's not the cause of my problem.

And as for all those shiny clicky-clickity tools, no thanks! I prefer to know what is going on on my computer.

 

Any comments on my question, anyone? If anybody could write one of the images using his his preferred/recommended imaging tool and run fsck on the resulting partition it would help me much.

Thank you.

Edited 9 hours ago by ChrisO

[Werner]

May I ask why you do this fsck? Is there a problem with the image like not booting?

[ChrisO]

This is really a strange question, Werner. fsck for filesystems like ext2/3/4 is for a purpose, no?

But here you go.

Normally when I install a new system, configure it to my needs and liking I make a backup image of it.

To let say quickly restore after breaking the system with some "experiments" or such. Is much easier then install from scratch.

As first step in this procedure i shrink the filesystem on the 1st partition which requires a fsck -f on it. Theodore's telling us to do so, he must know why 🙂

So I discovered those two images I mentioned give me filesystem errors.

As there is nobody in my neighborhood messing up with Armbian, I asked here for help. If somebody could try to see if he/she reproduced my problem.

Instead I was instructed what tools are recommended (by whom?) and "scolded" for using fsck. 🙂

BTW, after fsck lost+found contains several hundreds of files, most of them .c/.h from kernel source/headers.

Thanks.

[eselarm]

See my 'dry' test:

 

# cat Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz.sha
80ffb7486a9d9950c2613f42be520c4086d4a3b894da4fd46a07120ecd9ddb30 Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz
# sha256sum -c Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz.sha
Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz: OK
# xzcat Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.xz > Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img
# losetup --show -fP Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img
/dev/loop0
# sudo fsck -f /dev/loop0p1  
fsck from util-linux 2.41
e2fsck 1.47.2 (1-Jan-2025)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
armbi_root: 64131/123136 files (0.1% non-contiguous), 441689/492539 blocks

# losetup -d loop0

So can't reproduce.

 

I won't write it to real SD-card and then do the fsck. You can try this first, so via loop device. My computer is Armbian Trixie edge 6.18.0-rc7 NanoPi-R6C, .xz file downloaded on N100, so could also done it there, does not matter Ext4 is Ext4.

 

Edited 3 hours ago by eselarm

[ChrisO]

I should have mentioned, I tried fsck on loop device and it was fine. It's what I cannot understand.

In my script after writing the image I read it back and compare with the source:

dd status=progress if=Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img of=/dev/sdc bs=1M conv=fsync
2032140288 bytes (2.0 GB, 1.9 GiB) copied, 79 s, 25.7 MB/s2034237440 bytes (2.0 GB, 1.9 GiB) copied, 79.2902 s, 25.7 MB/s

Reading image from disk ...
dd status=progress if=/dev/sdc of=Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.from-disk bs=1M count=1941
2032140288 bytes (2.0 GB, 1.9 GiB) copied, 127 s, 16.0 MB/s

 

They are equal in size. Produce same SHA hash:

$ sha256sum Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img*
ab74fc6f34f4f235ca224bc8d282feb1acf94cfe56bdf0b93c21894838ea0c71  Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img
ab74fc6f34f4f235ca224bc8d282feb1acf94cfe56bdf0b93c21894838ea0c71  Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img.from-disk

 

Tried also simple cmp on image file and SD card:

 

$ sudo cmp Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img /dev/sdc
cmp: EOF on Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img after byte 2034237440, in line 14175730

 

See, after byte 2034237440, so the 2034237440 bytes are equal on disk and on the SD card, .img is 2034237440 bytes of size:

$ stat Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img
  File: Armbian_25.11.1_Rock-5c_trixie_current_6.12.58_minimal.img
  Size: 2034237440    Blocks: 1643993    IO Block: 131072 regular file

 

$ sudo -fn /dev/sdc1 
gives FS errors, hundreds of "Unattached inode" and such.
Pass 5: Checking group summary information

armbi_root: ********** WARNING: Filesystem still has errors **********

armbi_root: 64131/123136 files (0.1% non-contiguous), 441689/492539 blocks

 

Voodoo? 😉

 

A spare SD card anyone to try it: 🙂

[eselarm]

I think there is something wrong with the whole chain from 'computer-RAM down to SD-card itself'. I state it like this because there can be many points where the root-cause is.

An issue like this I have seen several times before, and I think I also have had it myself, but was several years ago. /dev/sdc means you use some USB attached mmc, so even if sequential reads and writes work fine, certain pseudo random scattered small blocks can maybe hit some corner-case in the whole Linux I/O in combination with out-of-spec hardware; can be power issue internally in the SD-card adapter, anything.  Also the SD-card itself might do very strange things internally, you don't know, it is some micro-controller firmware. Even if not counterfeit or just fake. Check CID and/or post here maybe.

 

So to avoid at least USB adapter issues, I have used my RPI4 that runs from USB3-SATA SSD  as SD-card reader/writer for images for for example a nanopineo. So then in the RPi4 , it is /dev/mmcblk0 you operate on. My NanoPi-R6C runs from eMMC+NVME, so also there /dev/mmcblk0 is free to use for image writing. Advantage is also that those SBC native slots do support trim, so to also internally wipe SD-card I do 'sudo blkdiscard /dev/mmcblk0' sometimes first, than all is fast and freely available. This command actually failed on some details for some SD-card brand when in ROCK3A SD-card slot for some kernel version. Also A2 SD-card and faulty queuing can randomly corrupt things.