How do I completely reset GRUB2 to its default state?
The steps appear somewhat complex:
How do I correctly save modifications to it, when it has been reset?
Despite the purpose of the thread which the undermentioned quotation has been quoted from being to explicitly ascertain which command(s) to invoke to correctly apply the configuration, it wasn’t summarised:
I’d rather like a simple list of commands to run (not that I’ve no interest in understanding them — annotations are wonderful, if you’re willing).
GRUB_TERMINAL_OUTPUT=“console” was used in legacy MBR systems to produce large text output. This option can be disabled by prefixing the command with "# " to change it to a comment.
GRUB_TERMINAL_OUTPUT=“gfxterm” is currently the default used in GPT systems but it will only be honored if GRUB_TERMINAL_OUTPUT=“console” is either commented or deleted.
GRUB_ENABLE_BLSCFG=“true” should be included.
The method that I use to set the display resolution requires the following commands:
@Ernie-07, you’ll be surprised to learn that my GRUB2 configuration was set to console by default then, despite being UEFI with a GPT (is that what you meant by “GPI”?) storage device for /.
I’m as surprised as I presume you are. To confirm, I also presume it wasn’t the default for you? How strange that this very capable and new combination of hardware was detected by the OS installer as supposedly incapable of rendering a GUI bootloader.
Thank you. I’ll try this. I presume that /boot/grub2/grub.cfg is the file that I am supposed to modify, too?
“/boot/grub2/grub.cfg” is the configuration file that will be overwritten via the “grub2-mkconfig” command. Note this file will be used to boot a specific installation of Fedora.
If you have multiple UEFI boot partitions, each may be configured to contain a grub.cfg file.
Generally, the UUID of the Linux OS will determine which UEFI boot partition is searched for an appropriate grub.cfg file.
Would this occur if there were multiple Linux distribution installations? I solely have Windows 11 and the Fedora 41 KDE Spin installed, and each on different storage devices.
boot order as defined via the efibootmgr command will determine which boot partition will be inspected by default although a different one may be selected at boot.
When more than one OS share the same boot partition the grub.cfg file will contain entries for all, usually by UUID.
Initially you expressed questions about how to fix grub after file “/etc/default/grub” was modified to make use of “gfxterm” rather than “console”. That is the only file that requires direct modification.
When executed as root from the proper directory, the command “grub2-mkconfig > /boot/grub2/grub.cfg” will overwrite an existing version of file “/boot/grub2/grub.cfg” with a new one that has been influenced by content of the file “/etc/default/grub”.
Here is a screenshot when the “efibootmgr” command was used first to change the order in which boot partitions were searched IE boot order. Initially the boot order was “0001,0002,0003,0004,0005,006” which was then changed to “0002,0001,0003,0004,0005,0006” and changed again to “0001,0002,0003,0004,0005,0006”.
This command updates NVRAM so you can determine which OS boots by default so you don’t have to fiddle with selecting which OS to boot unless you care to.
Looking to the future. You may have to reinstall windoze to correct something in the future. In
preparation for that day consider the following steps as part of the reinstall process:
Boot an external SSD configured via “VenToy” to allow you to boot a “SystemRescue ISO” from that same external SSD to gain access to “gparted”.
Store copies of all important data and configuration files on that external SSD if space allows. Otherwise, store data in a different external drive.
Use “gparted” to delete the partition table which will wipe out everything on the internal SSD.
Install windoze specifying a small boot partition (200 Mb should work) and a reasonable amount of space for that OS.
Use “gparted” to create and label a very small (93 Mb) boot partition in the remaining space. During a distro installation, having a named boot partition will help ensure that the desired partition is used.
Use “gparted” to create and label a root partition in the remaining space. During a distro installation, having a named root partition will help ensure that the desired partition is used.
If you choose custom partitioning and standard partition during the Fedora install, you will have the option to use the “ext4” filesystem rather than “btrfs”. My preference is “ext4” because it can be easily archived and migrated as an nth distro. That extra distro can be helpful when you cannot make changes to the mounted distro. File system checking and some security-related configuration are some things that cannot be done on a mounted file system.
root@sayw4i:/home/RokeJulianLockhart# grub2-mkconfig > '/boot/grub2/grub.cfg'
Generating grub configuration file ...
Found Windows Boot Manager on /dev/nvme2n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done
The solution is to use su -c:
#!/usr/bin/env -S bash
# Invokes an editor:
xdg-open '/etc/default/grub'
# Applies the configuration change:
su -c "grub2-mkconfig > '/boot/grub2/grub.cfg'"
@ernie-07, sorry about that! Forgot. I’ve incorporated the correct $PWD now:
#!/usr/bin/env -S bash
# Invokes an editor:
xdg-open '/etc/default/grub'
# Switches to the correct `$PWD`; Applies the modified configuration:
su -c "cd '/boot/efi/EFI/fedora'; grub2-mkconfig > '/boot/grub2/grub.cfg'"
However, might I ask why that’s necessary? I ask because with it added, it seems to work exactly like last time:
RokeJulianLockhart@sayw4i:~$ su
Password:
root@sayw4i:/home/RokeJulianLockhart# cd '/boot/efi/EFI/fedora'
root@sayw4i:/boot/efi/EFI/fedora# grub2-mkconfig > '/boot/grub2/grub.cfg'
Generating grub configuration file ...
Found Windows Boot Manager on /dev/nvme2n1p1@/EFI/Microsoft/Boot/bootmgfw.efi
Adding boot menu entry for UEFI Firmware Settings ...
done
It appears that you want to edit file “/etc/default/grub” and then immediately execute the “grub2-mkconfig > /boot/grub2/grub.cfg” command.
Your solution may well work, but I have concerns about a potential race condition and that is why I assumed that changes to the file “/etc/default/grub” had been committed and all that remained was to cause an updated “/boot/grub2/grub.cfg” to be created.
Using two “sudo” prefaced commands will work but I prefer to open the proper directory as root. If you added yourself as an administrative user during the installation as I have, your account will be part of the wheel group.
My preference follows:
Open the file manager and navigate to and highlight directory “/boot/efi/EFI”.
Right click to access a context menu, select “Open as Root” then provide your password.
Highlight the “fedora” directory.
Right click to access a context menu, select “Open in Terminal”.
Execute the “grub2-mkconfig > /boot/grub2/grub.cfg” command which will create updated configuration file “/boot/grub2/grub.cfg” overwriting the existing file.
There was a time not long ago where the “grub2-mkconfig” command would occasionally throw errors so I developed the habit of being where the action was so that I could respond appropriately to them. Perhaps the cause of those has been remedied, but my habit persists.
@ernie-07, I don’t have a desire to invoke a specific command. I believe I’ve been adhering to your advice. Am I mistaken?
The cd shan’t function correctly with sudo, since it spawns and detaches a new shell, and xdg-open shouldn’t be invoked as sudo unless the corresponding consumer is a CLI or TUI application.
To my knowledge, that shouldn’t differ functionally to the script that I provided, unless I’ve missed something. Have I?
Thanks for the explanation. It did initially seem strange, but that makes sense.
