Installing from ISO leads to decompress errors

I first tried installing from an ISO file for two times on a bare metal system, which always resulted in strange zsdt decompression errors.


  • brand-new 32 GB large microSD card
  • with an older, but working USB-(micro)SD card adapter (I’m out of spare USB drives, so I though this was a clever idea… :stuck_out_tongue_winking_eye:)


I basically just followed the official doc here by installing the CoreOS system:

$ coreos-installer download -s stable -p metal -f iso -C ./downloads --decompress

The current CoreOs version has been downloaded, which I used, i.e. fedora-coreos-33.20210328.3.0-live.x86_64.iso.

Then “burning” that image to that external drive (in my case SD card) and booting from it.

What happened

As said I tried that two times and both times it failed with some error like:

[…] SQUASHFS error: zstd decompression error[…]
[…] SQUASHFS error: zstd decompression failed, data probably corrupt[…]

…followed by some “Unable to rad page, block/fragment cache entry" etc.

Here is a full image:

As said I thought it was just some error when “burning” the image to the “disk” (=sd card), so I tried again… which failed, too. So far… so strange.


I just thought I’d report it here. Let me know if you think this is just some (random?) hardware failure or where I should report it, if it is something interesting…

In any case IÄm surprised as the SD card is new and thus likely has no fault.

Hmm, that’s definitely odd. It seems like the root squashfs on the ISO is corrupted. Could you double-check that it was written to the SD correctly by reading back from it and comparing to the downloaded ISO file?

Well… one thing it certainly did was to expand the root FS to the full SD card, so I’m afraid to read all 29GB of /dev/zero data:

I’ll have to look how to read that quickly…

Edit: Okay, I’ll try it like this.

Hm tried the linked question with cp --sparse=always and dd conv=sparse from here, but I always just got a 32Gb file.
I guess it wrote some bytes at the end of the partition or so and not only “just expand” it.

Now had an idea to just change the partition size back on the SD card, but GParted does not let me do this arg…

You only have to read the first N bytes of the SD card, where N is the size of the ISO. Something like:

$ dd if=/dev/mmccblk0 count=N bs=1 | sha256sum

Uhm dd if=disk.image count=8049257792 bs=1 of=disksmall.img (for an ISO size of 804.257.792 Bytes) went bad (was horribly slow) and copied more than 1 GB…

You have an extra 9 in your count.

If you want to speed up the copy and have a decent amount of RAM, you could swap the bs and count.

Oh of course, sorry.

Okay, so the result. The files differ, indeed.

$ diff -u disksmall.img ../downloads/fedora-coreos-33.20210328.3.0-live.x86_64.iso
Binary files disksmall.img and ../downloads/fedora-coreos-33.20210328.3.0-live.x86_64.iso differ
$ sha256sum disksmall.img 
d7a55ade23af0c765cdbc2afa4f85fb6e1cba68dbdea3755f5e5b6df7aeb1b42  disksmall.img
$ sha256sum ../downloads/fedora-coreos-33.20210328.3.0-live.x86_64.iso 
685fa6f19133410c127d2a31c52750becc9fe1a3bfc9231df20daf52914953d5  ../downloads/fedora-coreos-33.20210328.3.0-live.x86_64.iso
$ cmp -l disksmall.img ../downloads/fedora-coreos-33.20210328.3.0-live.x86_64.iso | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'|head -10

00000001 00 33
00000002 00 ED
00000003 00 90
00000004 00 90
00000005 00 90
00000006 00 90
00000007 00 90
00000008 00 90
00000009 00 90
0000000A 00 90

The cmd command is from here. I shortened it as it just was a huge long list of diffs.

$ xxd disksmall.img > disksmall.img.hex
$ xxd ../downloads/fedora-coreos-33.20210328.3.0-live.x86_64.iso > ../downloads/fedora-coreos-33.20210328.3.0-live.x86_64.iso.hex
$ diff disksmall.img.hex ../downloads/fedora-coreos-33.20210328.3.0-live.x86_64.iso.hex > diff-iso-hex.diff # that took 1m 46s :o

So the resulting diff-iso-hex.diff has a size of 7 GiB, Bytes. :astonished:

After all, maybe it could be some error with the SD card or SD card reader. Would not it be a good idea to include a self-check (for first boot) in CoreOS then as some installer ISOs from some Linux distros do? (They verify checksums AFAIK.)