specifying the default kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 at the front of the list. This patch was accepted:
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?".

Gene

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list




[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux