Booting from 8GB usb3 thumb drive, which is fully updated (x64).
Unfortunately I had a faulty 4TB Seagate USB enclosure which crashed the system twice or three times yesterday (since replaced with a generic enclosure working fine.) But now I am noticing from dmesg,
SQUASHFS error: xz decompression failed, data probably corrupt
SQUASHFS error: squashfs_read_data failed to read block 0x2bdea53d
SQUASHFS error: Unable to read fragment cache entry [2bdea53d]
SQUASHFS error: Unable to read page, block 2bdea53d, size b3e80
I used md5sum on all files but that did not trigger any addition squashfs messages. Also ran MemTest86+ for a couple hours. Other than the dmesg log entries, nothing is actually crashing or acting oddly.
Is there a way to determine what exactly is corrupted on the USB thumb drive? I could just start over … ugh. Is there fsck for squashfs? The USB drive has like 2.5GB overlaying the base image (all openSUSE updates).
Ah, the only squashfs mount is read-only, that’s interesting.
Installed squashfs, and ran
unsquashfs -d /path/to/extract/to /dev/loop0
and it was clean. So, either it’s a squashfs bug, or glitchy hardware though I haven’t had any problems with this PC otherwise. It only seems to happen once per boot in the dmesg, not repeatedly. Hmm, maybe a flaky USB thumb drive.
Did you install to the thumb or did you just image the ISO to the thumb and run as a live image??
Note that thumb drives use flash memory and flash has a limited number of erase cycles. Also unlike SSD’s thumbs don’t have write leveling algorithms so wear out relatively fast if you write/change a lot of data. By default the file system will normally write the time each file is accessed. This can be a lot. Also a lot of temp files are writen then discarded. this puts a heavy load on the poor flash memory. Don’t expect that the thumb drive to last very long
Imaged the ISO to the thumb and run as a live image. Was that bad?
These are just small 8GB usb thumb drives for my live linux uses. (My permanent install is openSUSE in vbox in win7 on ssd.) In this case, I am backing up the PC’s drives from the live linux thumb drive to an external drive overnight.
My web research indicates usb thumb drives have had wear leveling for at least a decade already. You’re thinking of raw nand storage.
Not really not the same as SSD. Thumb drives will wear out much much quicker then an SSD. You think they sell devices for $10.00 that are equal to devices they sell for $100.00 There is a reason you pay that premium
In any case SquashFS is what is used by the ISO image. Nothing wrong with that just trying to see why you are using it at all.
If it is juist a note in the logs and you see no other problem ignore it. Maybe a timing problem that the drive is not ready as soon as power comes on. Who knows. If it does not appear to be a real problem let it go.
Also you should follow the recommendations of SSD usage to minimize wear on the memory.
It’s some time after boot completes, like one minute to an hour before the error pops up in dmesg. I have to use a live usb (or CD) to do the offline PC backup. Monthly rotated mirrors. Well, I could use a non-persistent image that is read-only, but I don’t remember seeing that option for 13.2? Previously I was using a non-persistent old Kubuntu live image, but it’s pretty old now – trying to update! Maybe I can coax the error out with repeated md5sum. Data integrity is important!
Oooh, md5sum /dev/loop0 flip-flopping between 3 different checksums! Probably the thumb drive. =/
Yup, dumped out /dev/loop0 twice, then used “cmp -l” … there are 4 bytes with bit 0x2 flipped. Bad USB drive. And it’s brand new!!!