Recovering a broken F18 installation

For some reason (possibly a broken F17 upgrade which moved /lib around?) there were a bunch of empty files in /lib. So F18 refused to boot, with error messages like “/lib/ :File too short”

I discovered yum doesn’t like chroots: Kept on getting a message regarding build_time_vars missing. (Spoiler: This was actually Python!)

I also discovered that yum doesn’t like running from an x86_64 arch when the install arch is i686. Solution was to use setarch as mentioned here:
Essentially, spawn a new bash shell with arch set to i686, so yum will pick everything up as i686 and (re) install the correct files

Final command (with the borked system drive mounted as /media): yum –installroot=/media –skip-broken –releasever=19 distro-sync

Fingers crossed it works, though it can’t get any worse now…
And nope, it didn’t work. –skip-broken seems to have sent it into (circular) dependency hell.

Next thing to try is booting an F18 image and copying over /lib/*. Fingers crossed it’ll fix the lib-systemd missing problem.

Yay! No need to boot the F18 image and copy over stuff!

It was a bugged fedup upgrade from F18-F19. yum installed a bunch of packages, left everything in an inconcsistent state – like Python 2.7.5 was ‘installed’. but build_info stuff was never added/created as it would normally be. Manually redownloading python and python-libs for F18 (python-2.7.3), removing Python 2.7.5 (rpm -e python-2.7.5, python-libs-2.7.5) and then installing Python 2.7.3 got yum up and running again.

However, rpm -e $(rpm -qa|grep fc19)’ also removed glibc… which is needed for practically everything. (Should have been rpm -e $(yum list installed|grep fc19|awk {‘print $1’}) ). So I rebooted into the live system and tried downloading glib for fc19 – since everything wanted GLIBC_2.17, and F18 only had glibc-2.16.

Whoops. Ended up with another inconsistent system. Glibc was the only thing that was for F19. AND, because it was a dependency for just about everything, I couldn’t erase it, and yum wouldn’t let me downgrade it either.

So I decided to just do the distro-sync over it. And one distro0sync later, I discovered that I *really* should have mounted /boot (since it lived on a different partition) before installing a new kernel/initrd. So reboot into live cd, copy the files over from the root’s /boot (bloody shadowing!) into the proper /boot, mount the proper /boot into the live cd’s /boot (since doing it in a chroot made grub2-mkconfig complain), and run grub2-mkconfig -o /boot/grub2/grub.cfg.

Other than it mysteriously picking up fedup (I thought that had been disappeared!), it seems to have booted F19… at least, gotten part way there and frozen, but it’s 11:40 at night, I have a flight in 9 hours, and I kind of need to sleep, so I’m off for now…


And correcting the root=/dev/mapper/live-rw to the proper path (/dev/mapper/vg_lantea-lv_root) got it to at least boot past the root switch, but now services are failing to start, and I don’t know why… Possibly SELinux trouble, so I’m going to try putting enforcing=0 on the boot command line…

And it kind of worked, in that it gets to the login screen at least, though it won’t let me login…

, ,

  1. No comments yet.
(will not be published)