RFE: [ubuntu installer and] make-kpkg should be resilient to failure of mkinitramfs
| 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/
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.
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/
At this point I rebooted with the original generic kernel and I finally ran /usr/sbin/
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/
| Marty Vona (vona) wrote | #1 |
| Andreas Moog (ampelbein) wrote | #2 |
| Changed in kernel-package: | |
| assignee: | nobody → andreas-moog |
| status: | New → Incomplete |
| Marty Vona (vona) wrote Re: [Bug 112365] Re: RFE: [ubuntu installer and] make-kpkg should be resilient to failure of mkinitramfs | #3 |
| Andreas Moog (ampelbein) wrote Closing this Bug since there was no Information provided | #4 |
| Changed in kernel-package: | |
| assignee: | andreas-moog → nobody |
| status: | Incomplete → Invalid |
Forgot to mention: I did run the media verify on the install cd, and it did not report any problem.