The most recent F14 updates damage my system

[James Laska]

On Tue, 2010-09-28 at 07:21 -0400, Paul Frields wrote:
> On Tue, Sep 28, 2010 at 7:14 AM, Paul Frields <stickster at gmail.com> wrote:
> > On Tue, Sep 28, 2010 at 5:31 AM, Joachim Backes
> > <joachim.backes at rhrk.uni-kl.de> wrote:
> >> Hi,
> >>
> >> Sombody has seen this:
> >>
> >> I applied the recent updates for F14 (most are coming from
> >> updates-testing repo).
> >>
> >> Then I rebooted: system still runs.
> >>
> >> Then, after some time (say about 1/2 to 1 hour), getting zillions of
> >> crash messages (in /var/log/messages), for example
> >>
> >> Sep 28 10:25:02 eule kernel: Process 17042(abrt-hook-ccpp) has
> >> RLIMIT_CORE set to 1
> >> Sep 28 10:25:02 eule kernel: Aborting core
> >> Sep 28 10:25:02 eule kernel: eu-unstrip[17043]: segfault at 962dfc ip
> >> 00945689 sp bf9ad844 error 7 in ld-2.12.90.so[942000+20000].
> >>
> >> I tried to reboot with ctrl+alt+del: nothing happens.
> >>
> >> Pressing reset, going into grub: system starts booting, than hangs.
> >>
> >> My impression: the *glibc* or *glibc-common* update make my system buggy.
> >>
> >> Restoring my system, then updating without the updates-testing repo: No
> >> more such messages in /var/log/messages.
> >
> > I also get a kernel panic after last night's updates.  Here's the
> > relevant section of boot messages. I'm transcribing this and will try
> > to be careful with my typing. ;-)
> >
> > * * *
> > dracut: Switching root
> > init[1]: segfault at 3df641fbf8 ip 0000003df62033c7 sp 00007fff2e7bf5f0 error 7 in ld-2.12.90.so[3df6200000+1f000]
> > init used greatest stack depth: 3880 bytes left
> > Kernel panic - not syncing: Attempted to kill init!
> > Pid: 1, comm: init Not tainted 2.6.35.4-28.fc14.x86_64 #1
> > Call Trace:
> >  [<ffffffff8149b08b>] panic+0x8b/0x110
> >  [<ffffffff81054a89>] do_exit+0x7b/0x7d0
> >  [<ffffffff81055474>] do_group_exit+0x88/0xb6
> >  [<ffffffff810628f4>] get_signal_to_deliver+0x3d6/0x3f5
> >  [<ffffffff81008f91>] do_signal+0x72/0x690
> >  [<ffffffff8149b178>] ? printk+0x68/0x70
> >  [<ffffffff81033874>] ? bad_area_access_error+0x47/0x4e
> >  [<ffffffff8107f15e>] ? lockdep_sys_exit+0x20/0x76
> >  [<ffffffff810095f0>] do_notify_resume+0x28,0x86
> >  [<ffffffff8149e39b>] retint_signal+0x4d/0x92
> > panic occurred, switching back to text console
> > * * *
> 
> Artem Goncharov helpfully filed this, which looks to be the same issue:
> https://bugzilla.redhat.com/show_bug.cgi?id=638091

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20100928/3dfd9052/attachment-0001.bin