Bug 333521

Summary:	Problems with upgrade from FC5 -> F8test3
Product:	[Fedora] Fedora	Reporter:	Jeff Norden <jeff>
Component:	mkinitrd	Assignee:	Peter Jones <pjones>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	8
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-10-23 13:55:07 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jeff Norden 2007-10-16 05:36:31 UTC

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.

Thanks,

-Jeff

Comment 1 Jeremy Katz 2007-10-22 20:09:45 UTC

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?

Comment 2 Jeff Norden 2007-10-23 06:07:12 UTC

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
            LDSO="$ldso"
        done
    fi

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?

Thanks,

-Jeff

PS: FC5 -> F8 is only 3 releases, it doesn't seem "that far back" to
me.

Comment 3 Jeremy Katz 2007-10-23 13:55:07 UTC

Aha.  That makes sense and in fact got fixed up just the other day :-)

*** This bug has been marked as a duplicate of 336161 ***