Bug 197065

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

Still happens as of latest rawhide.  To install side-by-side, I'm using 
two /boot partitions, but it's a pain.

I'll take a look into this for FC7

Ok.  I can prepare a patch if you like.

Modifications just committed to rawhide.

Notice to fedora-devel-list:
...we've made some [kernel] changes that should be transparent to most users, 
save those that are building external kernel modules. As of 
kernel-2.6.25-0.154.rc6.git7.fc9, we now include the target cpu in uname -r 
output, like so:

# uname -r
2.6.25-0.154.rc6.git7.fc9.x86_64

And we've also renamed files in /boot:

# ls /boot/*x86_64*
/boot/config-2.6.25-0.154.rc6.git7.fc9.x86_64
/boot/initrd-2.6.25-0.154.rc6.git7.fc9.x86_64.img
/boot/System.map-2.6.25-0.154.rc6.git7.fc9.x86_64
/boot/vmlinuz-2.6.25-0.154.rc6.git7.fc9.x86_64

# ls /boot/*i686*
/boot/config-2.6.25-0.154.rc6.git7.fc9.i686
/boot/initrd-2.6.25-0.154.rc6.git7.fc9.i686.img
/boot/System.map-2.6.25-0.154.rc6.git7.fc9.i686
/boot/vmlinuz-2.6.25-0.154.rc6.git7.fc9.i686

The uname -r change also means /lib/modules/ looks slightly different:

# ls /lib/modules/
2.6.25-0.154.rc6.git7.fc9.i686
2.6.25-0.154.rc6.git7.fc9.x86_64

And so do the contents of the kernel-devel packages:

# ls /usr/src/kernels/
2.6.25-0.154.rc6.git7.fc9.i686
2.6.25-0.154.rc6.git7.fc9.x86_64

This last one is probably the one with the most visible impact, as any 
external module build script that was looking 
for /usr/src/kernels/$(uname -r)-$(uname -m) should now be looking 
for /usr/src/kernels/$(uname -r) only.

This is too silly for words. RH/Fedora (it's just made its way to RHEL6 beta) has to inflict this change because someone couldn't fix their own scripts? Now tout le monde has to change too?

What's wrong with this change? It simply adds arch-specific info to file names and file paths. No real change in normal usage patterns, and now people can install both 32-bit and 64-bit kernels on the same /boot partition (which is NOT a simple scripting issue). Haven't seen any problems with this change in the past 2+ years its been this way in Fedora now (after some initial quirks were sorted out, iirc). Seems like nothing but a win to me. Do you have an actual bug to report?