Bug 1335533 - "File '/grub2/grubenv' not found" on selecting any boot option with GRUB_SAVEDEFAULT=true
Summary: "File '/grub2/grubenv' not found" on selecting any boot option with GRUB_SAVE...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: grub2
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Peter Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1355943 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-12 12:42 UTC by Jan Niklas Hasse
Modified: 2018-02-07 15:52 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-24 18:34:00 UTC
Type: Bug


Attachments (Terms of Use)

Description Jan Niklas Hasse 2016-05-12 12:42:34 UTC
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.

Comment 1 Warren Lewis 2016-06-15 18:18:59 UTC
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.

Comment 2 Edgar Hoch 2016-06-22 01:58:10 UTC
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.

Comment 3 Fedora End Of Life 2016-11-25 09:01:06 UTC
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.

Comment 4 Lorenzo 2016-12-04 13:05:48 UTC
This is definitely still confirmed in F24

Comment 5 Fedora End Of Life 2016-12-20 20:27:47 UTC
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.

Comment 6 Edgar Hoch 2016-12-20 20:52:35 UTC
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?

Comment 7 Samuel 2017-02-06 15:54:02 UTC
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?

Comment 8 Abhishek Mishra 2017-02-22 10:20:15 UTC
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?

Comment 9 Robin Lee 2017-04-20 07:26:24 UTC
This issue persists in Fedora 26 Alpha.

Comment 10 Robin Lee 2017-04-20 07:27:08 UTC
*** Bug 1355943 has been marked as a duplicate of this bug. ***

Comment 11 Jan Niklas Hasse 2017-04-20 07:55:43 UTC
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?

Comment 12 Michael Cronenworth 2017-06-07 18:29:00 UTC
I cannot reproduce this bug. GRUB_SAVEDEFAULT "Just Works(tm)" on my EFI machines.

What is the full grub2-mkconfig command you are running?

Comment 13 Edgar Hoch 2017-06-07 18:37:19 UTC
(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).

Comment 14 Michael Cronenworth 2017-06-07 18:59:15 UTC
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.

Comment 15 Edgar Hoch 2017-06-07 21:08:37 UTC
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.

Comment 16 Michael Cronenworth 2017-06-07 21:21:27 UTC
(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.

Comment 17 Edgar Hoch 2017-06-07 21:36:15 UTC
(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.

Comment 18 taa 2017-06-12 00:26:37 UTC
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)"

Comment 19 Jan Niklas Hasse 2017-06-29 08:25:21 UTC
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.

Comment 20 Sam Hathaway 2017-07-14 19:55:32 UTC
Also present on F26 with BIOS boot and GRUB_SAVEDEFAULT=true.

Comment 21 Michael Cronenworth 2017-07-24 14:36:12 UTC
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.

Comment 22 Jan Kurik 2017-08-15 07:09:29 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 23 Adam Williamson 2018-02-06 19:08:32 UTC
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...

Comment 24 Jan Niklas Hasse 2018-02-06 21:39:10 UTC
He added "The issue I am having might actually not be caused by this update after all." later on.

Comment 25 Petr Pisar 2018-02-07 09:16:37 UTC
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.

Comment 26 Adam Williamson 2018-02-07 15:52:26 UTC
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).


Note You need to log in before you can comment on or make changes to this bug.