File (.xz) less than 1M, it extracts to 1444M, only 836k content, rest is sparse. Only U-Boot is written It looks like. So clearly image generation failed.

Does it fail to assemble image? Or you can make image but image is corrupted? For that part we have an explanation: https://docs.armbian.com/User-Guide_Getting-Started/#flash-to-sd-card

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.

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: 🙂

My intention is not to put the whole desktop on the display. Just a user application. I am trying to build a thermostat and might use LVGL for it. I tried a similar project on 256MB and still had plenty of RAM left.