So I messed up my Arch system by accidentally installing a broken GRUB. I have a working GRUB called grub_uefi, and a broken one just called GRUB. I'd like to remove GRUB from my system but keep grub_uefi. How do I do so?
-
1GRUB can operate either in BIOS mode (residing in and behind the MBR or in a GPT legacy BIOS partition) or in UEFI mode (residing in the ESP). Both can coexist perfectly fine. You can remove the BIOS variant by zeroing out the first 446 bytes. Please describe the problems you seem to be experiencing.Hermann– Hermann2019-09-23 21:51:35 +00:00Commented Sep 23, 2019 at 21:51
Add a comment
|
1 Answer
I fixed this. I basically listed all my bootloaders with
efibootmgr
which gave me
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0001,3001,0002,2001,2002,2004
Boot0001* GRUB
Boot0002* grub_uefi
Boot2001* EFI USB Device
Boot3001* Internal Hard Disk or Solid State Disk
I wanted to remove GRUB so I did
sudo efibootmgr -b 0001 -B
And it worked.
Now efibootmgr -v shows
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,3002,2001,2002,2004
Boot0002* grub_uefi HD(3,GPT,-redacted-,0x30000000,0x100000)/File(\EFI\grub_uefi\grubx64.efi)
Boot2001* EFI USB Device RC
Boot3002* Internal Hard Disk or Solid State Disk RC
-
So... you just removed an UEFI boot variable from system settings NVRAM, that defines an entry in the firmware boot menu. If there was an actual
GRUB[x64].efifile associated with the broken entry, that will still be present wherever it originally was. But if the entry was created incorrectly, it might not actually have pointed into anything valid. You could have checked the boot file paths withefibootmgr -v, but now the broken entry is gone. It's like removing a symbolic link: if the link used to point to a valid file, the original file will still exist after removing the link.telcoM– telcoM2019-09-24 05:39:37 +00:00Commented Sep 24, 2019 at 5:39 -
@telcoM so how do I remove the broken file? Does it matter if I do?Raymo111– Raymo1112019-09-24 11:51:51 +00:00Commented Sep 24, 2019 at 11:51
-
The first question should be: is there a broken file anywhere? If the root cause was that you made a mistake using the
efibootmgr -ccommand, then there may not be a broken file in the first place: there just was a broken UEFI boot variable, which you already removed. If the broken variable was created automatically by some program, you probably should check the contents of your ESP partition for extra files. But it probably won't matter, because bootloader files are small and with the variable deleted, any bootloader file it used to point to is not going to be used.telcoM– telcoM2019-09-24 12:00:50 +00:00Commented Sep 24, 2019 at 12:00 -
Before you worry any more about this, I suggest you run
efibootmgr -vto display the full content of the boot variables, and try and understand what they mean and how Boot002 exactly refers to thegrubx64.efifile on your ESP partition. Then try and identify the purpose of any other files on your ESP partition. Once you understand what should be there, you can identify possible misplaced duplicates or other broken files. I cannot tell you where the file might be, because you already deleted theBoot001variable that could have told it to you.telcoM– telcoM2019-09-24 12:07:26 +00:00Commented Sep 24, 2019 at 12:07 -
@telcoM I've edited answer with output of
efibootmgr -vRaymo111– Raymo1112019-09-24 13:54:10 +00:00Commented Sep 24, 2019 at 13:54