Got this as well. Currently running kernel-2.6.23.9-85.fc8, can't generate an
initrd for kernel-2.6.23.14-107.fc8 due to this error.

looks like it might have been caused by glib2-2.15.2-1.fc9 (I'm running
partially rawhide due to tracking evolution packages), problem went away by
upgrading to glib2-2.15.3-1.fc9 and libbdevid-python-6.0.28-3.fc9 

Yes, that fixed it for me, thanks!

similar problem fixed for me by downgrading glib2-2.16.1-1.fc9 to glib2-2.14.6-1.fc8

Mixing packages from F9 in F8 will often break your system. This is unsupported.
 Sorry.

I think it would still be a good idea to understand why it's breaking.  glib2 is
supposed to be backwards compatible, which means that such things are not
supposed to happen.

The crash happens or cleanup, which means that merely running nash with wrong
arguments (like "nash -h") would cause it to crash.

# /sbin/nash -h
unknown argument -h
nash received SIGSEGV!  Backtrace (12):
/sbin/nash[0x40c7c9]
/lib64/libc.so.6[0x7fc1b487a2a0]
/lib64/libglib-2.0.so.0[0x7fc1b4e62809]
/lib64/libglib-2.0.so.0[0x7fc1b4e63159]
/usr/lib64/libbdevid.so.6.0.19(bdevid_module_unload_all+0x24)[0x7fc1b5533411]
/usr/lib64/libbdevid.so.6.0.19(bdevid_destroy+0x29)[0x7fc1b5532bef]
/usr/lib64/libnash.so.6.0.19[0x7fc1b574bfe2]
/usr/lib64/libnash.so.6.0.19(nash_vitals_destroy_probes+0x3a)[0x7fc1b574c661]
/usr/lib64/libnash.so.6.0.19(_nashFreeContext+0x16)[0x7fc1b573cef4]
/sbin/nash[0x40cba0]
/lib64/libc.so.6(__libc_start_main+0xfa)[0x7fc1b486632a]
/sbin/nash[0x404179]

And here's the gdb backtrace

Program received signal SIGSEGV, Segmentation fault.
g_hash_table_remove_node (hash_table=0x1a74800, node_ptr_ptr=0x7fffe01802d0,
notify=1)
    at ghash.c:198
198       *node_ptr = node->next;
(gdb) where
#0  g_hash_table_remove_node (hash_table=0x1a74800, node_ptr_ptr=0x7fffe01802d0,
notify=1)
    at ghash.c:198
#1  0x00007ffdd7473159 in g_hash_table_foreach_remove_or_steal
(hash_table=0x1a74800, 
    func=0x7ffdd7b43347, user_data=0x1a73a30, notify=1) at ghash.c:972
#2  0x00007ffdd7b43411 in bdevid_module_unload_all () from
/usr/lib64/libbdevid.so.6.0.19
#3  0x00007ffdd7b42bef in bdevid_destroy () from /usr/lib64/libbdevid.so.6.0.19
#4  0x00007ffdd7d5bfe2 in ?? () from /usr/lib64/libnash.so.6.0.19
#5  0x00007ffdd7d5c661 in nash_vitals_destroy_probes () from
/usr/lib64/libnash.so.6.0.19
#6  0x00007ffdd7d4cef4 in _nashFreeContext () from /usr/lib64/libnash.so.6.0.19
#7  0x000000000040cba0 in ?? ()
#8  0x00007ffdd6e7632a in __libc_start_main (main=0x40c8c7, argc=2,
ubp_av=0x7fffe0180588, 
    init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value
optimized out>, 
    stack_end=0x7fffe0180578) at libc-start.c:220
#9  0x0000000000404179 in ?? ()
#10 0x00007fffe0180578 in ?? ()
#11 0x000000000000001c in ?? ()
#12 0x0000000000000002 in ?? ()
#13 0x00007fffe01826d6 in ?? ()
#14 0x00007fffe01826e1 in ?? ()
#15 0x0000000000000000 in ?? ()
(gdb) p node
$1 = (GHashNode *) 0x0
(gdb)

If you can boil it down to a bit of glib2 using code that builds on F8 and
crashes on F9 then you might have found a legitimate glib2 bug that should be
reported upstream.  But otherwise realistically resources cannot be prioritized
for this specific issue. 

Created attachment 302288 [details]
Patch backported from mkinitrd-6.0.43-1.fc9

This patch fixes the problem.  And that's the corresponding chaglelog entry
from mkinitrd.spec:

* Fri Dec 21 2007 Peter Jones <pjones@redhat.com> - 6.0.25-1
- Don't remove two things from a GHashTable at the same time;
  it doesn't work with newer glib2.

The bug doesn't just affect the case where packages from different versions of
Fedora are mixed.  I installed the latest glib into /usr/local to be able to
compile the latest swfdec.  I was assured that it's backwards compatible.  Yet
installing kernels stopped working after that.

Having had the same problem with glibc, I simply rebuilt the src rpm from
http://koji.fedoraproject.org/koji/buildinfo?buildID=28893 and that worked fine.