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