Efibootmgr & gummiboot replaced UEFI entry for Windows Boot Manager

Question

TLDR
I am now in Windows 7 and dual boot with Arch is working fine.
But before I update Arch, I would like to understand what happened, as in why adding an efibootmgr entry for Arch replaced/deleted the Windows Boot Manager entry although I followed the BG.
The status of my UEFI boot menu was, before the installation of Arch:
Windows Boot Manager
AHCI HDJ... (hard drive 1)
AHCI ST... (hard drive 2)
While working through the BG, I decided to use gummiboot=> https://wiki.archlinux.org/index.php/Be … #Gummiboot. So:
pacman -S gummiboot
gummiboot install
pacman -S efibootmgr
gummiboot install
[some error ocurred, as mentioned in red box]
efibootmgr -c -L "Gummiboot" -l /EFI/gummiboot/gummibootx64.efi
nano /boot/loader/entries/arch.conf
title Arch Linux
linux /vmlinuz-linux
initrd /initramfs-linux.img
options root=/dev/sdb3 ro
[CTRL + X, Y, Enter]
exit
umount /mnt/{boot,home,}
reboot
I then saw a new list of the UEFI boot order:
Gummiboot
AHCI HDJ... (hard drive 1)
AHCI ST... (hard drive 2)
Chose Gummiboot and it brought up a gummiboot menu with entries
Arch Linux
Windows Boot Manager
EFI Shell something
Selected Arch Linux and it went to a message something along "boot device ' ' not found" and I was in a shell which was, I think, rootfs.
I rebooted via the button on my desktop and out the Arch Linux USB drive back. After mounting the partitions:
gummiboot remove
efibootmgr
[0000: Windows Boot Manager
[0001: Arch Linux
[0002: AHCI HDJ...
[0003: AHCI ST...
exit
umount /mnt/{boot,home,}
reboot
Now I booted into a black screen with white text which said something "Reboot and select proper Boot device"
=> Inserted Win 7 64-bit DVD, repaired the boot sector. Rebooted, saw I had these entries again:
Windows Boot Manager
AHCI HDJ... (hard drive 1)
AHCI ST... (hard drive 2)
The boot into Windows worked fine. Rebooted, chrooted into my install again and:
efibootmgr
[0000: Arch Linux
[0001: Windows Boot Manager
[0003: AHCI HDJ...
[0003: AHCI ST...
efibootmogr -b 0 -B
Then I used the EFISTUB method:
efibootmgr -c -L "Arch Linux" -l /vmlinuz-linux -u "root=/dev/sdb3 ro initrd=/initramfs-linux.img"
efibootmgr
[0000: Windows Boot Manager
[0001: Arch Linux
[0002: AHCI HDJ...
[0003: AHCI ST...
exit
umount /mnt/{boot,home,}
reboot
On reboot, 'Windows Boot Manager' was again replaced by 'Arch Linux'.
=> Inserted Win 7 64-bit DVD, repaired the boot sector.
Rebooted, I have now Windows Boot Manager + Arch Linux and dual boot works now.
My questions:
What is going on with efibootmgr replacing/deleting the Windows entry? Is there something wrong with my UEFI menu?
In connection with 1., I would like to sync the EFISTUB Kernel (wiki entry) before I run pacman -Syu. Can I do that now?
Can I uninstall gummiboot now?
Last edited by jones (2013-07-11 12:30:55)

Answer 1

henrik wrote:So in light of your post, I decided to ditch EFISTUB + gummiboot and try out GRUB. Thanks for clearing it up a bit. Which is what confuses me a great deal more, as GRUB/gummiboot obviously do not meddle with Microsoft's EFI files. Right?
EFI relies on two things to boot:
Boot loader program files on the ESP (or occasionally elsewhere).
NVRAM entries pointing to the boot loader files.
Your own problems seem to be with the NVRAM entries, not with the boot loader files themselves. Unfortunately, managing those NVRAM entries has proven to be problematic because of bugs in specific EFI implementations, bugs in efibootmgr and other tools that manipulate the NVRAM entries, poor documentation, and other factors.
To answer your question, though, no boot loader should mess with another's files. Such things can happen, though. The number of bugs that cause Microsoft's boot loader (EFI/Microsoft/Boot/bootmgfw.efi) to be treated deferentially have provoked some tools to use it as a target location for other boot loaders. (Ubuntu's Boot Repair tool does this in a rather overzealous way. So does my own rEFInd installer script, but only under certain narrow circumstances.) Also, the EFI/BOOT/bootx64.efi file is a special case; it's the fallback bootloader that's used when NVRAM entries are missing or don't work, and various boot loader installation procedures place copies in that location, so it can be overwritten and could contain just about anything.
However, the whole thing happened again with GRUB. So I did the whole "repairing Boot problems" with the Windows DVD rescue thingy again and deleted all non-Microsoft files from the EFI partition, /dev/sda1.
Then I formatted / (root) and installed arch again and followed the Beginners' Guide which suggest mounting /dev/sda1/ to /mnt/boot (in contrast to the GRUB entry where the ESP should be mounted to /mnt/boot/efi).
I strongly advise against doing a complete re-installation just to overcome a boot loader problem. Instead, figure out what the problem is and fix it. Doing a complete re-installation is not likely to fix anything, and depending on precisely how you do it, you could end up with a more complex problem. The reason is that the re-installation is not likely to erase the NVRAM entries from the old installation, so you could find that you've got additional stray NVRAM entries. If you do happen to fix the problem by re-installing (say, because you selected a different installation option), you're not likely to know what changed to fix the problem, so you could end up in the same boat should you need to re-install again in the future.
But it did not show this line
Found Windows 7 (loader) on /dev/sda1
... how come??
I've given up trying to understand GRUB's configuration scripts. You could try creating an entry manually by editing /etc/grub.d/40_custom; or you could forget about using the GRUB scripts and create a hand-crafted grub.cfg; or you could forget about using GRUB at all. I'm not a fan of GRUB, so my personal choice is the final one.
So for all the headache and time ... should I delete the EFI partition and recreate it maybe? I think it's possible using the Windows 7 DVD.
But somehow using efibootmgr on my UEFI list somehow invalidated the Windows entry.
Reviewing your posts, it seems that you want to use the EFI stub loader directly, but you're having problems with that because when you add it to the NVRAM entries, Windows drops off your boot manager's boot options. The obvious solution to this problem is to forget about adding the EFI stub loader directly to the NVRAM entries, and instead add a boot manager that can handle either a Linux kernel or the Windows boot loader. (IMHO, this is the superior solution anyhow; I disagree with the Arch wiki's emphasis on using the EFI stub loader "raw.") It seems you were trying to do this with GRUB but had problems booting Windows. Earlier you tried gummiboot but had problems booting Linux. My suggestion is to either go back to gummiboot and fix its problem or try rEFInd. The "device not found" error you reported with gummiboot is usually caused by either a missing (or incorrectly-specified) initrd file or by an incorrectly-specified "root=" option passed to the kernel. Check those possitilities, and if you need help, report what happens in more detail. If necessary, take a digital photo of the screen and post it here. (Make sure it's legible, though!)
You can try rEFInd with minimal disk by using a CD-R or USB flash drive image. Boot with that and your NVRAM and ESP won't be affected at all. If you can get rEFInd working from the flash drive, you can then install it to your hard disk and it should continue working. Note that you probably won't be able to boot Linux directly from rEFInd with your current configuration without adding a "root=" specification to the kernel command line. You can do this by hitting F2 or Insert twice rather than launching Linux by pressing Enter. Alternatively, you can create a refind_linux.conf file in the directory that holds your kernel. That file's contents are described in the rEFInd documentation.