a Thanksgiving disaster averted

[David A. Bandel]

On Nov 22, 2007 1:11 PM, Lonni J Friedman <netllama at gmail.com> wrote:
> https://netllama.linux-sxs.org/llamaland/2007/11/kernel-panic.html
>
> I (thought that I) had some time to kill yesterday afternoon, and went
> ahead and upgraded from Fedora 7 to Fedora 8 via yum. Everything
> appeared to go well, until I rebooted and ended up with a kernel
> panic:
>
> /bin/nash: /lib/libc.so.6: version 'GLIBC_2.7' not found (required by
> /lib/libcrypto.so.6)
>

[snip]

>
> And reboot. Bingo, no more problems. At this point, I fixed all the
> same files under /lib/i686/nosegneg on the master filesystem so that
> future generated initrds wouldn't be similarly broken. What I still
> don't understand is why this got broken originally, or what this stuff
> inside of /lib/i686/nosegneg actually is. None of it appears to be
> part of an RPM.

nosegneg is part and parcel of the glibc-2.7.xx rpm
(http://rpm.pbone.net/index.php3/stat/6/idpl/5327656)

This nosegneg I find mostly in reference to XEN, although why it's in
the primary rpm and not a XEN rpm is anybody's guess.

This from a post on the XEN mailing list:
Add the "nosegneg" fake capabilty to the vsyscall page notes. This is
used by the runtime linker to select a glibc version which then
disables negative-offset accesses to the thread-local segment via
%gs. These accesses require emulation in Xen (because segments are
truncated to protect the hypervisor address space) and avoiding them
provides a measurable performance boost.

Why mkinitrd would choose this is the real puzzle.  Seems like you'd
need this on a real system (just not a XEN hypervised guest system).

So I'd say something didn't get properly updated during your upgrade.

Ciao,

David A. Bandel
-- 
Focus on the dream, not the competition.
            - Nemesis Air Racing Team motto