0

I've been trying to install Ubuntu on an old laptop this weekend, a Sony Vaio PCG-6S4M / VGN-SZ61MN, for if that is relevant. I start using a live USB (on a micro SD card actually), but when it gets to the point where the files are copied, it crashes:

The installer encountered an error copying files to the hard disk

When I call dmesg afterward, the output toward the end contains something like this:

[  450.928749] perf: interrupt took too long (3932 > 3930), lowering kernel.perf_event_max_sample_rate to 50750
[  608.661461]  sda: sda1 sda2 < sda5 sda6 >
[  610.596440] Adding 1951740k swap on /dev/sda5.  Priority:-2 extents:1 across:1951740k FS
[  636.547888] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: errors=remount-ro. Quota mode: none.
[  636.637761] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[  666.058175] SQUASHFS error: zlib decompression failed, data probably corrupt
[  666.058188] SQUASHFS error: Failed to read block 0xb8f39ff: -5
[  666.058192] SQUASHFS error: Unable to read fragment cache entry [b8f39ff]
[  666.058196] SQUASHFS error: Unable to read page, block b8f39ff, size 8df3
[  666.058250] SQUASHFS error: Unable to read fragment cache entry [b8f39ff]
[  666.058253] SQUASHFS error: Unable to read page, block b8f39ff, size 8df3
[  666.058250] SQUASHFS error: Unable to read fragment cache entry [b8f39ff]
[  666.058253] SQUASHFS error: Unable to read page, block b8f39ff, size 8df3

The block and size are different in different intents, though I got this size 8df3 twice.

When the live system is loaded, I can use Ubuntu just fine without apparent problems, it is only when installation starts, after the partitions have been created.

I checked everything I could come up with of what could have gone wrong:

  • The installation device: I tried four different micro SD cards with two different card readers
  • The Ubuntu image: I tried both Ubuntu 20.04.3 and Ubuntu Mate 20.04.3, desktop version. I verified the checksum after downloading, and then again the checksum on the card, using dd if=/dev/sdX count=... | sha256sum. It checked out in all cases.
  • The hard disk drive: I tried with two different HDD's. Also checked using smartctl.
  • RAM: performed a memory test from the live USB, which passed.

Where else could it have gone wrong? How can I diagnose it? Any ideas?

EDIT I may have some more relevant information. First let me clarify that the image on the SD card is almost certainly good:

  • I checked the sha256sum of the downloaded ISO
  • I wrote the ISO to the device using dd, then checked the same sha256sum on the device itself using dd again: dd if=/dev/sdX count=... | sha256sum.
  • I checked all md5sums listed in md5sum.txt by executing md5sum -c md5sum.txt.

What I found out is this: when I check the hashes again on the target computer, it gives an erroneous value of the file casper/filesystem.squashfs most of the time, and moreover always different. This is by far the largest file at around 2GB. For if it is relevant: the laptop also has 2GB of RAM. The file does not actually get corrupted: when I check it again on the newer computer, the checksum is good. Note that this happens on different SD cards.

Thanks!

doetoe
  • 111
  • Squashfs errors are errors usually on your installation media; was it validated? ie. did you firstly validate the ISO being correct before write to media, and then validate the media write as per instructions for your unstated product/release of Ubuntu? – guiverc Jan 23 '22 at 21:03
  • Does this answer your question? Why do I see a message SQUASHFS ERROR:UNABLE TO READ DATA AND PAGE WHILE INSTALLING UBUNTU – guiverc Jan 23 '22 at 21:03
  • @guiverc Yes, I checked the sha256 of the downloaded ISO, then I checked it again on the installation medium after copying it using dd, and also checked the hashes against the included sha256sums.txt. Moreover I did this several times and with different releases: Ubuntu desktop 21.04.3 and Ubuntu Mate desktop 21.04.3. – doetoe Jan 23 '22 at 21:24
  • @guiverc Thanks for the link, I'll check it out – doetoe Jan 23 '22 at 21:25
  • @guiverc sorry, versions 20.04.3, also changed it in the main body – doetoe Jan 23 '22 at 21:34
  • The ISO validate is cheap insurance as I see it, but it's very rare that I find it has issues; the write to media however is a very different story with my finding 5-8% of ISO writes fail using sandisk media & various computers (usually higher failure rate with other brands of media) as the media is cheap (made to cost). It's the validation of media I find most useful in detecting issues; the squashfs errors in your paste show failure to read the installation media (ie. ISO write failed or you have bad thumb-drive media; in my experience). Check your software can write the ISO version – guiverc Jan 23 '22 at 22:12
  • @guiverc I added some new info. It seems highly unlikely that the medium is actually corrupted, but something may go wrong in reading from it on the old laptop (on the new one everything is OK). This happens with several different SD cards. Do you have any idea what might cause something like that? Thanks! – doetoe Jan 24 '22 at 00:28
  • You should consider the possibility of an intermittent problem in the USB port or some weird issue with using media designed for and expecting USB3.x being used in USB2.0 ports. – ChanganAuto Jan 25 '22 at 20:34
  • @ChanganAuto yes, you might be right it is something like that. I actually managed with a USB pendrive (USB 3 indeed, though the potty was only USB 2), and when booting into the installed system (as opposed from the live USB) the checksums are consistently computed correctly from the same SD cards – doetoe Jan 26 '22 at 20:24
  • I write ~300-400 ISOs to thumb-drives per annum a year; and in my experience the write is the most problematic. The software you write to media (be it SD card/usb-thumb-drive etc) must match the ISO being written; as Ubuntu is produced for different architectures; and all of 20.04 will boot the same, all of 20.10 will boot the same, as will 21.04 etc.. however 20.04 boots differently to 20.10, which boots differently to 21.04 etc.. ie. ISO changes between cycles so software must know how to deal with this (esp. if not simple clone done). My guess is bad write of ISO assuming you validated it – guiverc Jan 26 '22 at 20:36
  • If I have problematic boots; I will test on 3 devices (1) the device I want to boot on, (2) another of the same time, (3) a different type of device.. if media validates on 2 & 3 then I assume issue is likely on device 1 (by type I mean similar device; such as same BIOS/uEFI/secure-uEFI & very close firmware/hardware); different being if one is secure-uEFI other is usually BIOS/legacy..). 2GB RAM is not a problem; I still use devices with 2GB for QA-testing flavors, 2GB doesn't meet minimums for Ubuntu Desktop so I don't test that on <4GB. The large single file is what gets installed – guiverc Jan 26 '22 at 20:40
  • FYI: I do perform live testing of Ubuntu Desktop on 2GB devices; just not QA-test installs as the minimum specifications require 4GB; 1GB is required for the installer itself thus I don't do it.. as even if it failed; nothing would be gained as the minimum hardware requirement was 4GB so problems were already documented as box doesn't meet minimum specifications for Ubuntu Desktop. – guiverc Jan 26 '22 at 20:44

0 Answers0