Issues with booting, GPT and UEFI

[nrickert]

@bogdanc2011

It’s still

BootCurrent: 0000
Timeout: 0 seconds

Thanks.

So that you know what we were looking for, here’s what I see:

# efibootmgr -v
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0002
Boot0000* tumbleweed-secureboot HD(1,800,fa000,c0b70134-6c3b-4722-835e-6bc174ade394)File(\EFI	umbleweed\shim.efi)
Boot0002* Windows Boot Manager  HD(1,800,fa000,a0547a0a-57c0-405d-b6b9-a01ca4839f0f)File(\EFI	w\shim.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...t................

It looks as if there is nothing in NVRAM (the flash memory used by UEFI) on your system. And this is strange.

On my box, if I boot from the install media, then the “efibootmgr -v” output will have an entry for the install media, though the BIOS will remove that two or three boots later.

I’m guessing that UEFI is not fully implemented on your system.

[arvidjaar]

@nrickert

Boot0002* Windows Boot Manager  HD(1,800,fa000,a0547a0a-57c0-405d-b6b9-a01ca4839f0f)File(\EFI\**tw\shim.efi**)

Funny - it does not look like Windows. Is Windows happy with it (i.e. - can you actually edit BCD and such)?

[arvidjaar]

@bogdanc2011

First, there’s the error. Then I restart, press ESC to enter the BIOS menu, F9 to enter the boot menu, choose EFI file and it’s done.

Does your system offer any means to edit boot menu? If yes, did you try to add this file to boot menu manually?

[nrickert]

@arvidjaar

Funny - it does not look like Windows. Is Windows happy with it (i.e. - can you actually edit BCD and such)?

Yes, Windows seems to be be happy with that. I can still edit BCD, and I could put that back to the way Windows normally sets it. What you see is my work around for the limitations of the Dell BIOS.

My BIOS only retains one NVRAM entry per EFI partition. So if I install opensuse (say a 13.2 milestone) using the same EFI partition as Windows, then the BIOS will delete the Windows entry in NVRAM. And when I next boot Windows, it will put its entry back and the BIOS will then delete the entry for opensuse. So, I have it set that when Windows puts its entry back, it puts back an entry that gets me to grub.

Incidentally, I the directory “\EFI w” that you see being used there, is manually copied from the EFI directory on the second hard drive, where I have 13.1 installed. I don’t think I can “persuade” Windows to actually boot from something in an EFI partition other than the one it normally uses.

[bogdanc2011]

I went ahead and installed Fedora afterall. Just as I thought, it worked, the system would load the boot menu automatically, although I could not boot openSUSE (it said it couldn’t find the kernel or something).
After that, I reinstalled openSUSE but without formatting the boot partition, and now it still boots into Fedora automatically but if I enter the BIOS boot menu manually I can select openSUSE’s GRUB menu. So I have two GRUB efi images in /boot/efi.

Does your system offer any means to edit boot menu? If yes, did you try to add this file to boot menu manually?

Yes, it does offer this option, and I tried it without any luck. It doesn’t let me choose an efi image, but asks me to write a boot entry. I tried “opensuse” but it wouldn’t work.
By the way, in Fedora, efibootmgr -v says:

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0003
Boot0000* Fedora    HD(1,800,fa000,23b25eea-b3ba-491e-9113-c680b990b016)File(\EFI\fedora\shim.efi)
Boot0001* Fedora    ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000HD(1,800,fa000,23b25eea-b3ba-491e-9113-c680b990b016)File(\EFI\fedora\shim.efi)..
Boot0002* Fedora    ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000HD(1,800,fa000,23b25eea-b3ba-491e-9113-c680b990b016)File(\EFI\fedora\shim.efi)..
Boot0003* Fedora    ACPI(a0341d0,0)PCI(1f,2)03120a00000000000000HD(1,800,fa000,23b25eea-b3ba-491e-9113-c680b990b016)File(\EFI\fedora\shim.efi)..

[arvidjaar]

@bogdanc2011

… or something … it wouldn’t work …

You give zero information about what you did and what is result. So anyone trying to help here basically performs guesswork.

Anyway, you could try to run “grub2-install” in openSUSE. With some luck it adds entry for openSUSE to your EFI boot menu.

[bogdanc2011]

@arvidjaar

You give zero information about what you did and what is result. So anyone trying to help here basically performs guesswork.

Anyway, you could try to run “grub2-install” in openSUSE. With some luck it adds entry for openSUSE to your EFI boot menu.

The errors are:

error: can't find command 'linux'
error: can't find command 'initrd'

That’s with Fedora’s GRUB that loads automatically.

About that custom boot option, it asks me to “enter custom boot path”. I’m not sure what to write in there.

grub2-install changed nothing.

But I did notice that /boot/efi/EFI/fedora has these files:

-rwxrwxr-x 1 root root     102 Nov 13 21:00 BOOT.CSV
drwxrwxr-x 2 root root    8192 Dec 14 06:54 fonts
-rwxrwxr-x 1 root root  931176 Aug 10 16:48 gcdx64.efi
-rwxrwxr-x 1 root root   10665 Dec 14 18:11 grub.cfg
-rwxrwxr-x 1 root root  931176 Aug 10 16:48 grubx64.efi
-rwxrwxr-x 1 root root 1273264 Nov 13 21:00 MokManager.efi
-rwxrwxr-x 1 root root 1390152 Nov 13 21:00 shim.efi
-rwxrwxr-x 1 root root 1381448 Nov 13 21:00 shim-fedora.efi

/boot/efi/EFI/opensuse has only grubx64.efi

[oldcpu]

@bogdanc2011

/boot/efi/EFI/opensuse has only grubx64.efi

Strange. When openSUSE was installed, was the secure boot install selected ?

[arvidjaar]

@bogdanc2011

The errors are:

error: can't find command 'linux'
error: can't find command 'initrd'

That’s with Fedora’s GRUB that loads automatically.

This is bug in Fedora’s os-prober; it is fixed in openSUSE.

About that custom boot option, it asks me to “enter custom boot path”. I’m not sure what to write in there.

Does it provide a way to select file? If not … it is hard to answer not seeing actual interface. Manually entering EFI device path won’t be fun, I agree.

grub2-install changed nothing.

If I read this correctly you state that Fedora can modify EFI variables and openSUSE can not.

But I did notice that /boot/efi/EFI/fedora has these files:

It has absolutely nothing to do with your problem.

What you could do now.

1. boot Fedora
2. Check device name where /boot/efi is mounted. Let’s assume it is /dev/sdb1.
3. run the following command

efibootmgr -c -d /dev/sdb -p 1 -w -L opensuse -l '\EFI\opensuse\grubx64.efi'

Here device (/dev/sdb) and partition (1) must correspond to device where /boot/efi is mounted

1. Verify with “efibootmgr -v” that “opensuse” boot entry was really created.

[bogdanc2011]

@oldcpu

Strange. When openSUSE was installed, was the secure boot install selected ?

No.

Does it provide a way to select file? If not … it is hard to answer not seeing actual interface. Manually entering EFI device path won’t be fun, I agree.

No, it’s only a text field. That’s why it’s such a pain.

If I read this correctly you state that Fedora can modify EFI variables and openSUSE can not.

My guess is that for some reason Fedora writes to the NVRAM and openSUSE doesn’t. I understand that efibootmgr is the one that writes to the NVRAM.
So I did like arvidjaar](https://forums.opensuse.org/members/arvidjaar.html) said:

efibootmgr -c -d /dev/sda -p 1 -w -L opensuse -l '\EFI\opensuse\grubx64.efi'

Indeed the entry is created but it still loads Fedora’s bootloader. Apart from that, there were about ten entries in efibootmgr, 8 of them being “Fedora” and the last two opensuse and opensuse-secureboot.
So I went ahead and deleted all of them and then added opensuse using that command. Now efibootmgr -v is:

BootCurrent: 0000
Timeout: 0 seconds
Boot0000* opensuse      HD(1,800,fa000,23b25eea-b3ba-491e-9113-c680b990b016)File(\EFI\opensuse\grubx64.efi)

Reboot and still Fedora’s bootloader loads as default. This time, for a fraction of a second, I see an error, which I’ve managed to capture with my camera:

And after checking again, this is when Fedora creates all those entries, after every reboot.
So I backed up and deleted /boot/efi/EFI/fedora, deleted all the entries in efibootmgr and let Yast add its own entry with secureboot enabled. Rebooted and it still tries to load Fedora’s bootloader. But it gets stuck in a loop because it can’t find the files, reboots and so on.

I’m starting to think I should clear the NVRAM memory in some way, but I have no idea how on a laptop.

[arvidjaar]

@bogdanc2011

This time, for a fraction of a second, I see an error, which I’ve managed to capture with my camera:

Now that was helpful. I begin to remember that there was at least one vendor who ignored any boot menu entry unless it contained word Windows. May be we see the same issue but “fixed” by adding Fedora to the list See mjg59 | More in the series of bizarre UEFI bugs

Unfortunately it is extremely hard to investigate problems caused by buggy firmware without actually having access to such systems. You may try to open bug report on openSUSE bugzilla so at least it is recorded and someone may get an idea.

[gogalthorp]

WARNING Clearing the UEFI memory may brick the machine

[bogdanc2011]

@arvidjaar

Now that was helpful. I begin to remember that there was at least one vendor who ignored any boot menu entry unless it contained word Windows. May be we see the same issue but “fixed” by adding Fedora to the list See mjg59 | More in the series of bizarre UEFI bugs

Unfortunately it is extremely hard to investigate problems caused by buggy firmware without actually having access to such systems. You may try to open bug report on openSUSE bugzilla so at least it is recorded and someone may get an idea.

Well I tried to trick the system by copying “opensuse” to “fedora” (the folders in /boot/efi/EFI) and adding the entry as fedora. No luck
What’s more annoying is that even by having no entries in the NVRAM it still goes to Fedora’s bootloader automatically.

[bogdanc2011]

I had a breakthrough.
After messing with gummiboot, I realised that apart from copying an .efi image to /boot/efi/EFI/gummiboot, it actually copies the same image to /boot/efi/EFI/BOOT/BOOTX64.EFI. So I did the same thing with my openSUSE efi image and IT WORKS. It doesn’t even matter what entries are in the NVRAM.

[oldcpu]

@"bogdanc2011

@oldcpu

@bogdanc2011;2608239

/boot/efi/EFI/opensuse has only grubx64.efi

Strange. When openSUSE was installed, was the secure boot install selected ?

No.

My guess would be if secure boot install is not selected, then it makes sense that /boot/efi/EFI/opensuse has only grubx64.efi (and not shim.efi).

[bogdanc2011]

@oldcpu

My guess would be if secure boot install is not selected, then it makes sense that /boot/efi/EFI/opensuse has only grubx64.efi (and not shim.efi).

That is correct. After installing with secureboot enabled I have those files as well.

[bogdanc2011]

It seems that Fedora is using a customised GRUB2 installation:

GRUB 2 on UEFI for Fedora 18 has been tweaked a lot to support Secure Boot. Unfortunately that also mean that Fedora 18 GRUB 2 is quite different from what upstream provides and loses some of the nice properties it has and which can be seen on BIOS systems.

So it might be a GRUB issue afterall. I think what Yast does is just run grub-mkconfig and grub-install.

[arvidjaar]

@bogdanc2011

After messing with gummiboot,

Huh?!? This is the first time ever you mention gummiboot. Oh, well …

/boot/efi/EFI/BOOT/BOOTX64.EFI. So I did the same thing with my openSUSE efi image and IT WORKS.

Well, that’s default path that firmware takes if you ask it to boot from HDD without giving any explicit path. What is confusing - on your screenshot it explicitly says \EFI\fedora. May be this message comes from whatever was in \EFI\BOOT … I’ll have to look at what gummiboot does.

So it might be a GRUB issue afterall. I think what Yast does is just run grub-mkconfig and grub-install.

grub-install does efibootmgr. Nothing more. If you want to help with this issue - open bug report on openSUSE bugzilla and post number here. Be prepared to answer questions and do testing - if not, bug report probably makes little sense.

[bogdanc2011]

Huh?!? This is the first time ever you mention gummiboot. Oh, well …

It’s the first time I use it.

[nrickert]

@bogdanc2011

After messing with gummiboot, I realised that apart from copying an .efi image to /boot/efi/EFI/gummiboot, it actually copies the same image to /boot/efi/EFI/BOOT/BOOTX64.EFI. So I did the same thing with my openSUSE efi image and IT WORKS. It doesn’t even matter what entries are in the NVRAM.

Some BIOSes do not fully implement the UEFI standard. They use what’s in ‘\EFI\BOOT’ instead of what’s in NVRAM. It seems that you have such a BIOS. You will need to remember that, for future installs.