Public bug reported:
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.
** Affects: kernel-package (Ubuntu)
Importance: Undecided
Status: Unconfirmed
--
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 member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
