Created attachment 104968 [details]
Trivial patch to make defaulting to new kernel configurable.

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>

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.

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".

You'll need:
up, smp, hugemem among others, I'm sure.

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 ;-).

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.

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.

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?

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).

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
/sbin/new-kernel-pkg):
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.

> (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.)

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.

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? 

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.

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.

here's a thought.

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

defaultkernel=kernel-smp
or
defaultkernel=kernel


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.

re: Comment #17 -- makes sense to me.

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.

is there any reason package name could NOT be passed into the script?

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
advised---
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---

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. 

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
contain
UPDATEDEFAULT=yes
DEFAULTKERNEL=kernel

(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.

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
UPDATEDEFAULT=yes
DEFAULTKERNEL=kernel


Barring objections, I'll build this tomorrow.

I haven't looked at the patch yet, but comment 23 sounds excellent to me.

* 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.

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).

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?  

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
possible...

Ignoring 3rd-party kernels, where is this documented for FC/Redhat?

> 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")

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
touch.

> 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.

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?

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.