Thanks Artem, I've added this to F14Blocker list, as it clearly
impacts
the final release criteria if all systems fail to boot.
This updated required a few additional steps in order to rollback the
glibc update to return to a working system. As with anything, there are
many different ways to accomplish this. In case folks are interested, I
included my recovery procedure below ...
1. Boot into a rescue system (this could be the F14 installer
rescue-mode, a previously installed Fedora on another partition,
or a Fedora Live image). In my case, I have an F13 partition on
my system.
2. Identify and mount your F-14 installationrescue-mode will locate
and mount the partition for you). If not ... some manual steps
may be required. For me, it involved unlocking the encrypted
partition ...
* UUID=$(cryptsetup
luksUUID /dev/mapper/vg_flatline-f14_root)
* cryptsetup luksOpen /dev/mapper/vg_flatline-f14_root
luks-$UUID
* mount /dev/mapper/luks-$UUID /tmp/f14
* mount -t proc proc /tmp/f14/proc
* mount -t sysfs sysfs /tmp/f14/sys
* mount -t selinuxfs selinuxfs /tmp/f14/selinux
* mount -o bind /dev /tmp/f14/dev
3. Downgrade glibc* packages. Again, for my recovery procedure,
this involved ...
* yum --installroot=/tmp/f14 downgrade glibc*
4. Reboot your system into Fedora 14 ... and wait for a new and
improved glibc update to test
Thanks,
James
Sadly this isn't working for me, I get an error from yum stating that it was
unable to load yummain. I have tried booting from a f14 alpha rescue disc
and from a f3 rescue disk as well as working from a f13 live image and none
of the above works to downgrade glibc. Any other alternatives?
Thanks,
-Erinn