Mailinglist Archive: opensuse-bugs (5243 mails)

< Previous Next >
[Bug 809038] EFI problems - cannot boot windows with secure boot

https://bugzilla.novell.com/show_bug.cgi?id=809038

https://bugzilla.novell.com/show_bug.cgi?id=809038#c64


--- Comment #64 from Neil Rickert <nrickert@xxxxxxxxxxxxx> 2013-03-29 18:20:14
UTC ---
While I have your attention:

I noticed some strangeness this morning (on my UEFI box). I'll describe. Let
me know if you think a new bug report is warranted.

Background:
Windows 8 is installed to use "/dev/sda1" as the EFI partition for booting.
My primary opensuse install uses "/dev/sdb1" as its EFI partition, and
boots as "opensuse-secure". Andrey's patch is installed there.
My secondary opensuse uses "/dev/sda1" as its EFI partition, and boots as
"opensuse_alt-secure", though it usually does not show up in the BIOS boot
menu, so I boot it via the grub menu from my primary install.

Todays events:

1: I booted into my secondary opensuse, and ran online updates. That
apparently
caused a grub2 reinstall (I think a udev or udisk update or similar).
When I rebooted, it was the grub menu from my secondary opensuse that
greeted me. This was unexpected, but only because I wasn't paying
attention.

Running "efibootmgr" showed that "opensuse-secure" and
"opensuse_alt-secure" were in nvram, with "opensuse-secure" as the
default. Windows was gone. This was not a surprise, based on prior
experience. It seems to be the firmware that removes Windows during
reboot.

2: I booted into my primary opensuse (from the BIOS boot menu), and then ran
online updates. This time, I ran "efibootmgr" before I rebooted. That
showed "opensuse" and "opensuse-secure" as the only nvram entries. The
entry for "opensuse_alt-secure" was gone. The entry for "opensuse" was
listed as default. Note that the "opensuse" and "opensuse-secure" both
referenced "/dev/sdb1" (by its gpt GUID) as the EFI partition.

3: I rebooted. That gave me the "opensuse-secure" boot menu. Although plain
"opensuse" had been the default, that was not used, probably because my
system has Secure Boot enabled.
I ran "efibootmgr" to see what was in nvram. It showed two bootable
systems. Those were "opensuse-secure" and the first hard drive (the entry
from "/EFI/BOOT/bootx64.efi"). The latter would presumably have booted
Windows.

4: I booted into Windows, expecting that to add back its entry to nvram. I
then had to get into BIOS settings, to make the "opensuse-secure" entry
the default. And then, booting back into opensuse-secure (my primary
install), I ran "efibootmgr" which showed "Windows" and
"opensuse-secure" entries, with "opensuse-secure" as default.

Here's what bothers me about all of this:

A: It looks as if the re-install of "opensuse-secure" deleted the entry for
"opensuse_alt-secure". I don't think it should be doing that. However,
the reinstall of "opensuse_alt-secure" did not remove the entry for
"opensuse-secure". My guess is that everything that matches
"distribution-name"* is being removed.

B: If it is installing "opensuse-secure" then I don't think it should also
install "opensuse" into nvram. If I turn off secure-boot" the
"opensuse-secure" entry still works. If I had disabled secure boot,
I am now wondering whether the firmware might have deleted the
"opensuse-secure" entry in place of deleting the "opensuse" entry.

C: I think it's a mistake to reinstall grub whenever "mkinitrd" is run. (I
recall objecting to that for a 12.2 milestone release). Reinstalling
grub (in this case, grub2-efi) has repercussions for the booting of other
systems than opensuse. In my opinion, it should not be done unless
necessary (say, after an update of grub2-efi or grub2), or after a
deliberate reinstall by the owner.

--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >
References