RFE: [ubuntu installer and] make-kpkg should be resilient to failure of mkinitramfs

Bug #112365 reported by Marty Vona
4
Affects Status Importance Assigned to Milestone
kernel-package (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: kernel-package

For whatever reason it appears that the initial install of /usr/sbin/mkinitramfs on one of my systems, as laid down by the ubuntu 7.04 installer, was borked. The file was present, had the same date and size as on another (working) ubuntu 7.04 system, but would not run. Attempting to run it gave the error "binary file not executable". The execute bits were set. Further, diff reported that the binary file contents of /usr/sbin/mkinitramfs *did* differ from the same file on the other system.

Obviously this is bad. Only explanation I can think of is that there was some hardware issue, possibly with the cdrom drive or the hard drive or their respective controllers, during the install. Note: such issues *do* occur and *do* need to be dealt with if we want our installers to be truly reliable and usable by everyone. I have (sadly) installed many many versions of Microsoft operating systems on this particular machine over the years and have never had such a problem.

What is prompting me to write this RFE in particular is that it took a lot of sleuthing to find this problem because, apparrently, make-kpkg (and the ubuntu installer, which I'm assuming is using make-kpkg or something very similar under the hood, is it?) does not check for such an error, and does not fail. It simply does not generate the initrd file, even when --initrd is specified. Attempting to boot the new kernel then fails of course with the dreaded

kernel panic VFS: Unable to mount root fs on unknown-block(0,0)

because there is no initrd file from which the new kernel can get the necessary filesystem and disk hardware driver modules.

I ran into the problem in two contexts before I discovered the borked mkinitramfs binary.

First, the original install (from the live cd), which appeared to complete correctly and fully, and presented me with the usal reboot now dialog and no particularly worrysome error messages, failed promptly on reboot with the above kernel panic. I was able to recover from that and boot the new system only by booting again from the live cd (which takes forever on this system at least in part due to the live cd kernel timing out multiple times trying to access a nonexistent floppy drive "fd0", but that issue seems to be already filed) and using the live cd to manually run mkinitramfs (from the live cd's filesystem, not the borked mkinitramfs on my hard drive, I still wasn't aware of that at this point) to generate an initrd into the boot partion on my hard drive. I noted that the file /boot/initrd.img-2.6.20-15-generic.bak was present on the hard drive boot partition, but that the much more pertinent /boot/initrd.img-2.6.20-15-generic was *not* present until I manually created it. I believe I also had to manually add an initrd line to the relevant stanza in /boot/grub/menu.lst.

That got me booting the new install. But I should not have had to do that. The installer should have detected the problem and at least issued a severe warning. At best, it should have used debsums to figure out that the initramfs-tools install was borked, reinstalled it, verified that the new install was ok, and then regenerated the initrd. I may be a bit misled here, of course. Does the installer really use the mkinitramfs binary on the target filesystem to create the initrd? I'm assuming it does based on my observations, but I could easily be wrong. It is definitely true that there was no working initrd on my system though after the installer claimed to have suceeded (just the .bak file).

The second context was that, after I got my system to boot, I built a custom kernel (primarily because the boot with the generic kernel was still quite slow right at the very beginning, and I suspected that it was again looking for hardware I didn't actually have, maybe trying to restore a nonexistent hibernated session or something, wasting my time, and then timing out) using make-kpkg --initrd. I then installed the new custom kernel .debs, which appeared to have been created without errors, and which installed without warning, and again on reboot promptly got the "kernel panic ... unable to boot ..." problem. So again I dug in and found that no initrd was created (in this case there was neither a .bak file in /boot) nor was an entry for one added to the stanza for my custom kernel in /boot/grub/menu.lst.

At this point I rebooted with the original generic kernel and I finally ran /usr/sbin/mkinitramfs manually, attempting to generate the missing initrd, and finally discovered that it was borked. apt-get install --reinstall initramfs-tools fixed the problem and got me a running mkinitramfs. [I did not know about debsums at the time.]

Hardware: this is an older (circa 2002) Dell laptop with an Intel IDE chipset and an internal cdrom module.

Additional note: I eventually found at least one more file which was borked on install, /usr/lib/libglib-2.0.so.0.1200.11. Again the file was present and had the same date and size as the same file on another system, but diff reported different binary contents. And this appears to have caused applications using VTE (including, painfully, gnome-terminal and update-manager) to segfault. I'm going to enter a separate issue for that, but I'll note it here just so that everyone knows mkinitramfs was indeed not the only borked file after the install.

Revision history for this message
Marty Vona (vona) wrote :

Forgot to mention: I did run the media verify on the install cd, and it did not report any problem.

Revision history for this message
Andreas Moog (ampelbein) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Has that happened with latest Ubuntu release? Thanks in advance.

Changed in kernel-package:
assignee: nobody → andreas-moog
status: New → Incomplete
Revision history for this message
Marty Vona (vona) wrote : Re: [Bug 112365] Re: RFE: [ubuntu installer and] make-kpkg should be resilient to failure of mkinitramfs

You can close this if you want, I don't care about it anymore.

Marty

Andreas Moog writes:
> Thank you for taking the time to report this bug and helping to make
> Ubuntu better. You reported this bug a while ago and there hasn't been
> any activity in it recently. We were wondering is this still an issue
> for you? Has that happened with latest Ubuntu release? Thanks in
> advance.
>
> ** Changed in: kernel-package (Ubuntu)
> Assignee: (unassigned) => Andreas Moog (andreas-moog)
> Status: New => Incomplete
>
> --
> RFE: [ubuntu installer and] make-kpkg should be resilient to failure of mkinitramfs
> https://bugs.launchpad.net/bugs/112365
> You received this bug notification because you are a direct subscriber
> of the bug.

Revision history for this message
Andreas Moog (ampelbein) wrote : Closing this Bug since there was no Information provided

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

We are closing this bug report as requested. Thanks again!

 status invalid
 assignee nobody

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiu4AUACgkQ06FgkPZwicT56wCg4Zi/pUptr2tsRcXvuxePsUcF
JcEAoMlN9MSj41ChtGmpMuSp/K3y9VVS
=+f4w
-----END PGP SIGNATURE-----

Changed in kernel-package:
assignee: andreas-moog → nobody
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.