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
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 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. |