Red Hat Bugzilla – Bug 333521
Problems with upgrade from FC5 -> F8test3
Last modified: 2007-11-30 17:12:18 EST
I tried an upgrade from an FC5 installation to F8test3.
The first problem I noticed was a wrong grub configuration, the
same as bug 325871, the default was set to the non-existent FC5
kernel. Also, the grub entry for windows was deleted (maybe this
is the same as bug 322401).
But much worse, anaconda installed a bad initrd file which caused
the boot process to freeze right after the kernel prints the line
Write protecting the kernel read-only data: 844k
To fix this, I re-booted the dvd in rescue mode, chrooted to
mnt/sysimage, erased and then re-installed the kernel package
from the dvd. This screwed up grub.conf even worse, leaving
*only* the entry for the FC5 kernel (there was an error message
about a bad template from grubby, though). After editing
grub.conf, the system now boots fine.
I saved a copy of /boot before re-installing the kernel, and
discovered that the initrd file created under anaconda was bad. After
unpacking it, I found that the bad one contains the wrong loader:
lib/ld-2.4.so instead of /lib/ld-2.6.90.so.
As a final note, this upgrade took a *very* long time to run,
2 hours and 5 min by my stopwatch. My system is a few years old, but
not that bad - it has a 2.4Ghz celeron (old netburst speed) and
512 mb of ram. Everything seems to run at a reasonable pace once the
system is installed.
Upgrades from that far back to current aren't really fully supported, but I
would have suspected this would work (other than taking a while due to every
package on the disk having to be replaced). Is there anything in
/root/upgrade.log on the kernel upgrade?
There are no error messages in upgrade.log, and I think I know why.
I can re-create the corrupted initrd file as follows:
1) Extract /lib/ld-2.4.so from glibc-2.4-4.i686.rpm from the fc5
distribution, and copy just this file into /lib/ on a system running
fc8test3. This should be harmless, since the symbolic link
/lib/ld-linux.so.2 still points to the correct loader.
2) Run 'mkinitrd /tmp/initrd-test.img `uname -r`'. This runs without
apparent errors. But, now list the contents of the resulting file:
'zcat /tmp/initrd-test.img | cpio --list -v', and you'll see that the
2.4 loader has been installed in /lib/ of the initrd file.
The culprit seems to be the following lines in the mkinitrd script:
# this is a hack, but the only better way requires binutils or elfutils
# be installed. i.e., we need readelf to find the interpreter.
if [ -z "$LDSO" ]; then
for ldso in /lib*/ld*.so* ; do
[ -L $ldso ] && continue
[ -x $ldso ] || continue
$ldso --verify $bin >/dev/null 2>&1 || continue
The old (lower-numbered) ld-2.4 file appears first when ld*.so* is
expanded. I'm kind of surprised that this hasn't caused a problem
before now. I guess the weird behavior is that, for some reason,
'ld-2.4.so --verify' succeeds during mkinitrd, but then the old loader
doesn't actually work properly during boot.
It seems that, during the upgrade, the kernel is installed at a point
when the new glibc package has been installed, but the old one has not
yet been deleted, so the old loader is still in /lib/.
Maybe mkinitrd should be smarter about choosing the ver of ld.so?
Maybe, during the upgrade process, the new kernel shouldn't be
installed until the outdated packages have been removed? Or, if this
can't be done easily, maybe mkinitrd should be run a second time at
the end of the install?
PS: FC5 -> F8 is only 3 releases, it doesn't seem "that far back" to
Aha. That makes sense and in fact got fixed up just the other day :-)
*** This bug has been marked as a duplicate of 336161 ***