Score:1

Make ubuntu 20.04.2 desktop custom LiveCD encounter Check finished: errors found in 1 files! You might encounter errors

bg flag

I make a usb Ubuntu LiveCD 20.04.2 desktop version via this article.

I had check my original iso sha256 is correct. Also I had check usb block via rufus. And the result is 0 bad blocks found. (0/0.0 errors)

But after flash the iso via Windows rufus. And boot in uefi mode. It may encounter:

 Check finished: errors found in 1 files! You might encounter errors.

What I encounter like this Check finished errors found in 1 file. But there is no answer in the end.

Is there any way to dump the check disk information message result or the inspect file /boot/grub/efi.img is correct/incorrect ?

I had check the path /cdrom/boot/grub/efi.img which is equal in md5sum.txt

There are some articles relate this problem Check error with 20.04-desktop ISO , Check error with 20.04-desktop ISO but not about make the live cd.

galexite avatar
pk flag
Is the error reported as in `efi.img`? It looks like it can be any one of those files, just that those issues you mentioned directly talked about an error in that file.
galexite avatar
pk flag
Can you use `md5sum -c md5sum.txt | grep -v OK` on the USB drive root, and see which file is not listed as `OK` in the output?
laudai avatar
bg flag
The check result is `./isolinux/isolinux.bin` is FAILED. Does it be normal or unusually ?
laudai avatar
bg flag
And why rufus change my file ?
laudai avatar
bg flag
@galexite Finally, I check the [article](https://help.ubuntu.com/community/LiveCDCustomization#Producing_the_CD_image) and confirm `isolinux.bin` is modified by `mkisofs -b`. It may cause the `isolinux.bin`'s md5sum change after use this command. No changed by rufus software.
Score:1
bg flag

The reason why encounter error is that md5sum script in the Ubuntu LiveCD article.

This script in nowadays will product the isolinx directory md5sum. Which is not hash on official Ubuntu's 20.04.2 image.(Maybe the wiki need to be modified. You can see the beginning of article is ubuntu-18.04-desktop-amd64.iso. But end of article is ubuntu-9.04.1-desktop-i386-custom.iso.)

To avoid this problem. You can modified the script from

find -type f -print0 | sudo xargs -0 md5sum | grep -v isolinux/boot.cat | sudo tee md5sum.txt #original

to

find . -type f -not -name md5sum.txt -not -path '*/isolinux/*' -print0 | sudo xargs -0 md5sum | grep -v isolinux/boot.cat | sudo tee md5sum.txt #other people purposal

In this issue. It doesn't cause by the Windows rufus ESP problem. Althought the rufus may cause the same problem.(like @Akeo said. rufus update in 3.15. In this changelog)

Score:0
hk flag

This is normal. The problem is that efi.img gets mapped to the ESP (EFI System Partition), which Windows tries to mount after the USB is created and, when it does, it creates a System Volume Information\ directory in there. This is an (obnoxious) default Windows behaviour which we can't really control.

The end result is that the ESP is modified, which means that boot/grub/efi.img is modified and therefore the checksum doesn't match. This is however a benign problem that is not indicative of an actual issue.

The newly released Rufus 3.15 tried to add provisions against Windows altering the ESP, so that the checksum should match, but there's really only so much we can do against Windows' default behaviour, and, ideally, Ubuntu (and other distros) would probably be better off not trying to add more ISOHybrid hacks in order to map an ESP onto a file that gets checksummed, and instead just use a single partition, with the EFI and installation content, when the image is written in DD mode...

galexite avatar
pk flag
Thanks for creating Rufus, @Akeo! It appeared in the end Rufus/Windows was not at fault at all, and that Ubuntu's check simply runs through an `md5sum` file, so it doesn't seem to care about extra files on the ESP. OP had modified their ISO with `mkisofs`, and as it turns out, this created a new `isolinux.bin` which did not match the hash.
laudai avatar
bg flag
@Akeo Thanks for devote into Rufus. As @galexite mention it is the `isolinux.bin` hash did not match. All the information have been write to below answer.
Akeo avatar
hk flag
Glad to see you figured out the cause. I mentioned the issue with `efi.img` because I've seen it leading to failed checksum validation with Ubuntu images written in DD mode in the past, so it may help others who stumble on this issue and find that it's their `efi.img` that is failing validation.
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.