Description of problem: After a clean install and upgrade, the default kernel in the GRUB menu is the original installed kernel, not the upgraded kernel. Version-Release number of selected component (if applicable): grub2-2.02-0.8.fc21.i686 grubby-8.35-4.fc21.i686 How reproducible: Always Steps to Reproduce: 1. Install Fedora-Live-Workstation-i686-21_Alpha-TC7.iso 2. dnf upgrade 3. reboot Actual results: Originally installed kernel is the default kernel in the GRUB menu. 3.16.1-301.fc21.i686 Expected results: Upgraded kernel should be the default booted kernel 3.16.2-301.fc21.i686 Additional info: Immediately after primary installation, but prior to any updates: # grub2-editenv list saved_entry=Fedora, with Linux 3.16.1-301.fc21.i686 Somehow this seems wrong. Why is it that 'grub2-set-default 0' from anaconda, and then a reboot, causes the grubenv to be populated with the above saved_entry instead of 0? If I do 'grub2-set-default 0' the problem is fixed, it now uses the upgraded kernel. Weird. Although grubby creates the grub.cfg entries for the upgraded kernel, I don't think it touches grubenv, which is why I'm marking this against grub2 rather than grubby.
Created attachment 937158 [details] photo of boot menu Shows 2nd kernel as default, which is the original kernel, not the upgraded kernel.
Proposed as a Blocker for 21-final by Fedora user chrismurphy using the blocker tracking app because: The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation).
Yea, I saw the same thing when I installed a while back. Clearing the grubenv seemed to fix it, and it hasn't returned, so whatever made that grubenv entry appeared to do so only at install time. Updated kernels since clearing grubenv, and nothing new has shown up in grubenv.
I upgraded from fc20 and have this same issue. The file /etc/sysconfig/kernel was empty so I wrote: UPDATEDEFAULT=yes DEFAULTKERNEL=kernel-core But still doesn't boot the newest kernel by default. There is some new stuff in grub.cfg seem boot default = 0 wasn't good enough.
I also saw this yesterday when I did an upgrade pop-up in a bare metal install of Fedora-Live-Workstation-i686-21_Alpha-TC7.iso.[1] On reboot I selected the first entry as it defaulted to the second entry and the reboot failed at "starting authorization manager" (I waited +5 minutes) I had to do a power cycle to reboot; used the default 2nd line and Workstation logged in via gdm correctly. [1] https://fedoraproject.org/wiki/Test_Results:Fedora_21_Alpha_TC7_Desktop#Release-blocking_desktops:_x86_.2F_x86_64
OK another TC7 install, another chroot of /mnt/sysimage while in the post-install live media environment: # grub2-set-default 0 # grub2-editenv list saved_entry=0 # rm -f /boot/initramfs-3.16.1-301.fc21.i686.img # grub2-mkconfig -o /boot/grub2/grub.cfg ## the grub.cfg is now in the state it was in during installation, with a boot entry that lacks an initrd line # grub2-editenv list saved_entry=0 # new-kernel-pkg --mkinitrd --dracut --depmod --update 3.16.1-301.fc21.i686 # grub2-editenv list saved_entry=Fedora, with Linux 3.16.1-301.fc21.i686 I'm willing to bet dollars to donuts that grubby is doing this from within new-kernel-pkg because the time stamp of the modified grub.cfg and grub.env are identical down to the second. And I know it's grubby that's adding the missing initrd line to the grub.cfg. The question is which thing here is the bug: 1. grubby modifying grubenv in the first place, wiping out the anaconda set saved_entry=0 value 2. grubby not modifying grubenv when doing later kernel updates 3. anaconda creating /etc/default/grub with GRUB_DEFAULT=saved rather than =0
See: RHBZ #1111790
Changing: DEFAULTKERNEL=kernel-core to DEFAULTKERNEL=kernel allows /bin/kernel-install to update the default kernel. So, who's setting it to "kernel-core"?
Or perhaps the kernel-core packages scriptlet needs to be: /bin/kernel-install add+core ?
"So, who's setting it to "kernel-core"?" Anaconda is. pyanaconda/bootloader.py, writeSysconfigKernel() basically figures out the name of the installed package that contain the actual kernel file, and sets that as the DEFAULTKERNEL= value. Hence, kernel-core , because that's the package that contains vmlinuz now. I can't answer the question of whether anaconda or the kernel package needs to amend its behaviour here, but apparently one of them does. pjones is probably a good assignee here either way, but let's pull in Josh too.
Alpha_RC1 this problem exists (installed workstation live image) (Just wanted to add me to cc list + comment that it happens with latest image)
should probably commonbugs this.
OK, I believe that the problem is not anaconda but instead with ... grubby! Earlier in the anaconda-21 development cycle a patch of mine was accepted and merged into anaconda: https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-May/011336.html https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-June/011369.html I should have BZ'ed the problem but I did not. OK, anaconda is fixed but then along comes grubby which anaconda runs and it screws things up so that it is back to putting the title from the kernel into saved_entry and that sticks. https://bugzilla.redhat.com/show_bug.cgi?id=1111790
I have dug into the problem and it involved both anaconda and grubby. 1. My original patch to anaconda was incomplete. It set "saved_entry=0" but did not change /etc/sysconfig/kernel to UPDATEDEFAULT=no I will do an anaconda patch. That will fix things, right? Wrong! 2. In spite of UPDATEDEFAULT=no which (to me) means that grubby should not do anything with the /boot/grub2/grubenv file but it does. While the new-kernel-pkg shell script checks for UPDATEDEFAULT=yes if --make-default is specified, it blindly does --copy-default I updated grubby with my set of patches (now numbering 10) so that I printed grubby's command line. It appears thta --copy-default is not the problem. No, in spite of --make-default not being specified and UPDATEDEFAULT=no, grubby is still updating /boot/grub2/grubenv Question: If UPDATEDEFAULT is not "yes" in /etc/sysconfig/kernel, then **no** updating of /boot/grub2/grubenv is to be performed. However, if UPDATEDEFAULT=yes, the we should force --make-default. Is this how we want things to work?? My opinion: yes!
This BZ report is against anaconda and anaconda does need to get a small update. For the grubby fix, I will post the fix to BZ #1111790 Peter (pjones) Do you want me to run with this?
Created attachment 941560 [details] In /etc/sysconfig/kernel make it UPDATEDEFAULT=no The will need to be another patch for grubby which will actually honor the setting of UPDATEDEFAULT.
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". I think what's happening here is that something is going wrong when we're trying to figure out what the default should be, and we're picking the wrong one when we update it. /var/log/grubby from the first kernel update that goes wrong should tell us if that's the case.
Peter: so I think I see now what Gene was doing - he was, I think, trying to make it so anaconda simply set the "default entry" to "0", indicating "whichever kernel is first in the list at the current time", and then have nothing touch that when a kernel was updated, so that a new kernel upon installation would become the default *simply by virtue of its position in the list*. I'm not sure if he thought that was the previous behaviour and it had broken, or he just thinks it's a better design. Either way, it seems to me that that would appear to the user to 'fix the problem' and preserve the previous behaviour, but it is not really a fix for this bug, it's a major change to how this code operates, and should therefore not be considered in this context. Gene, if my read is correct, can you please make your proposal into perhaps a mailing list post or a new enhancement bug or something? As it's not really an appropriate way to fix this bug. So, that aside, pjones and I looked into this, and we basically confirmed Orion's diagnosis from c#8 (thanks, Orion!) It works if you change /etc/sysconfig/kernel to say "DEFAULTKERNEL=kernel" not "DEFAULTKERNEL=kernel-core", and that's not by chance or by accident but more or less "by design". The other elements of this chain - the kernel package scriptlets, and /bin/kernel-install , which is part of systemd - are designed to pass new-kernel-pkg the string "kernel", not "kernel-core", when they invoke it. kernel-core %posttrans calls: /bin/kernel-install add %{KVERREL}%{?1:.%{1}} /%{image_install_path}/vmlinuz-%{KVERREL}%{?1:.%{1}} which translates for a particular kernel to: /bin/kernel-install add 3.17.0-0.rc6.git2.2.fc22.1.x86_64 /boot/vmlinuz-3.17.0-0.rc6.git2.2.fc22.1.x86_64 (just for example, that's the one I'm running here). /bin/kernel-install looks for a kernel "flavor", but that's not something like "core", it's something like "debug": [[ "$2" == *\+* ]] && flavor=-"${2##*+}" i.e. it's looking for a '+' in the second argument it was passed (which is 3.17.0-0.rc6.git2.2.fc22.1.x86_64 in our example) and taking the bit after the + as the 'flavor'. If you look at a debug kernel's scriptlets, it runs something like: /bin/kernel-install add 3.17.0-0.rc6.git2.2.fc22.1.x86_64+debug /boot/vmlinuz-3.17.0-0.rc6.git2.2.fc22.1.x86_64+debug so kernel-install would see the +debug and set that as the flavor, in that case. anyhow, what kernel-install does after checking for the flavor is just to call new-kernel-pkg with various arguments, but every time it includes this: /sbin/new-kernel-pkg --package "kernel${flavor}" note, there's no -core there. Unless there's a flavor, the parameter will simply be --package "kernel". If there is a flavor, like "debug", the parameter will be --package "kernel-debug" (the - is added by kernel-install any time it sees a flavor, in that line quoted above). Either way, it's not going to add "-core", because "core" is not a kernel flavor in the sense kernel-install understands. So yup: the kernel and n-k-p are set up to consider the kernel "package" to be called kernel(-flavor). This is arguably incorrect, because of course the kernel package making these calls is no longer called kernel or kernel-debug, it's called kernel-core or kernel-debug-core. But as things stand, the simplest thing to do is have anaconda follow along with the other bits and write DEFAULTKERNEL=kernel . It would of course be possible to have kernel-install call: /sbin/new-kernel-pkg --package "kernel${flavor}-core" to match what the package is *actually* called. Either way, though, the two need to agree on what to do, and do it.
OK, I will move my proposal/discussion to the anaconda discussion list since anaconda is at least a little involved. I already have BZ #1111790 concerning grubby and saved_entry. There is one comment which suggests that I use UPDATEDEFAULT=no and then grubby will not update saved_entry. Too bad grubby does not honor it. To me (and I suspect most people) UPDATEDEFAULT=no clearly says that grubby should do nothing with respect to saved_entry. You might want to look at BZ #135161 which introduces UPDATEDEFAULT=yes/no and anaconda commit 7d7e5bac325cb828a3310fc06aabbdfaa1451615
(In reply to Gene Czarcinski from comment #19) > I already have BZ #1111790 concerning grubby and saved_entry. There is one > comment which suggests that I use UPDATEDEFAULT=no and then grubby will not > update saved_entry. Too bad grubby does not honor it. Just "not updating" it isn't feasible though - if we add a kernel when saved_entry is 0, and we don't update it, the result is the behavior you're supposed to get when UPDATEDEFAULT=yes is set. So we always have to update it if it's set to an index, or else the index will simply be wrong in terms of the user's desire. > To me (and I suspect most people) UPDATEDEFAULT=no clearly says that grubby > should do nothing with respect to saved_entry. You might want to look at BZ > #135161 which introduces UPDATEDEFAULT=yes/no and anaconda commit > 7d7e5bac325cb828a3310fc06aabbdfaa1451615 The question isn't what new-kernel-pkg does with the settings — in fact, that remains the same as it was in the patch katzj attached to that bug. The question is: when "grubby --add-kernel" does not get --make-default as a parameter, what is the intended result? If the intended result is to keep the same stanza as default as we had /before/ grubby was run, then we have to update saved_entry if it's an integer index.
Can I ask an elementary question? Why is anything automated modifying grubenv? I got my fedora 21 system to boot perfectly normally by simply flushing out the contents of grubenv so that all the silly saved nonsense was no longer used, and it simply defaulted to booting the first entry. It seems to me grubenv is for users to manually fiddle in order to achieve various esoteric objectives (either with grub-editenv or with menu entries that explicitly invoke save_env because that's what a user wants to do). Mysterious behind the users back changes to grubenv don't seem to be useful at all, and only lead to confusion. Why not just teach anaconda and grubby to leave it completely alone as they always used to do?
anaconda has written UPDATEDEFAULT=yes into /etc/sysconfig/kernel since https://bugzilla.redhat.com/show_bug.cgi?id=135161 , in 2004 (the commit is 7d7e5bac325cb828a3310fc06aabbdfaa1451615 , dated 2004-10-13 ). It appears that the point was to make this behaviour configurable; either the default is/was not to do so unless UPDATEDEFAULT=yes was specified (so anaconda had to specify it in order to ensure our 'out of the box' behaviour was as designed), or it was considered desirable to explicitly state the default behaviour in the configuration file. The reason for the DEFAULTKERNEL mechanism, back in 2004, appears to have been the existence of variant kernels like 'hugemem' and 'smp'. Our current kernel 'variants', so far as I'm aware, are 'PAE' (for the x86-32 kernel) and 'debug'. I do not know for sure if these are implemented in the same way as 'hugemem' and 'smp' used to be, or if the DEFAULTKERNEL mechanism actually does anything sensible with them. I think it may not actually be a bad idea to review whether this mechanism makes any sense in a modern Fedora context or if we're simply reproducing configuration mechanisms that now exist within grub (and then whether, if we decide to keep the mechanism, it's actually still working as designed). But that's a greater concern than specifically fixing this bug, and probably F22 stuff.
Let me try this once again. What I am proposing is a change to the design. However, it is a change that (I believe) most people would expect to be the default: the next boot will boot the newly installed kernel. 1. When a new kernel is installed, the menuentry for that kernel is placed at the head of the list ... the "zeroth" member in the "10_linux" section. 2. When I realized that anaconda was generating bad titles for saved_entry, I submitted a patch to simplify things and simply set saved_entry=0. This would implement the generally expected behavior of booting the latest kernel. Unfortunately, this does not completely work because grubby comes along and updated saved_entry with the new kernel's title. 3. I now realize that anaconda needed to specify UPDATEDEFAULT=no for the saved_entry=0 to work correctly. Unfortunately, grubby ignores this and updates saved_entry. 4a. I propose that new-kernel-pkg be change to add --make-default to grubby's command line if UPDATEDEFAULT=yes and an --install is being performed. 4b. I propose that grubby be change to only update saved_entry if --make-default is specified on its command line. 4c. With these changes the default behavior will always be to boot the latest kernel. 5. I do not see any valid use of saved_entry=<numeric> other than when <numeric>=0. However, I do see a good use of saved_entry=<title> and UPDATEDEFALT=no. By default, I want to boot one of the menuentry items specified in /etc/grub.d/40_custom. On my laptop, I have mutiboot implemented with Windows 7, Fedora 19 and Fedora 20 installed. By default, I want to boot up Windows because that makes it easier for my wife to use. Also, when I install Fedora 21, it will replace the Fedora 19 installation. If Fedora 21 does not work, I will still have the Fedora 20 install. 5a. The 40_custom menuentry items: For Windows 7, it chainloader +1 the Windows partition. For the Fedora installs (two ext partions plus one BTRFS volume with root1 and root2 suvolumes) the menuentry uses configfile to "chainload" the grub.cfg files on each of the two /boot partitions. Now, my objective is: Things should work out of the box where the latest installed kernel will be booted and, if I specify another menuentry to be booted, that will be preserved over kernel updates being done on any of the Fedora installs. IIUC, the only way the above objective can be acheived is with my proposed patches applied. As things currently work, after a kernel update (install), I have to go back and fix /boot/grub2/grubenv. I believe that I should not have to do that.
But that's not the only way to automatically boot the 1st kernel entry. If anaconda puts nothing at all in grubenv and grubby puts nothing at all in grubenv (which, up to f21 was the way things always worked), then the 1st entry is in fact the one that boots.
Gene: "IIUC, the only way the above objective can be acheived is with my proposed patches applied" This is where you go wrong. That is *not* the only way the above objective can be achieved. It can be achieved simply by either having anaconda write "DEFAULTKERNEL=kernel-core" into /etc/syconfig/kernel or by having kernel-install call: /sbin/new-kernel-pkg --package "kernel${flavor}-core" instead of: /sbin/new-kernel-pkg --package "kernel${flavor}" all of this I explained in c#18. Fedora has already had a system in place which produces the result you describe for, like, a decade. All that has changed in F21 is that it stopped working because of the kernel package organization change to have 'kernel' be a metapackage and have all the real bits in 'kernel-core'. You and Tom both seem to be over-thinking the action needed here: all that's needed is a bugfix in an existing mechanism to account for a behaviour change by a different component.
oh, it may be that the existing mechanism doesn't cover your second requirement, but the point is that *that isn't a part of this bug*. This bug is about the existing mechanism breaking. Attempting to extend the functionality of the mechanism is not an appropriate thing to do as a part of fixing this bug.
*** Bug 1153539 has been marked as a duplicate of this bug. ***
I kinda expected this to be fixed quite quickly once we identified the problem, but since it hasn't been, throwing it on the Beta FE list as it'd be very good to get this fixed in RC2 if at all possible. pjones, is there a chance we could put at least a band-aid for this in RC2 so we don't wind up with everyone who installs Beta reporting this problem too? remember, all we need to fix the immediate problem here is for anaconda and kernel-install to agree on 'kernel' vs. 'kernel-core', the other stuff is not necessary. thanks!
Discussed at 2014-10-27 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2014-10-27/f21-blocker-review.2014-10-27-16.01.log.txt . Accepted as a freeze exception issue: if we can get a safe looking and tested fix for this in time for the next anaconda build it'd be good to take it.
Please look at commit 5c26c8689bc55e3c5fadc74cfa3636475cb54b1a in anaconda (my patch to change the default to "0") At this point in the cycle would backing that off "fix" things? With this patch, grubby needs to be changed. Peter has that patch also but I am not sure we are in agreement as to meanings. Plus, an additional patch is needed to anaconda which so add UPDATEDEFAULT=no to /etc/sysconfig/kernel It may be a bit late in the F21 cycle to make all of that happen.
For the 63rd time no, this bug is not about your patch. The thing that changed is the split between kernel and kernel-core. What this bug is about is that pyanaconda/bootloader.py writes "DEFAULTKERNEL=kernel-core" into /etc/sysconfig/kernel , but kernel-install calls 'new-kernel-pkg --package kernel'. *THAT IS ALL THIS BUG IS ABOUT*. Please discuss anything else, somewhere else.
grubby-8.35-8.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/grubby-8.35-8.fc21
8.35-8 fixes (well, papers over really, but hey) this for me, thanks.
pop up: reboot and update in worksation RC4 x86_64 showed the selected item as updated kernel (first line)
grubby-8.35-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.