Bug 135869 - es3u2 -> es3u3 kernel update breaks grub.conf config
Summary: es3u2 -> es3u3 kernel update breaks grub.conf config
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: anaconda   
(Show other bugs)
Version: 3.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-15 15:23 UTC by Hal Wine
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-10 22:58:21 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
installed rpms before update to es3u3 (3.89 KB, text/plain)
2004-10-15 15:48 UTC, Hal Wine
no flags Details
installed rpms after update to es3u3 (4.27 KB, text/plain)
2004-10-15 15:50 UTC, Hal Wine
no flags Details

Description Hal Wine 2004-10-15 15:23:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)

Description of problem:
The update order of kernel & kernel-smp in es3u3 varies. This ends up
changing which kernel is booted by grub. (The stanza order can change,
and the "default=x" line is not updated.)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. start with es3u2 system, kernel & kernel-smp installed
2. Note order of stanzas in grub.conf & default setting
3. do an "rpm -Uvh *.rpm" in a directory with the matching es3u3 rpms
4. Note that the stanza ordering in grub.conf has changed, but the
default line has not.

Actual Results:  Machine boots, by default, the non-smp kernel.

Expected Results:  grub default kernel selection should not have changed.

Additional info:

Note that if you apply just the kernel updates, the stanza ordering
does not change.  I.e.
  rpm -Uvh kernel-*.rpm
gives an installation order of:
 1:kernel-utils           ### [ 25%]
 2:kernel                 ### [ 50%]
 3:kernel-smp             ### [ 75%]
 4:kernel-source          ### [100%]

The failing update gives an installation order of:
 32:kernel-smp             ### [ 42%]
 37:kernel-source          ### [ 49%]
 44:kernel                 ### [ 58%]
 45:kernel-utils           ### [ 59%]

I'll attach the pre & post rpm -qa listings

Comment 1 Hal Wine 2004-10-15 15:48:05 UTC
Created attachment 105278 [details]
installed rpms before update to es3u3

command to generate was:
rpm -qa --qf "%{name}-%{version}-%{release}.%{arch}" | LANG=C sort

All rpms are from es3u2 (stripped down) installation

Comment 2 Hal Wine 2004-10-15 15:50:31 UTC
Created attachment 105279 [details]
installed rpms after update to es3u3

command to generate was:
rpm -qa --qf "%{name}-%{version}-%{release}.%{arch}" | LANG=C sort

Comment 3 Hal Wine 2004-10-19 20:35:18 UTC
Clarification: the update is not done using the RedHat iso's. I.e.
Anaconda is not involved at all.

We extract the relevant (to our situation) rpms from the iso, put them
in one directory, and run 'rpm -Uvh *rpm' in that directory.

I suspect fixes or workarounds will be needed in either 'rpm' itself
(order never changed in AS 2.1), or in a new kernel installation
helper scripts called from %post (hmm, maybe mkinitrd's /sbin/grubby)

Comment 4 Jeremy Katz 2004-11-10 22:58:21 UTC
This is why package update tools such as up2date actually install instead of
updating the kernel as well as handling some default setting themselves.  This
is also why running rpm -U directly on kernels has always been recommended against.

There are some changes in RHEL4 that will help, but they don't (and can't
really) go all the way.

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