Bug 1918817

Summary: Unify the GRUB configuration files location across all supported architectures
Product: [Fedora] Fedora Reporter: Ben Cotton <bcotton>
Component: Changes TrackingAssignee: Javier Martinez Canillas <javierm>
Status: CLOSED ERRATA QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 34CC: bugzilla, ckellner, edpil02, fmartine, javierm, jwatt, percy, rocketraman
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-03-24 08:54:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1930567    
Bug Blocks: 1860440, 1956008    

Description Ben Cotton 2021-01-21 15:51:13 UTC
This is a tracking bug for Change: Unify the GRUB configuration files location across all supported architectures
For more details, see: https://fedoraproject.org/wiki/Changes/UnifyGrubConfig

This change makes the GRUB configuration files layout to be consistent across all the supported architectures. Currently EFI is a special case since the GRUB configuration file and environment variables block are stored in the EFI System Partition (ESP) instead of the boot partition (or /boot directory if no boot partition is used).

Comment 1 Ben Cotton 2021-02-10 22:46:02 UTC
We have reached the 'Code Complete (testable)' milestone in the Fedora 34 release cycle. If your Change is in a testable state, please set the status to MODIFIED. If this Change will not be ready for Fedora 34, please set the version to rawhide.

The 100% code complete deadline is Tue 2021-02-23.

Comment 2 edpil02 2021-02-13 15:58:44 UTC
A few months ago anaconda was patched to allow  /boot on a btrfs file system and a was able to boot with this config.
i make a fresh  install and i cant boot anymore

Put  /boot on a ext4 partition solves the issue.

Comment 3 Ben Cotton 2021-02-16 15:52:02 UTC
Reminder: The change complete (100% complete) deadline for Fedora 34 changes is Tuesday 23 February. At that point, changes should be 100% code complete, along with supporting documentation where appropriate. Please indicate this by setting the tracker bug for your change to ON_QA.

Comment 4 Fedora Update System 2021-02-22 20:20:59 UTC
FEDORA-2021-41577efba4 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 5 Chris Murphy 2021-03-06 01:47:39 UTC
Pretty sure this should still be ON_QA to track any related issues.

Comment 6 Fedora Update System 2021-03-24 08:54:16 UTC
FEDORA-2021-6e172a47e2 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 7 percy 2021-04-30 03:15:31 UTC
Because of the change https://fedoraproject.org/wiki/Changes/UnifyGrubConfig grub2-reboot stopped working. It is not producing any errors nor unexpected messages in the system log. Just having no effect during next reboot.
Tested on system upgraded to Fedora 34.

Comment 8 Jonathan Watt 2021-06-20 15:07:51 UTC
If a user has invoked `grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg`, is there a similar command that can be invoked to reset that file to the canonical unified-configuration contents for that file, including the correct UUID (that is, so it will direct GRUB to read the config from `/boot/grub2/grub.cfg`)? Or will the user have to figure out the canonical contents for the current version of Fedora and carefully edit in the correct UUID?

Comment 9 Chris Murphy 2021-06-20 15:54:36 UTC
sudo dnf reinstall grub2-common

That will rerun the script that moves /boot/efi grub.cfg to /boot; and recreates the stub/forwarding ESP grub.cfg.

Comment 10 Jonathan Watt 2021-06-20 15:58:17 UTC
Fantastic, thank you, Chris!

Comment 11 Raman Gupta 2022-04-14 13:49:09 UTC
For future searchers (including myself)... I was in a live image and `dnf reinstall grub2-common` was not creating the /boot/efi/EFI/fedora/grub.cfg stub for me. Upon investigating the script I saw that the script validates the /boot/efi mountpoint, and then noted that my EFI system partition was mounted outside the chroot, but not inside the chroot. This is a sublety that I believe should be documented at https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/#restoring-bootloader-using-live-disk.

Also note that the documentation at https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/#create-a-grub-2-configuration still says to target /boot/efi/EFI/fedora/grub.cfg directly with `grub2-mkconfig`, but with this change it really should recommend doing `grub2-mkconfig -o /boot/grub2/grub.cfg`, and verifying that `/boot/efi/EFI/fedora/grub.cfg` is a valid stub.

Further, the documentation at https://docs.fedoraproject.org/en-US/quick-docs/bootloading-with-grub2/#install-the-bootloader-files should probably include grub2-common in the list of rpms that are reinstalled.

Comment 12 Ben Cotton 2022-04-14 14:57:29 UTC
Raman, would you mind filing an issue at https://pagure.io/fedora-docs/quick-docs/issues with details? (Or make a pull request to update the docs, if you're comfortable with that)

Comment 13 Raman Gupta 2022-04-14 17:23:22 UTC
(In reply to Ben Cotton from comment #12)
> Raman, would you mind filing an issue at
> https://pagure.io/fedora-docs/quick-docs/issues with details? (Or make a
> pull request to update the docs, if you're comfortable with that)

Thanks Ben, I've submitted a docs PR: https://pagure.io/fedora-docs/quick-docs/pull-request/446