UEFI Boot Entry Disappeared After Updates?

English Install/Boot/Login
#1

I installed openSUSE 13.1 on my laptop a little bit ago, and the “opensuse” boot entry under my firmware settings was present. I did some updates (200 some packages), rebooted, and the boot entry was gone (thus I couldn’t boot openSUSE).

I don’t recall this happening in the past with 13.1. My HDD passes S.M.A.R.T. too so I doubt it was corruption.

I already reinstalled 13.1, but I was wondering if anyone might know why this happened?

I have an Acer Aspire V3 551G-X419 laptop also with the latest BIOS (2.14).

#2

It is more likely a problem with your BIOS, rather than a problem with your disk. Some BIOS do nasty things with NVRAM entries.

If this happens again, you should be able to boot to rescue mode (either use live media or the DVD), and recreate the needed NVRAM entry with the command “efibootmgr”. The man page for “efibootmgr” is reasonably good…

#3

It seemed to of happened again on a clean install. For now, I just reinstalled in BIOS mode (I’m not entirely confident in my laptop’s EFI implementation anyway).

#4

I’m new to UEFI and trying to learn more so I can (1) support my own PCs and (2) help some colleagues using openSUSE.

It reads like you solved your problem with a ‘BIOS mode reinstallation’. By that do you mean you changed the setting in the firmware from UEFI to BIOS (CSM ? ) . Do you have a Microsoft OS also onsame laptop, and if so does it still boot ?

Also, you noted previous you could not ‘boot openSUSE’. Did another OS (such as MS-Windows) boot ?

The above is just for my own edification (learning). Thanks !

#5

I have also been trying to learn UEFI since it is the future. I have learned that the vendor specific implementation of UEFI varies greatly (as well as UEFI versions). I have three machines running in UEFI mode, and all three act differently. My Dell laptop runs perfectly with Win8/openSUSE including secure boot. It has the newest version of uefi. The dell desktop doesn’t work because win8 takes over the uefi entries and erases the openSUSE entry after updates. The HP all-in-one is the worst. I have to create a separate uefi partition to get a dual boot to work. It has the oldest uefi version. Depending on your vendor, your mileage may vary.

#6

If that’s the same problem that I am seeing, then it is easy to fix (or work-around). See my blog post Notes on UEFI, Windows and linux

#7

I actually ran across your tutorial when I first fought with this. :slight_smile: My desktop is also Dell 660. I would have made it work, but decided not to keep win8 on it. Adding the second efi partition worked on the HP.

#8

On Mon 13 Jan 2014 10:36:01 PM CST, 67GTA wrote:

I actually ran across your tutorial when I first fought with this. :slight_smile:
My desktop is also Dell 660. I would have made it work, but decided not
to keep win8 on it. Adding the second efi partition worked on the HP.

Hi
You should give gummiboot a go, it cleaned up the uefi in the HP
Norebook (ProBook 4430s), the HP 2000 with Windows 8 and SLED/openSUSE
works fine even with secure boot. My other HP ProBook 4525s also works
fine with openSUSE, but not with SLED…oh well…

–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 13.1 (Bottle) (x86_64) GNOME 3.10.2 Kernel 3.11.6-4-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

#9

My laptop has a switch in the BIOS for either using UEFI or Legacy BIOS modes. Switching the mode reboot the laptop into that respected mode (the general BIOS appearance doesn’t change at all though).

If I saw correctly, it would also seem that switching between Legacy and UEFI also change the version string of the Video BIOS in-use too (my BIOS shows a VBIOS string for both my iGPU and dGPU; it specifies a UEFI GOP BIOS on the iGPU when in UEFI for what I imagine to be Windows 8 Ultra-Fast Boot compliance).

I only had openSUSE on the hard drive at the time; wiped Windows out completely. SecureBoot is disabled.

When changing between the modes, the laptop can only boot the respected mode on installation media (so if I insert a Windows DVD on UEFI mode, the UEFI installer automatically begins with no option to use Legacy).

On my desktop however (ASRock 970 Extreme3), I have the choice of using either UEFI or Legacy boot without changing the entire firmware mode. If I disable CSM, I won’t be able to boot in Legacy mode though.

As for the openSUSE-specific problem though, it seems to be some update that possibly messes with GRUB or something. I’ve used openSUSE for a bit back around 13.1’s launch, and don’t recall having any problems. On my desktop, the UEFI entry is still present even after updates too, so it’s just something on my laptop that’s acting strangely.

#10

I just received (last night) a new desktop PC with a Gigabyte GA-Z87X-D3H motherboard. The PC has a 2TB HD and a 256 GB SSD drive. There is no operating system (no data either) on the HD and SSD drives currently. I did boot to an openSUSE-13.1 liveDVD successfully prior to rebooting to firmware, and then I rebooted direct to firmware to obtain these images. An attempt to boot to an openSUSE-13.1 liveUSB failed, but I need to confirm the USB stick is still good (it did work a month ago on my Ultrabook).

I have different selections than you, and this goes to illustrate the differences between manufacturers.

Note below :
http://thumbnails112.imagebam.com/30115/0e6963301146985.jpg](http://www.imagebam.com/image/0e6963301146985)

with a zoom in here …
http://thumbnails109.imagebam.com/30115/796d68301146987.jpg](http://www.imagebam.com/image/796d68301146987)
where I have 3 (and not just two) selections for UEFI or Legacy. I don’t yet understand the ramifications of the combined UEFI/Legacy mode.

.
and note here there are boot options that can be selected for booting and also selections currently assigned P0, P1, P2 … etc . I do not understand what P0, P1, P2 means. Could it be priority ? Or is it simply an arbitrary number assignment to a device ?
http://thumbnails110.imagebam.com/30115/c113a6301146988.jpg](http://www.imagebam.com/image/c113a6301146988)

.
and note here when saving any changes to the Firmware, I obtain the following confirmation, which does not yet (for me) shed any light on this.
http://thumbnails111.imagebam.com/30115/24d1b7301146990.jpg](http://www.imagebam.com/image/24d1b7301146990)

I have more studying to do to understand this.

#11

Further to the above, when reading my new Gigabytte motherboard ‘User’s Manual’, I noted some firmware controls that I over looked previous in my initial glance of the settings.

The CSM Support on my motherboard provides two options: Always (which enables UEFI CSM and is the default setting), and Never (which disables UEFI CSM and supports UEFI BIOS boot process only). The user manual advises that this item is configurable only when the OS type is set to “Windows8” or “Windows 8 WHQL”. On my motherboard I have the OS type set to the default setting, which is “Other OS”. Hence that implies that the default value for “CSM Support” of ‘Always’ is always set (to enable UEFI CSM).

Then there was the boot mode selection, which is designed to allow various operating systems to boot :
http://thumbnails110.imagebam.com/30120/e1bb77301192672.jpg](http://www.imagebam.com/image/e1bb77301192672)
However given I do not have Windows8 selected, and given that the CSM support is at its default value of “Always” -> that implies this Boot Mode selection allows me no choice, but rather is always set to “UEFI and Legacy”.

This suggests to me that a UEFI compatible GNU/Linux distribution may not be necessary for this motherboard with it as set today.

I then noted the Storage Boot Option, and this is where things get very fuzzy for me.
http://thumbnails112.imagebam.com/30120/3b3d47301192673.jpg](http://www.imagebam.com/image/3b3d47301192673)

I think I’ll start another thread on this, as the difference between “disabled”, “legacy only” , “uefi only” , “legacy first” , and “uefi first” given I will have both an HD and an SSD drive is lost on me - and as well the difference between “Legacy OpROM and UEFI OpROM” is lost on me.

#12

This still seems to be happening. Just installed openSUSE 13.1 again on my laptop, installed all available updates, rebooted, and can’t boot back into openSUSE due to the UEFI entry being removed.

Edit: https://forums.opensuse.org/showthread.php/492039-Repair-Grub2-Efi-Boot-Entry-in-Rescue-Console-form-DVD?p=2597929#post2597929 seems to fix it nicely, but it’s still really weird that this happens. Maybe one of the updates I install updates grub, but it doesn’t regenerate boot entries on its own?

#13

grub2 update reistalls bootloader which also regenerates boot entries. To troubleshoot it one would need to reproduce this. Could you try record current “efibootmgr -v” output, run “update-bootloader --reinit” and check with “efibootmgr -v” whether entries are missing? Then reboot and check again?

#14

There seem to be some EFI BIOSes that will only boot Windows. There is a trick to get around the bad behavior

Essentially you copy the files from the openSUSE section of the EFI/boot and rename them the same as those files in the Windows section replacing the Windows boot code with openSUSE boot code. So then the machine will always boot to Grub2 and never direct into Windows. You should of course backup the Windows files just in case you need them

oldcpu

the UEFI + legacy mean you can have a MBR based boot along side a EFI based boot. Some how it make me think of Rub Goldberg :open_mouth:

#15

Is this still the same ACER computer?

Try the following command in Windows (from an Administrator command prompt)


bcdedit /set {bootmgr} path \EFI\opensuse\shim.efi

This assumes that your opensuse system is setup for secure boot. If not, then change that “shim.efi” to “grubx64.efi”.

If you ever want to undo that change, here’s the Windows command:


bcdedit /set {bootmgr} path \EFI\Microsoft\Boot\bootmgfw.efi

I’ll note that one of the Windows updates (the one people have been calling “update 1 to windows 8.1” failed to install on my system, until I undid that change (as indicated). I then redid the change and all is still working.

This solves a quirk found in some UEFI implementations. We won’t really know if it solves your problem until you try it.

#16

Is this the good (rather: bad) old “Win8.x-overwriting-everything-after-boot” problem? If you haven’t made any power adjustments inside Win8.x that you know of, then expect it to be that:

Windows 8 and Windows 8.1 are similar in that area, and you can see the link below for a way to adust Win8.x. I recommend the graphical way as that seems to do more adjustments inside Windows than the command line equivalent (I haven’t seen it documented, but there have been problems solved by the GUI-method that the command line method didn’t solve, so maybe MS is pulling some undocumented trick). Also beware the the actual wording has changed in W8.x since I wrote this (W8 has been upgraded/patched several times since) but I don’t think you will be confused anyway. Take a look here:
https://forums.opensuse.org/showthread.php/487837-How-to-Dual-boot-(preinstalled)-Windows-8-and-Linux-UEFI-etc#4
in particular the “Preparing Windows 8 for dual-booting:” item 4. That trick may solve your problem, but you still may need to make one more reinstall of grub after doing this. You may also want to take a look at part 6.

Good luck!

dayfinger

#17

Installed 13.1, updated it, and did efibootmgr -v before rebooting; there were no entries. Did the update-bootloader --reinit command and then checked efibootmgr -v again, and opensuse was there. Rebooted and booted openSUSE without issue.

Also, Windows isn’t installed on the computer atm (openSUSE is using the entire disk), and SecureBoot is disabled. Just to re-clarify the problem, openSUSE and other Linux distros boot just fine in UEFI on this laptop. openSUSE 13.1 boot fine initially, but after installing updates, the UEFI boot entry disappears. Re-initializing the bootloader with the above command however (or just manually re-adding it via efibootmgr) re-adds the boot entry and allows for successful boot. The boot entry seems to stick after reboots as well.

#18

Please open bug report and attach yast logs from this system (/sbin/save_y2logs); mention bug number here. I assume you did have menu entries before update? Having “efibootmgr -v” output immediately before update would be helpful.

#19

Besides the comprehensive explanation given in this thread, you can have a look here too:
http://www.rodsbooks.com/linux-uefi/

#20

https://bugzilla.novell.com/show_bug.cgi?id=887066 (uploaded that y2logs on the bug report)

Here’s my efibootmgr -v output right after openSUSE 13.1 install:

BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000
Boot0000* opensuse      HD(1,800,4e000,d44b2e19-8e12-4b50-bc4b-fba770312da4)File(\EFI\opensuse\grubx64.efi)

And here it is after installing all 508 updates (as of today):

BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000

And here it is after running update-bootloader --reinit:

BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0000
Boot0000* opensuse      HD(1,800,4e000,d44b2e19-8e12-4b50-bc4b-fba770312da4)File(\EFI\opensuse\grubx64.efi)