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.ht...
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 at the front of the list. This patch was accepted: https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-June/011369.h...
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/01407...
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?".
Gene
On 11/12/2014 01:34 PM, Gene Czarcinski wrote:
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.ht...
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 at the front of the list. This patch was accepted: https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-June/011369.h...
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/01407...
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
- 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.
- 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
anaconda-devel@lists.stg.fedoraproject.org