Description of problem: I've installed Fedora 23 Workstation, upgraded using "dnf upgrade" and added `GRUB_SAVEDEFAULT=true` to /etc/default/grub. When rebooting selecting any entry results in the error message "File '/grub2/grubenv' not found". Pressing any keys continues the boot provess. How reproducible: I've tested this with multiple different computers, happens every time. Steps to Reproduce: 1. Install Fedora 23 2. dnf upgrade 3. Add `GRUB_SAVEDEFAULT=true` to /etc/default/grub and recreate grub's config 4. Reboot Additional info: A similar bug has been reported: https://bugzilla.redhat.com/show_bug.cgi?id=1173843 See comment 13 for a working patch. Updating the symlink as in https://bugzilla.redhat.com/attachment.cgi?id=1008050, fixes the issue.
I ran into this bug also. I +1 applying the above symlink patch or as an alternative symlink /boot/boot to . That should not break the Grub2 config parts and allows the existing symlink to work even when /boot appears as the root directory.
This bug appears also in Fedora 24. The file /boot/grub2/grubenv is still a symbolic link to an absolute path, instead of a relative path.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This is definitely still confirmed in F24
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug should be reopened. It still appears on Fedora 25. The file /boot/grub2/grubenv is still a symbolic link to an absolute path, instead of a relative path. The fix seems to be simple. Can someone patch it, please?
This bug should be reopened. It still appears on Fedora 25. I am also facing grub boot issues after updating kernel to 4.9.9. The file /boot/grub2/grubenv is still a symbolic link to an absolute path, instead of a relative path. The fix seems to be simple. Can someone patch it, please?
This issue persists in Fedora 26 Alpha.
*** Bug 1355943 has been marked as a duplicate of this bug. ***
I also wrote to the devel mailing list, but no response: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/MLAKL2G22K76A4Z55D6SWSSS3AJISZSJ/ Is no one maintaining GRUB2? What can be done so that this *working* patch can be merged?
I cannot reproduce this bug. GRUB_SAVEDEFAULT "Just Works(tm)" on my EFI machines. What is the full grub2-mkconfig command you are running?
(In reply to Michael Cronenworth from comment #12) > I cannot reproduce this bug. GRUB_SAVEDEFAULT "Just Works(tm)" on my EFI > machines. The problem occurs when the machine boots. If /boot/grub2/grubenv is a symbolic link with absolute path, e.g. it points to /boot/efi/EFI/fedora/grubenv instead of ../efi/EFI/fedora/grubenv, then the file is not found by grup2 in the boot process. This is because at this time there exists no /boot directory, only the boot partition which is later mounted as /boot is read by grup2, but not the root (/) partition of linux (fedora).
I'm aware of that. As I said, my machine boots without error. Rebooting the machine shows grub selecting my last selected kernel. The third kernel. Letting it boot automatically boots into the third kernel without error. ls -l /boot/grub2/grubenv lrwxrwxrwx. 1 root root 28 Dec 8 09:48 /boot/grub2/grubenv -> /boot/efi/EFI/fedora/grubenv I ask what grub2-mkconfig command was used because Google shows the wrong command to be used (grub2-mkconfig -o /boot/grub2/grub.cfg) on some forums.
I have used the command (as root, or with sudo) grub2-mkconfig -o /boot/grub2/grub.cfg It is neccessary if something has changed that would build a modified grub.cfg file, for example a change in /etc/default/grub . I have added the following line to /etc/default/grub: GRUB_SAVEDEFAULT=true Then I have rebuild grub.cfg (see above). I had previously changed the grubenv link to: /boot/grub2/grubenv -> ../efi/EFI/fedora/grubenv Now I did some tests. I have the following entries: # grep -E '^menuentry ' /boot/grub2/grub.cfg |sed -e "s/^\(menuentry '[^']\+'\).*$/\1/" menuentry 'Fedora (4.11.3-200.fc25.x86_64) 25 (Twenty Five)' menuentry 'Fedora (4.10.17-200.fc25.x86_64) 25 (Twenty Five)' menuentry 'Fedora (4.10.14-200.fc25.x86_64) 25 (Twenty Five)' menuentry 'Fedora (0-rescue-961d6a7940044a838b2b0caf615533c3) 25 (Twenty Five)' 1) Just reboot: # grub2-editenv list saved_entry=Fedora (4.11.3-200.fc25.x86_64) 25 (Twenty Five) # reboot => Result: First kernel (4.11.3) was booted. 2) Reboot and choose entry 2 at boot time. # grub2-editenv list saved_entry=Fedora (4.11.3-200.fc25.x86_64) 25 (Twenty Five) # reboot => Result: Second kernel (4.10.17) was booted. 3) Reboot again. Please note that saved_entry has changed. # grub2-editenv list saved_entry=gnulinux-4.10.17-200.fc25.x86_64-advanced-47b210f0-f567-496f-b153-60d5a776de13 # reboot => Result: Second kernel (4.10.17) was booted. grub has remembered the last selected boot entry. 4) Reboot again. It should boot the same kernel again (second entry). # grub2-editenv list saved_entry=gnulinux-4.10.17-200.fc25.x86_64-advanced-47b210f0-f567-496f-b153-60d5a776de13 # reboot => Result: Second kernel (4.10.17) was booted. Ok. 5) Reboot and choose entry 3 at boot time. # grub2-editenv list saved_entry=gnulinux-4.10.17-200.fc25.x86_64-advanced-47b210f0-f567-496f-b153-60d5a776de13 # reboot => Result: Third kernel (4.10.14) was booted. 6) Reboot again. It should boot the same kernel again (second entry). # grub2-editenv list saved_entry=gnulinux-4.10.14-200.fc25.x86_64-advanced-47b210f0-f567-496f-b153-60d5a776de13 # reboot => Result: Third kernel (4.10.14) was booted. Ok. 7) Now change link /boot/grub2/grub.cfg: rm /boot/grub2/grubenv ; ln -s /boot/efi/EFI/fedora/grubenv /boot/grub2/grubenv # grub2-editenv list saved_entry=gnulinux-4.10.14-200.fc25.x86_64-advanced-47b210f0-f567-496f-b153-60d5a776de13 # reboot => Result: - First menuentry was selected automaticall, instead of third. - After timeout of grub, there was printed an error message on the console: error: file `/grub2/grubenv' not found. press any key to continue... The system continues to boot after a short time even without pressing any key. grub has booted the first menu entry (kernel 4.11.3), but should have select the second menu entry, as we can see in the saved boot entry: # grub2-editenv list saved_entry=gnulinux-4.10.14-200.fc25.x86_64-advanced-47b210f0-f567-496f-b153-60d5a776de13 I didn't try other saved entries, because this doesn't change anything, because grub cannot find the file grubenv which would tell grub which menu entry was saved... 8) Change link /boot/grub2/grub.cfg back to a relative link: # rm /boot/grub2/grubenv ; ln -s ../efi/EFI/fedora/grubenv /boot/grub2/grubenv # grub2-editenv list saved_entry=gnulinux-4.10.14-200.fc25.x86_64-advanced-47b210f0-f567-496f-b153-60d5a776de13 # reboot => Result: Third kernel (4.10.14) was booted. Ok. Conclusion: With relative link /boot/grub2/grubenv -> ../efi/EFI/fedora/grubenv all works fine and as expected, but with absolute link /boot/grub2/grubenv -> /boot/efi/EFI/fedora/grubenv only the first grub menu entry is booted (automatically), saved boot entries are ignored. I usually don't use GRUB_SAVEDEFAULT=true, but sometimes I want to boot a special menu entry MENUENTRY once (only for next boot). Then I use # grub2-reboot MENUENTRY This uses the same file for saving which menu entry grub should use at next boot. I have tested this using Fedora 25 x86_64.
(In reply to Edgar Hoch from comment #15) > I have used the command (as root, or with sudo) > > grub2-mkconfig -o /boot/grub2/grub.cfg That's the wrong command. :) Correct command: grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg EFI grub does not read from /boot/grub2/grub.cfg.
(In reply to Michael Cronenworth from comment #16) > (In reply to Edgar Hoch from comment #15) > > grub2-mkconfig -o /boot/grub2/grub.cfg > > That's the wrong command. :) > > Correct command: grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg > > EFI grub does not read from /boot/grub2/grub.cfg. No. My command is the right command for me because my system don't use EFI but BIOS boot mode (but package grub2-efi is installed). Grub2 should work as expected in BIOS boot mode too, not only in EFI boot mode, even with package grub2-efi installed. I don't have tested it in EFI boot mode.
I'm having this same issue on Fedora 25, 32bit, BIOS boot mode. I manually correct the issue by using the script created by Edgar Hoch (thanks Edgar!) at https://bugzilla.redhat.com/show_bug.cgi?id=1173843#c14 As far as the command to rebuild grub.cfg, I use the following as explained at https://unix.stackexchange.com/a/336508/116319: sudo grub2-mkconfig -o "$(readlink -e /etc/grub2.cfg)"
Sorry that I forgot to mention this in the description: I'm also using BIOS boot mode. It seems that the bug is limited to that.
Also present on F26 with BIOS boot and GRUB_SAVEDEFAULT=true.
Apparently I do not have permission to push an update for this package for F26 or lower. You can pull a package I built for F26 if you wish to test it. Perhaps testing that will get the maintainer to push an update. https://koji.fedoraproject.org/koji/buildinfo?buildID=921503 I have pushed this change to Rawhide so you will see the change in F27.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
There are a couple of comments on an F26 update that backported this fix suggesting it might have caused problems for some reason: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f6166caf0b see the comments from ppisar and kevin_kofler . Not quite sure what's going on in either case, but this change is the obvious one that at least looks relevant...
He added "The issue I am having might actually not be caused by this update after all." later on.
My problem could that I have installed grub into /boot/EFI/fedora/grubx64.efi. Because I transferred my disk from BIOS to UEFI machine and configured environment variables and GRUB manually. I've never grasped the reason why Fedora uses doubled EFI subdirectory in /boot/efi/EFI/fedora/grubx64.efi.
ppisar: yeah, that sure looks like it could cause a conflict with the RPM. I'd say that's probably your problem to solve, then. :P (I believe the reason is that /boot/efi is the mountpoint we use for the EFI system partition, but following the UEFI specs, EFI system partitions are supposed to have that top-level /EFI directory. Hence /boot/efi/EFI. I didn't double check this, though, it's just from memory).