Bug 158690 - Kernel RPM install violates grub config
Kernel RPM install violates grub config
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Jones
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-24 16:52 EDT by Jonathan S. Shapiro
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: fc4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-24 14:19:19 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jonathan S. Shapiro 2005-05-24 16:52:59 EDT
I have noticed that kernel updates are breaking my system configuration. If I
have grub configured to boot a Xen kernel, and install an updated "conventional"
kernel RPM, my grub default gets whacked to point to the new kernel.

Unfortunately, this could have a negative effect. A machine that is running
multiple logical machines before the upgrade stops running them once it is rebooted.

My sense is that the default grub configuration should only be moved forward if
the new kernel is of the same "type" as the pre-update default. That is,
installing kernel-smp should only update my grub default if the current default
is an SMP kernel. Installing a xen kernel should only update my default if the
current default is a xen kernel, and so forth.

But the important thing is that logical machines shouldn't spontaneously fail to
restart merely because the xen kernel update is trailing the conventional kernel
update.
Comment 1 Dave Jones 2005-05-24 21:11:25 EDT
Sounds like functionality that needs adding to grubby (which for some reason is
in the mkinitrd package).
Comment 2 Jonathan S. Shapiro 2005-05-25 12:39:29 EDT
Sorry about the misdirected package. Grubby sounds plausible as the culprit.
Comment 3 Jeremy Katz 2006-02-24 14:19:19 EST
This logic should be handled correctly now, although there's the "extra" piece
of needing to set DEFAULTKERNEL in /etc/sysconfig/kernel

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