Join Log in
Score:0
doetoe avatar Ubuntu

Why does the installer keep crashing when copying the files? I checked everything

cn flag
doetoe

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!

45
0 + 0
usb
guiverc avatar
cn flag
guiverc
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?
0
Reply
guiverc avatar
cn flag
guiverc
Does this answer your question? [Why do I see a message SQUASHFS ERROR:UNABLE TO READ DATA AND PAGE WHILE INSTALLING UBUNTU](https://askubuntu.com/questions/1236021/why-do-i-see-a-message-squashfs-errorunable-to-read-data-and-page-while-install)
0
Reply
doetoe avatar
cn flag
doetoe
@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.
0
Reply
doetoe avatar
cn flag
doetoe
@guiverc Thanks for the link, I'll check it out
0
Reply
doetoe avatar
cn flag
doetoe
@guiverc sorry, versions 20.04.3, also changed it in the main body
0
Reply
guiverc avatar
cn flag
guiverc
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
0
Reply
doetoe avatar
cn flag
doetoe
@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!
0
Reply
ChanganAuto avatar
us flag
ChanganAuto
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.
0
Reply
doetoe avatar
cn flag
doetoe
@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
0
Reply
guiverc avatar
cn flag
guiverc
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
0
Reply
guiverc avatar
cn flag
guiverc
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
0
Reply
guiverc avatar
cn flag
guiverc
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.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.