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
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.
Aha. That makes sense and in fact got fixed up just the other day :-) *** This bug has been marked as a duplicate of 336161 ***