|
This discussion is related to: https://bugzilla.redhat.com/show_bug.cgi?id=1111790 https://bugzilla.redhat.com/show_bug.cgi?id=135161 A little bit involved with this one: https://bugzilla.redhat.com/show_bug.cgi?id=1141414 And also the patch I submitted changing anaconda so that saved_entry=0 and is in anaconda-21.48: https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-May/011336.html https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-June/011369.html This all started when I finally became annoyed enough at how anaconda was creating s value for saved_entry in /boot/grub2/grubenv that I decided to fix it. Now most people want the latest installed kernel to be the default so the logical (to me) solution was the simply set saved_entry=0 which will result in the first (most recently installed) kernel being booted by default. Recently, I became aware that grubby was stell stepping on saved_entry. However, it was pointed out to me that I should modify /etc/sysconfig/kernel and change it to have UPDATEDEFAULT=no and that would solve my problem. Did it solve the problem? No! Before I get into how things really work and what my proposed change is, let me explain why I want the capability to have grubby not update saved_entry. Almost all of my systems are multiboot. Some are simply different versions (releases) of Fedora and at least one is Fedora and Windows. I do not like the way os-prober and /etc/grub.d/30_os-prober work . Instead I use hand crafted menuentry items in /etc/grub.d/40_custom. I then use saved_entry to point the the title on the menuentry I want booted by default ... Windows in the case of the laptop. And I do not want to be forced to remember to go fixup thigs every time the kernel gets updated. BTW, this also is the reason I created and submitted the "--nombr" patch so that a new install would not screw up may configuration of just what got booted: https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-September/013372.html https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-September/013373.html https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-September/013374.html Proposed change: 1. For --install in new-kernel-pkg, if (and only if) UPDATEDEFAULT=yes then pass "--make-default" to grubby. It is not necessary to specify --make-install for --update since saved_entry will already be correctly set. 2. Modify grubby.c so that for the grub2 bootloader, only updated saved_entry with the new kernel if --make-default has been specified on grubby's command line. How things work now: 1. It appears to me that --make-default is not being set if UPDATEDEFAULT=yes in new-kernel-pkg. I have grubby "wired up" with a lot of debugging code and one of the things I do is print grubby's command line and at no time is --make-default seen. 2. However, it does not matter because grubby always updates saved_entry. My main disagreement with Peter Jones is this from BZ#1141414: I do not agree. We want the same effective default behavior of, by default, booting the most recently installed kernel and this can be done with saved_entry=0 and UPDATEDEFAULT=no--- Comment #17 from Peter Jones <pjones@xxxxxxxxxx> --- I'm not sure why we'd want UPDATEDEFAULT=no . The correct behavior seems (to me) to be: "grub2-set-default 0" -> set the first current kernel to default "grub2-set-default $TITLE" -> set the title to default and then on an update: UPDATEDEFAULT=yes means (when kernel's %post runs it, so with --make-default): default=0 -> add the new kernel at the top and make it default default=$TITLE -> add the new kernel at the top and make it default UPDATEDEFAULT=no in the same situation means: default=0 -> add the new kernel at the top and set the default to whatever kernel it was before default=$TITLE -> add the new kernel at the top and leave the default in place In either case, titles and indices should be transparently interchangeable, so it doesn't matter if there's an index or a title. But we want the same default for UPDATEDEFAULT we've had for years, which is "yes". OK, have at it. Comments? Suggestions? Gene |
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
