https://bugzilla.novell.com/show_bug.cgi?id=820542 https://bugzilla.novell.com/show_bug.cgi?id=820542#c4 --- Comment #4 from Neil Rickert <nrickert@ameritech.net> 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. -- 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.