On Tue, 2010-09-28 at 07:21 -0400, Paul Frields wrote: > On Tue, Sep 28, 2010 at 7:14 AM, Paul Frields <stickster@xxxxxxxxx> wrote: > > On Tue, Sep 28, 2010 at 5:31 AM, Joachim Backes > > <joachim.backes@xxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
