Bug 179381 - RHEL-4 update to FC5t2 leaves behind incorrect kernels
Summary: RHEL-4 update to FC5t2 leaves behind incorrect kernels
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda   
(Show other bugs)
Version: 5
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Mike McLean
Depends On:
Blocks: FC5Blocker
TreeView+ depends on / blocked
Reported: 2006-01-30 19:13 UTC by Stephen Tweedie
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-20 20:26:46 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Stephen Tweedie 2006-01-30 19:13:40 UTC
Description of problem:

I updated a RHEL-4WS x86_64 SMP box to FC5 test2 using the boot.iso and NFS.  
The default kernel prior to the update was kernel-smp-2.6.9-22.0.2.EL.  After
the update, kernel-2.6.15-1.1826.2.10_FC5 was installed, but was not booted (it
defaulted to the old 2.6.9-22.0.2.EL SMP kernel); and the old kernel- and
kernel-smp 2.6.9-22, -22.0.1 and -22.0.2.EL were left behind.

This had two consequences:
X would not start, as hotplug was totally broken by the booting of the old
kernel; and

yum update would not work, as the old 2.6.9 kernels conflicted with new
kudzu/udev/initscripts etc. packages.

Version-Release number of selected component (if applicable):
All default FC5t2 packages.

How reproducible:
Have not tried.

Steps to Reproduce:
1. Install RHEL-4U2
2. Enable update to FC5t2 by manually installing fedora-release rpm
3. Run the FC5t2 upgrade
Actual results:
Old RHEL-4 kernels left behind as default kernels.

Expected results:
Old kernels should be removed and the new kernel should be the default one to
boot from.

Additional info:

Comment 1 Jeremy Katz 2006-01-30 19:15:54 UTC
We probably want to just have the kernel package doing the right thing here. 
That would need kernel obsoleting kernel-smp < something reasonable for x86_64.
 Then the tricky part is switching the /etc/sysconfig/kernel stuff so that the
right kernel gets made default.

Comment 2 Stephen Tweedie 2006-01-30 19:47:08 UTC
I suspect grubby needs to be involved too.  As I understand things right now, we
only ever update the default boot line in grub if the new kernel is replacing an
existing default one of the same variant.  Replacing a kernel-smp with a kernel
package may not trigger that.

Comment 3 Dave Jones 2006-01-31 03:24:22 UTC
The kernel spec has had..

%ifarch x86_64
Obsoletes: kernel-smp

Since ~ November.

Comment 4 Paul Nasrat 2006-01-31 03:33:49 UTC
The kernel is processed as 'i' with in the transaction install only which does
not do any erases (including obsoletes).

Comment 5 Stephen Tweedie 2006-01-31 04:00:33 UTC
Even if it did do obsoletes, that wouldn't fix up the grub config entry.

Comment 6 Jeremy Katz 2006-01-31 04:07:28 UTC
Hmm, we should definitely be overriding the installonlypkgs as we don't ever
want that behavior from anaconda.  Problems like this are just too painful. 
Paul -- want to fix this up?

Dave -- we probably still need to do something for munging /etc/sysconfig/kernel
so that the right thing gets set as default by grubby.  We basically just need
to do:
  sed -e -i 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/'
Kind of gross though :-/

Comment 7 Paul Nasrat 2006-01-31 17:41:01 UTC
I've fixed anaconda up to override installonlypkgs

Comment 8 Dave Jones 2006-02-03 20:00:28 UTC
kernel now has..
if [ `uname -i` == "x86_64" ]; then
  sed -e -i 's/^DEFAULTKERNEL=kernel-smp$/DEFAULTKERNEL=kernel/'

as the first thing in its %post 

Comment 9 Rahul Sundaram 2006-02-20 10:41:55 UTC

These bugs are being closed since a large number of updates have been released
after the FC5 test1 and test2 releases. Kindly update your system by running yum
update as root user or try out the third and final test version of FC5 being
released in a short while and verify if the bugs are still present on the system
.Reopen or file new bug reports as appropriate after confirming the presence of
this issue. Thanks

Comment 10 Jeremy Katz 2006-02-20 20:26:46 UTC
This should be handled properly in test3

Note You need to log in before you can comment on or make changes to this bug.