RFE: consider using debsums to improve reliability of install process

[Marty Vona]

Binary package hint: debian-installer

It appears that my fresh install of ubuntu 7.04 laid down a a few faulty binary files, including

/usr/sbin/mkinitramfs
/usr/lib/libglib-2.0.so.0.1200.11

In each case the file was present and had the correct size and date, but had different binary contents than the same file on (what should have been) an identical system.

I did run the installer media check, and it did not report any problems.

Needless to say, this was very bad, and caused subtle but major issues as I attempted to use the new system. The corruption of mkinitramfs appears ultimately to have led to the absence of initrd files, which made boots fail with the dreaded "kernel panic VFS: Unable to mount root fs on unknown-block(0,0)." The libglib problem appeared to affect all applications using the VTE library (though not many other applications). So I could log in to gdm without error but I could not launch gnome-terminal (the launch silently failed due to a segfault; it should not have been silent imo and I did file a separate RFE for that). I also could not run update-manager.

I have gotten around these problems with the help of apt-get install --reinstall and the live cd. It is not my intention to file these as a bug per se. Rather, I suggest an RFE to improve the reliability of the ubuntu installer, going beyond the optional media check, and actually verifying the contents of the binary files laid down on the target disk. Perhaps debsums could rise to the task. I was unable to find any existing threads or RFEs on this topic.

Yes, it's likely there was some hardware issue, possibly with the cdrom drive or the hard drive or their respective controllers, during the install. Such issues *do* occur and *do* need to be dealt with if we want our installers to be truly reliable and usable by everyone and their mom. I have (sadly) installed many many versions of Microsoft operating systems over the years, on this particular machine and on many others, and have never had such a problem.

Perhaps there is concern that debsums or something similar would slow down installs. It could be optimized, it could be localized to a potentially relatively small set of critical system files, and it could be made optional. Having had this experience, and other related ones over many years of installing many distros on many hardware configurations, I would definitely take the option. I'm sure the extra time in the install would be minimal compared to the 14 hours I spent yesterday finding and fixing these issues.

Maybe there is also concern that debsums itself could fail, and that it would not be able to solve all possible problems, especially with truly failing hardware. Of course those issues exist, but we can still do what we can. I dream of the day that I'll be able to hand my mom an ubuntu installer disk and be reasonably confident that she'll succeed if success is at all possible.

[Colin Watson (cjwatson)]

Did you install using the desktop CD or the alternate install CD? I ask because squashfs in Feisty is known not to detect errors properly, which can often cause issues like this; the upstream maintainer of squashfs has been working on this, and it should be corrected in Gutsy

[Marty Vona (vona)]

I used the Desktop CD.

In fact I used the very same CD to install on two different machines. One had this issue and the other did not.

Colin Watson writes:
> Did you install using the desktop CD or the alternate install CD? I ask
> because squashfs in Feisty is known not to detect errors properly, which
> can often cause issues like this; the upstream maintainer of squashfs
> has been working on this, and it should be corrected in Gutsy
>
> --
> RFE: consider using debsums to improve reliability of install process
> https://bugs.launchpad.net/bugs/112398
> You received this bug notification because you are a direct subscriber
> of the bug.

[Colin Watson (cjwatson)]

This was fixed in Ubuntu 8.04:

ubiquity (1.7.8) hardy; urgency=low

  * Check the md5 hash of the source and target files on copy to ensure they
    match, giving the user the option to abort, retry, or skip the file.
  * The md5 check can be disabled by preseeding
    ubiquity/install/md5_check to false.
  * Catch exceptions around the processing of each components run()
    function.
  * seteuid as a regular user until we need to do something as root.
  * Automatic update of included source packages: partman-target
    52ubuntu5.

 -- Evan Dandrea <email address hidden> Fri, 15 Feb 2008 00:10:18 -0500