specifying the default kernel

Gene Czarcinski

2014-11-12 20:16:18 UTC

Post by Gene Czarcinski
For a long time, anaconda has been going to a lot of trouble to
specify the default kernel setting in /boot/grub2/grubenv. In late
may, I submitted a patch to simply set saved_entry=0
https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-May/011336.html
According to grub2 documentation, setting the value to "0" will boot
the first menuentry (kernel) it finds ... this is what most, if not
all, users expect ... boot the latest kernel. This even works after
installing a new kernel since new menuentry definitions are inserted
https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-June/011369.html
and added to anaconda in commit 5c26c8689bc55e3c5fadc74cfa3636475cb54b1a
While this patch is necessary to "get things correct" as far as what
kernel should be booted by default, it is not sufficient. So, I
submitted another patch to anaconda which changes the setting of
UPDATEDEFAULT from "yes" to "no" in /etc/sysconfig/kernel.
https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-October/014079.html
So, that should fix things ... right? No! As of grubby-8.35-8,
grubby ignores UPDATEDEFAULt=no
Before plunging into doing an update fopr grubby, I would like some
confirmation as to what should be happening ... that is, what should
the user expect when the kernel is updated and there are settings for
saved_entry= in /boot/grub2/grubenv ad well as for UPDATEDEFAULT= in
/etc/sysconfig/kernel
1. UPDATEDEFAULT=no *Do nothing*!
* The user may have set saved_entry to point at a menuentry in
/etc/grub.d/40_custom and does not want that to change (this is a
big issue for me).
* saved_entry=0 will do the "right thing" booting the new kernel whose
menuentry is at the head of the list.
* saved_entry=xyz ... still OK becuase grub2 will boot the first
menuentry if it does not find a match
* saved_entry=5 ... who knows but most likely nothing good. On the
other hand, the user had to specifiocally set this.
2. UPDATEDEFAULT=yes
* saved_entry=0 ... there is a choice here. We can set saved_entry to
the id for the new kernel *or* we can do nothing in which case the
menuentry at the head of the list will be booted ... which is the
kernel just installed.
* saved_entry=5 ... update with saved_entry=0 or ID from new kernel
* saved_entry=xyz ... update with ID from the new kernel
IMO (maybe not so humble) is that if UPDATEDEFAULT=no, grubby should
do nothing. That is, leave saved_entry set to whatever it is set to.
Currently, grubby-8.35-8 unconditionally updates even if
UPDATEDEFAULT=no is specified in /etc/sysconfig/kernel.
OK, before I go and create yet another patch for grubby, how do you
want this to work?
And, also answer the question: "How does a user exp[ect things to work?".

OK, I created a little patch for grubby.c and did not update saved_entry
UPDATEDEFAULT=no so it remains saved_entry=0 which boots the head of the
least *and* still boots the head of the list if I remove the current
head of the list.

With UPDATEDEFAULT=yes, grubby updates saved_entry to the value of the
new kernel but does not updated saved_entry if that kernel is removed.
The value is left as the old value. This sort of works since grub2
defaults to using the head of the list if it cannot find a match.

Mmmmm ... do we really want things to work this way?

If anaconda sets saved_entry=0 and UPDATEDEFAULT=no *and* grubby honors
the UPDATEDEFAULT=no and does nothing, I believe things will work better
all around. That is, more consistently and reliably correct.

Comments??

Gene