Bug 135161 - PATCH: make defaulting to newly installed kernels configurable
Summary: PATCH: make defaulting to newly installed kernels configurable
Alias: None
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Peter Jones
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-09 14:58 UTC by Panu Matilainen
Modified: 2014-01-21 22:50 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-05 00:33:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Trivial patch to make defaulting to new kernel configurable. (491 bytes, patch)
2004-10-09 15:01 UTC, Panu Matilainen
no flags Details | Diff
slightly better patch for new-kernel-pkg (1.27 KB, patch)
2004-10-12 22:10 UTC, Jeremy Katz
no flags Details | Diff

Description Panu Matilainen 2004-10-09 14:58:41 UTC
Description of problem:
Currently depsolvers like yum, apt and up2date have special code for
optionally making a newly installed kernel default in bootloader
configuration. That logic doesn't belong to depsolvers, it should be a
systemwide configuration setting as discussed on fedora-test-list:

Comment 1 Panu Matilainen 2004-10-09 15:01:05 UTC
Created attachment 104968 [details]
Trivial patch to make defaulting to new kernel configurable.

Comment 2 Féliciano Matias 2004-10-09 15:42:22 UTC
We should not touch new-kernel-pkg, otherwise (as least) we should add
'--dont-make-default' to new-kernel-pkg.

Perhaps, the postinstall scriptlet of kernel package should use :
[ -f /etc/sysconfig/kernel ] && . /etc/sysconfig/kernel
[ "$MAKEDEFAULT" = "yes" ] && makedefault="--make-default"
[ -x /sbin/new-kernel-pkg ] && /sbin/new-kernel-pkg --mkinitrd
--depmod --install $makedefault <version>

Comment 3 Seth Vidal 2004-10-09 15:45:30 UTC
Slight problem with this plan.

Let's say you're on an smp system and both up and smp kernels get updated.
The way yum and up2date deal with that is by looking at what type of
kernel your current default and then making that same type(smp or up)
the default after you've installed.

In this configuration that's going to be hard b/c the kernels won't be
dealt with collectively. They'll be dealt with piece by piece.

Comment 4 Barry K. Nathan 2004-10-10 09:06:11 UTC
It should be possible to store the higher-level knowledge (i.e.
whether UP or SMP should be the default) in /etc/sysconfig/kernel,
right? So that would make it something like "no", "up" and "smp"
rather than "no" and "yes".

Comment 5 Seth Vidal 2004-10-10 14:36:17 UTC
You'll need:
up, smp, hugemem among others, I'm sure.

Comment 6 Paul Iadonisi 2004-10-10 19:28:18 UTC
I don't get why this would be necessary (i.e.: up, smp, hugemem
selectability in the config option).  Why not just have new-kernel-pkg
look at what type is *currently* configured to boot and only make the
new kernel being added the default if the type matches.  Of course,
the option should probably be named
--make-default-only-if-type-is-same-as-current-default or something
like that ;-).

Comment 7 Barry K. Nathan 2004-10-10 23:12:06 UTC
Regarding comment 5: AFAIK Red Hat is compiling the UP and SMP kernels
as hugemem by default now (i.e. as of kernel 2.6.x), so there aren't
any separate "hugemem" kernels anymore. (Unless you're thinking about
using this mechanism on older Red Hat-based distributions that use the
2.4 kernel; that's a use case I wasn't thinking about.)

Regarding comment 6: ISTM that having the separate configuration file
would allow a simpler implementation and would be easier to debug if
something goes wrong. OTOH your idea would reduce the potential for
human error, if the implementation can be sufficiently robust.

Comment 8 Seth Vidal 2004-10-11 00:55:32 UTC
well, some of this code would trickle down into rhel3 or other distros
so I'd think we'd need to be prepared for other names for kernels.

Comment 9 Panu Matilainen 2004-10-11 04:48:55 UTC
Hm, you're right, the hugemem/smp/up thing indeed needs to be dealt
with somehow. Having the preferred kernel type stored in
/etc/sysconfig/kernel would be quite nice I think since without that
it's largely guesswork which kernel is really the one that the user
wants as default: I could have both kernel and kernel-smp installed on
UP box in order to build modules for -smp as well and still prefer
up-kernel as default. Or we could look up the current default from
"grubby --default-kernel" I suppose. Thoughts?

Comment 10 Barry K. Nathan 2004-10-11 06:39:55 UTC
Interesting, I didn't realize grubby had that option. (I was about to
ask whether grubby works with lilo, but I just checked the grubby
documentation and it claims it does.)

Ok, so finding out the name of the installed kernel is a lot easier
than I was expecting. Good. I'm now starting to lean a little bit more
toward the automagic approach and less toward the configuration file
approach, but I'm not completely decided (and at this point, I have no
showstopper objections to either approach).

Comment 11 Barry K. Nathan 2004-10-11 10:39:48 UTC
Food for thought:

This command will find the type of kernel currently running (e.g.
"hugemem", "smp", "" for plain UP kernels, etc.):
rpm -qf --qf '%{name}' `grubby --default-kernel` | cut -c 8-

The following (untested) code might be able to find the type of kernel
that is in the process of being installed (from within
rpm -qf --qf '%{name}' $bootPrefix/$kernelName-$version | cut -c 8-

(If you want to prepend the types with -, e.g. "-hugemem", "-smp", "-"
so that "" is never a valid type, then change the "8-" to "7-" in the
cut command. Or, now that I think about it, perhaps the cut command is
completely unnecessary...)

Disadvantage: It would run rpm queries while an rpm transaction is
still in process. If RPM still has locking bugs (or if the system in
question is running a sufficiently old RPM version), this would be
going out of our way to hit those bugs.

Advantage: This will automatically figure out the difference between
UP kernels, "smp", "highmem", etc. without having to enumerate those
in /sbin/new-kernel-pkg ahead of time, and without having to specify
the kernel type in /etc/sysconfig/kernel.

Comment 12 Barry K. Nathan 2004-10-11 11:54:14 UTC
> (If you want to prepend the types with -, e.g. "-hugemem", "-smp", "-"
> so that "" is never a valid type, then change the "8-" to "7-" in the
> cut command. Or, now that I think about it, perhaps the cut command is
> completely unnecessary...)

Oops, I wasn't quite thinking straight. Changing the cut command
doesn't change "kernel" to "-", it still changes "kernel" to "".
Getting rid of the cut command completely, OTOH, might help matters.
(Or maybe it won't. I need to think about this again later.)

Comment 13 Jeremy Katz 2004-10-12 01:51:34 UTC
Running rpm from new-kernel-pkg is a non-starter.  That's part of why
this was put into up2date and not the kernel's %post to begin with.

Comment 14 Matthew Miller 2004-10-12 03:24:44 UTC
random midnight thought -- could we just check /proc/cpuinfo (or the
sysfs equivalent) for more than one CPU, and prefer SMP if the current
setup sees more than one? 

Comment 15 Barry K. Nathan 2004-10-12 06:02:25 UTC
Regarding comment 13: I realized that invoking rpm from within
new-kernel-pkg used to be out of the question in the past. However,
given that rpm's locking has changed a lot, I wasn't completely sure
that it's still not an option; thanks for confirming this.

Regarding comment 14: That doesn't account for e.g. smp vs. hugemem.

AFAICT all this brings us back to something resembling the suggestion
in comment 9: Look at the filename of the current default kernel, and
the version number of the kernel being installed, and from those two
bits of info, try to determine whether the kernel being installed
should become the default. I have some more ideas but I'm tired
tonight so those will have to wait for sometime tomorrow.

Comment 16 Jeremy Katz 2004-10-12 19:08:24 UTC
With comment 14: that also doesn't work as you don't necessarily want
to be based on what the current kernel sees.

I'm not against the idea in theory, but in practice, this just hasn't
been something that's had a reasonable-ish answer.  Running rpm to
find out what the current booting kernel is was considered the "best"
way to find out, and I still tend to agree unless I see something
pointing to the contrary.  And I don't yet feel comfortable with rpm's
locking to allow concurrent access in all cases to depend on that.

Comment 17 Seth Vidal 2004-10-12 19:13:44 UTC
here's a thought.

Why not have a config setting in /etc/sysconfig/somewhere of something


so that the command run can see if it should set the one it just
installed to be default, based on whether or not its name is that.

that would get around both sets of problems and it would be handled on
a kernel-package by kernel-package basis.

Comment 18 Matthew Miller 2004-10-12 19:23:33 UTC
re: Comment #17 -- makes sense to me.

Comment 19 Jeremy Katz 2004-10-12 19:51:28 UTC
You can't do it in on package name.  That's not passed into the script
and I have no way to find it out other than rpm -qf which goes back to
not being able to access the db while installing packages.

Comment 20 Seth Vidal 2004-10-12 19:54:41 UTC
is there any reason package name could NOT be passed into the script?

Comment 21 Barry K. Nathan 2004-10-12 21:12:46 UTC
Comment #20 is one of the "some more ideas" I alluded to (but was too
tired to state) in comment 15. :)

The more I think about it, the more that comment #17 makes sense to
me. Admins will need to become aware of /etc/sysconfig/kernel or
whatever *anyway*, for answering yes/no; once you make that leap, it's
not much more of a leap to specify the default kernel package name.

If that's not workable for any reason, I have some other ideas
(described below), but IMO they're ugly hacks so if the suggestions in
comments 17 & 20 are OK, feel free to skip the rest of this comment.

---WARNING: graphic description of ugly hacks, viewer discretion
For determining the type of the currently installed kernel, we don't
*really* need to access the rpm database. We could just see if the
current kernel's filename ends in "smp" or "highmem", or conclude
that's it's a UP kernel otherwise. (Or something like that.) In fact,
we could do that on the version number of the kernel being installed,
too, if it's too hard to pass the package name into the script.

If we want to reduce the guesswork and still avoid accessing the RPM
database, the kernel package containing "vmlinuz-2.6.39-1.3017foobaz"
could write the package name (e.g. "kernel-foobaz" or
"kernel-foobaz-2.6.39-1.3017" or "kernel-foobaz-2.6.39-1.3017.i686")
to "rpmname-2.6.39-1.3017foobaz" or whatever. Then the script could
find the rpmname file that corresponds to the default vmlinuz, and it
would have the package name that way. (Now that I think about it, this
would also eliminate the need to pass the package name into the script.)

Or we could store the package name in a comment somewhere (either in
grub.conf/lilo.conf, although that sounds *really* fragile to me, or
in config-2.6.39-1.3017foobaz).
---end of graphic description of ugly hacks---

Comment 22 Adrian Likins 2004-10-12 21:33:56 UTC
just a general comment, I'm all for having something external
do the "pick the right kernel" to make default. I'd love
to get that code out of up2date. 

Comment 23 Jeremy Katz 2004-10-12 21:59:58 UTC
I guess comment #17 will work.  It's a little bit ugly, but workable.

So, the plan is:
* anaconda will write out /etc/sysconfig/kernel on install.  This will

(plus some explanatory comments)

* kernel %post will be updated to pass '--package kernel-smp' (,etc)
to the invocation of new-kernel-pkg in %post.  Additionally,
Conflicts: mkinitrd < new.version

* new-kernel-pkg will get something along the lines of the patch in
comment #2 *and* also get some logic for checking that the kernel type
passed in matches that of DEFAULTKERNEL.  If not (or if it's not
passed in or DEFAULTKERNEL isn't set), then it won't change the default.

* release notes will be updated to have information on this.

* up2date and yum can lose their code for doing this.  The individual
maintainers can decide if they want to migrate their old setting on
first run of the new version.

Anything missing that anyone can think of?  I'll get the patches for
anaconda, the kernel %post and new-kernel-pkg together tonight.

Comment 24 Jeremy Katz 2004-10-12 22:10:49 UTC
Created attachment 105094 [details]
slightly better patch for new-kernel-pkg

Better patch to new-kernel-pkg that adds DEFAULTKERNEL.  Use an
/etc/sysconfig/kernel like this

Barring objections, I'll build this tomorrow.

Comment 25 Barry K. Nathan 2004-10-12 23:16:01 UTC
I haven't looked at the patch yet, but comment 23 sounds excellent to me.

Comment 26 Jeremy Katz 2004-10-13 17:40:09 UTC
* anaconda change committed
* new-kernel-pkg change committed (will be in mkinitrd-4.1.15)
* kernel %post change mailed to davej
* bug filed for release notes (bug #135586)

If people could test the new kernel + mkinitrd packages, it would be
much appreciated.  You'll need an /etc/sysconfig/kernel like the one I
described in comment 23 for things to work, but with that, it should
set new kernels to be the default.

Comment 27 Barry K. Nathan 2004-10-23 02:47:56 UTC
I can confirm that in rawhide snapshots from the last several days
this is working very well (i.e. I can install a rawhide snapshot, use
up2date to update to a newer kernel, and the new kernel automatically
becomes the default in GRUB, just as I want).

Comment 28 Kam Leo 2004-11-26 08:12:26 UTC
Possible values for UPDATEDEFAULT and DEFAULTKERNEL are not enumerated
in either FC3 release notes or /etc/sysconfig/kernel.  Users can guess
that the possible values for UPDATEDEFAULT are 'yes' and 'no'. 
Besides 'kernel' what are the possible values for DEFAULTKERNEL?  

Comment 29 Barry K. Nathan 2004-11-26 10:10:52 UTC
If I remember correctly, on Fedora Core 3 the possible choices are
"kernel" and "kernel-smp". On RHEL 4, "kernel-hugemem" is another
possibility. If you consider 3rd-party kernels, then maybe anything is

Comment 30 Kam Leo 2004-11-26 18:10:27 UTC
Ignoring 3rd-party kernels, where is this documented for FC/Redhat?

Comment 31 Matthew Miller 2004-11-26 18:14:43 UTC
> Ignoring 3rd-party kernels, where is this documented for FC/Redhat?

In the release notes.

("kernel RPMs *whose names match this value* will bebooted by default")

Comment 32 Kam Leo 2004-11-26 20:03:44 UTC
The phrase "kernel RPMs whose names match this value" is vague.
Without looking at /etc/sysconfig/kernel how does anyone know that
DEFAULTKERNEL should be set to 'kernel'?  How does one specify a
non-kernel OS as the default selection?  Do I use 'chainloader' as the
value? How would anyone outside of a mailinglist know unless these
things are documented.  Examples in the release notes would be a nice

Comment 33 Barry K. Nathan 2004-11-26 21:32:19 UTC
> How does one specify a non-kernel OS as the default selection?

Just set UPDATEDEFAULT to no, then edit grub.conf to specify the
default you want.

Comment 34 Kam Leo 2004-11-26 21:39:25 UTC
What I'm trying to point out is that not every one wants the latest
kernel update to be set as the default.  Setting 'UPGRADEDEFAULT=no'
seems pretty clear. My current kernel will not be usurped by the newly
installed version until I say so. 

I am, however, confused by the DEFAULTKERNEL parameter's vague
wording.  Values put forth are 'kernel', 'kernel-smp', and
'kernel-hugemen'.  None of these documented anywhere.

I have multi-boot systems.  Most have same flavor of Windows, multiple
Linux and unix distributions installed.  If I want the Windows or unix
OS to be automatically selected as the default regardless of upgrade
utility (yum, apt-get, up2date, etc.) what would I have to enter into
/etc/sysconfig/kernel to maintain that setting?

Comment 35 Matthew Miller 2004-11-26 22:07:25 UTC
It's not vague. Those are, as the documentation clearly says, the
names of the kernel RPMs. Maybe you are overthinking this -- almost
impossible to be any _less_ vague because it's so simple. 

If you want something _other_ than a Linux kernel package to be set as
the default, then do it manually in the grub conf, and set
UPDATEDEFAULT to "no". Then, when a new kernel package is installed
(regardless of upgrade utility), nothing will change.

Please, if you need further explanation let's take this discussion to
fedora-list, so as to avoid further spamming this bug.

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