Bug 820542

Summary:	On UEFI box, grub2-efi menu is not being updated after kernel install
Product:	[openSUSE] openSUSE 12.3	Reporter:	Neil Rickert <nwr10cst-oslnx>
Component:	Bootloader	Assignee:	Steffen Winterfeldt <snwint>
Status:	RESOLVED DUPLICATE	QA Contact:	Jiri Srain <jsrain>
Severity:	Normal
Priority:	P5 - None	CC:	jreidinger
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE 12.3
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	file as requestd Output of "efibootmgr -v" from the same machine.

Description Neil Rickert 2013-05-17 23:31:47 UTC

User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0

I am running Tumbleweed on two boxes.  One of those uses grub2.  The other is a UEFI box, and uses grub2-efi.

Today there was a kernel update.

On the grub2 (traditional BIOS) box, the boot menu was updated.  When I rebooted, I was using the new kernel.

On the UEFI box, after rebooting, I was still using the previous kernel.  A check of "/boot/grub2/grub.cfg" showed that it had not been updated (it had a May 15th date from when I had manually run grub2-mkconfig).  However, everything in the subdirectory "/boot/grub2/x86_64-efi" has been updated (time stamp similar to that of the "initrd" file for the new kernel.

I was not paying as much attention before, but I'm pretty sure this also happened with the previous kernel update.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1 Jiri Srain 2013-05-20 07:58:00 UTC

Please, attach the perl-Bootloader's log from the uEFI machine...

/var/log/YaST2/perl-BL-standalone-log

Comment 2 Neil Rickert 2013-05-20 15:12:30 UTC

Created attachment 540143 [details]
file as requestd

Thanks for pointing me to that file.  I think I know what happened.  I'll add a detailed comment.

Comment 3 Neil Rickert 2013-05-20 15:14:19 UTC

Created attachment 540145 [details]
Output of "efibootmgr -v" from the same machine.

Comment 4 Neil Rickert 2013-05-20 15:25:45 UTC

What probably happened, is that the UEFI firmware saw an attempt to add a duplicate NVRAM entry, and refused.  See the attached "efibootmgr -v" output.

Note that the entry for "Windows Boot Manager" actually refers to '\EFI\opensuse_alt\shim.efi' which is what a reinstall of shim.efi would have tried to duplicate.

I am doing that to experiment with a workaround for the problems caused by Windows 8.  If it sees that its boot entry is missing from NVRAM, it puts it back and perhaps wipes out other entries.  So, following a suggestion I found on the web, I have told Windows to use shim.efi as its boot manager.  That seems to be working with Windows.  But apparently it interferes with opensuse updates.

The big problem, in my opinion, is the decision of opensuse to reinstall the bootloader with each "mkinitrd".  I would prefer that it only update grub.cfg, and not attempt the reinstall.

Before I made that Windows Boot Manager change, here is what would have happened with the kernel update:

1:  An entry for opensuse would have been added to NVRAM
2:  The Windows boot entry would have been erased by the firmware
3:  When Windows was next booted, it would have reinstalled itself
4:  The opensuse entry in NVRAM would have been erased by the firmware.

(and then I would have had to fix that mess).

In short, reinstalling grub2-efi causes headaches.  Just running "grub2-mkconfig" does not cause any problems.

Comment 5 Neil Rickert 2013-06-02 15:24:22 UTC

This bug appears to be related to the same problem as bug 822770 (see the discussion there) and seems to be due to either a kernel bug or a bug in "efibootmgr".

Comment 6 Josef Reidinger 2016-10-06 13:55:24 UTC

duplicate of previously mentioned bug

*** This bug has been marked as a duplicate of bug 822770 ***