Description of problem: With LVM, it is very easy to install multiple versions of FC5 on multiple volumes, with a common /boot. The only problem is with the kernel, in that both 32 bit and 64 bit use exactly the same file names and grub titles. Version-Release number of selected component (if applicable): kernel-*-* How reproducible: always Steps to Reproduce: 1. install FC5-i386 and FC5-x86-64 Actual results: 1. later install overwrites previous kernel Expected results: 1. non-conflicting file names Additional info: Having arch in the file name would eliminate the problem. Also nice to have the arch in the title
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?