initrd.img symlink removed during kernel upgrade

Bug #10641 reported by Andrew Zajac
38
Affects Status Importance Assigned to Milestone
linux-source-2.6.15 (Ubuntu)
Fix Released
High
Ben Collins

Bug Description

This bug (https://bugzilla.ubuntu.com/show_bug.cgi?id=2492) stops the
configuration of packages during a dist-upgrade. Synaptic reports errors and to
scroll up to see them. The errors do not seem serious.

The new kernel-image package which is half-installed has not made its' initrd.
The old initrd is gone. The system is unbootable.

This is reproducable on Warty and on Hoary, but I had to downgrate to a warty
kernel first. This can probably be caused by any "stops configuration of
packages" bug.

Revision history for this message
Jan (debian-gepro) wrote :

I got the same problem when upgrading Hoary from kernel version 2.6.8.1-17 to
2.6.8.1-19. The old initrd.img is removed while the script believes it is a
dangling link and no new gets created. The update from warty kernel to Hoary
2.6.8.1-17 went OK yesterday.

Revision history for this message
Matt Zimmerman (mdz) wrote :

I encountered a similar problem with -19 on powerpc:

Preparing to replace linux-image-2.6.8.1-3-powerpc 2.6.8.1-17 (using
.../linux-image-2.6.8.1-3-powerpc_2.6.8.1-19_powerpc.deb) ...
The directory /lib/modules/2.6.8.1-3-powerpc still exists. Continuing as directed.
Unpacking replacement linux-image-2.6.8.1-3-powerpc ...
The link /boot/initrd.img is a dangling link
Removing symbolic link /boot/initrd.img
 you may need to re-run yaboot
[...]
Setting up linux-image-2.6.8.1-3-powerpc (2.6.8.1-19) ...
Not touching initrd symlinks since we are being reinstalled (2.6.8.1-17)
Not updating image symbolic links since we are being updated (2.6.8.1-17)

Somehow, it looks like mkinitrd was never called at all.

Revision history for this message
Fabio Massimo Di Nitto (fabbione) wrote :

Hi guys,
       the problem seems to be that either the bug
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=281953) hasn't been
fixed properly, or the merge has lost bits somewhere else.

In anycase i need a way to reproduce this bug since i have never been trapped in it.

Fabio

Revision history for this message
Matt Zimmerman (mdz) wrote :

On further investigation, in all likelihood, mkinitrd _was_ run successfully,
but the initrd.img symlink is missing. I haven't recovered the system yet, so
I'm guessing from the upgrade output so far.

Revision history for this message
Matt Zimmerman (mdz) wrote :

Fabio and I discussed this problem with Manoj on IRC, and determined that the
problem is in fact Debian bug #281953 (http://bugs.debian.org/281953). While
this bug was fixed some time ago, it is a bug which propagated into any kernel
packages which were built with kernel-package >= 8.109 and < 8.114. (the lower
limit is a guess and has not been confirmed)

Therefore this bug is lurking on many user systems, to be revealed on the next
kernel upgrade, and so a workaround needs to be found which can compensate for it.

Revision history for this message
Colin Watson (cjwatson) wrote :

After looking at the maintainer scripts, I believe this problem to be limited to
versions -17 to -19; that is, -16 (in warty) and -16.1 do not appear to be affected.

From the changelog, my guess at the point of introduction of the bug would be
kernel-package 8.106.

Revision history for this message
Andrew Zajac (arzajac) wrote :

This does not seem to be the situation that I am describing. My initrd.img symlink exists, but
the actual initrd is not there. I am presuming that is it deleted by the installation of the new
kernel-image and that its replacement is built during the configuration of packages. The
configuration, however, never gets done because of the other bug to which I refer.

The problem is that the user is warned that there are errors, but it not told what to do (or even
that there is not way to boot the system...)

What pertinent information can I provide?

Revision history for this message
Matt Zimmerman (mdz) wrote :

I've imported the bug that the rest of us are talking about as bug #10783 for
reference.

I think this is in fact the same bug, though. The postrm generated by the old
kernel-package scripts looked like this:

if (-f $realimageloc . "initrd.img-$version") {
  unlink $realimageloc . "initrd.img-$version";
}

while the new one looks like this:

if ($ARGV[0] !~ /upgrade/) {
  if (-f $realimageloc . "initrd.img-$version") {
    unlink $realimageloc . "initrd.img-$version";
  }
  image_magic($kimage, $image_dest);
  image_magic($kimage . ".old", $image_dest);
  image_magic("initrd.img", $image_dest) if $initrd;
  image_magic("initrd.img.old", $image_dest) if $initrd;
}

In other words, the initrd.img-$version was being removed on upgrades. This had
the side effect of causing the initrd.img symlink to be removed as well, due to
being a dangling symlink, but your installatin may not have gotten to that point
due to the errors you encountered.

Revision history for this message
Matt Zimmerman (mdz) wrote :

*** Bug 10783 has been marked as a duplicate of this bug. ***

Revision history for this message
Matt Zimmerman (mdz) wrote :

*** Bug 10745 has been marked as a duplicate of this bug. ***

Revision history for this message
Matt Zimmerman (mdz) wrote :

*** Bug 10786 has been marked as a duplicate of this bug. ***

Revision history for this message
Ben Collins (ben-collins) wrote :

From the looks of stable images, the correct bits are in postrm. Given that all
current images are correct, and that warty and hoary release images do not seem
to contain the problem, I'm going to close this bug.

We may still have users complaining who at some point were using a devel cycle
kernel. Hopefully they will find this page to help them.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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