Red Hat Bugzilla – Bug 197065
support side-by-side installation of 32 bit and 64 bit releases
Last modified: 2015-01-04 17:27:36 EST
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):
Steps to Reproduce:
1. install FC5-i386 and FC5-x86-64
1. later install overwrites previous kernel
1. non-conflicting file names
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.
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
And we've also renamed files in /boot:
# ls /boot/*x86_64*
# ls /boot/*i686*
The uname -r change also means /lib/modules/ looks slightly different:
# ls /lib/modules/
And so do the contents of the kernel-devel packages:
# ls /usr/src/kernels/
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?