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 19 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 6 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 25 minutes ago by eselarm