You are not logged in.

#1 2013-06-22 20:42:58

ivokosir
Member
Registered: 2013-03-08
Posts: 20

[MOOT]gummiboot install: Failed to create EFI boot variable entry

I have made fresh install on my laptop, and i want to install with uefi, and gummiboot as my bootloader, but i get this error "Failed to create EFI boot variable entry: No such file or directory" after running "gummiboot install".
I have kernel 3.9(2013.06.01 iso) but my "/sys/firmware/efi/efivars" is empty, and i suspect that is the problem.
I think i have booted to UEFI because my "/sys/firmware/efi" on liveUSB is not empty.

thanks

Last edited by ivokosir (2013-06-23 16:22:55)

Offline

#2 2013-06-22 22:26:33

the.ridikulus.rat
Member
From: Indiana, USA
Registered: 2011-10-04
Posts: 765

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

Boot with "efi_no_storage_paranoia" kernel parameter and try again.

Offline

#3 2013-06-22 22:44:34

ivokosir
Member
Registered: 2013-03-08
Posts: 20

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

How am I going to boot it if i didn't install my bootloader?

Offline

#4 2013-06-23 00:55:06

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

Are you able to boot with UEFI at all?  If you are not booted with UEFI, it is no surprise that you are not able to create the firmware entry.  If gummiboot successfully copied itself to \EFI\gummiboot\ as well as \EFI\boot\bootx64.efi, then you cam boot with gummiboot by simply enabling UEFI only (or first if that option is given) and then selecting that actual drive to boot from, like you were going to boot with legacy bios. 

The \EFI\boot\bootx64.efi spot is referred to as the "default" spot because it is what is automatically selected when you choose a drive.  According to srs5694, this was origianlly included in the UEFI spec for removable media, since obviously you were not going to have a firmware entry for a thumbdrive for instance.  But it has since been extended to most implementations of UEFI.  Some firmwares actually use whatever path M$ uses as its default spot though, so you have to be wary of that.  Then some use both... though which gets chosen depends on your firmware.

Offline

#5 2013-06-23 16:22:38

ivokosir
Member
Registered: 2013-03-08
Posts: 20

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

According to beginner's guide i am booting UEFI.
I mounted my UEFI partition to "/boot" and i have "\EFI\boot\bootx64.efi" and "\EFI\gummiboot\".

Finally i have decided to use BIOS, but i will take your advice if i want to install UEFI again.
Thanks

Offline

#6 2013-06-23 19:13:04

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

Wow, you gave up so quickly, how come? 

Did you try booting with the.ridikulus.rats suggestion?  If the system detects that the nvram is full to a certain point it will refuse to write the entries as a safety precaution.  The only problem with this is that they decided on an arbitrary 50% full while they hashed out the details.  So for example, the machine that was at the greatest risk were to samsungs that were being bricked.  But Samsung actually told the folks working on this that the nvram can safely be written to within 5% of being full(I think it was 5%... it might have been 5kb.  It was 5 something).  So by temporarily booting with efi_no_storage_paranoia, you can disregard this wildly conservative check and potentially write the vairables.

Otherwise it may be recent bugs that some users have experienced with recent versions of efibootmgr and the kernel.  In these cases, downgrading the kernel and efibootmgr will trypically solve the problem.  Still, you could simply rely on the "default" boot loader spot as described above.  There is nothing wrong with doing it that way if it works.

Offline

#7 2013-06-23 22:06:09

ivokosir
Member
Registered: 2013-03-08
Posts: 20

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

Well it was not that quickly...
I took a lot of time before posting looking for the solution.
I will try UEFI later when things become more stable.

Offline

#8 2013-06-24 00:14:37

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

Keep in mind that UEFI and bios booting can coexist on your machine.  So it is not like you have to rid yourself of one way in order to get the other going.  I think if it weren't for that fact, I would have never been able to get UEFI booting going on my machine.

Offline

#9 2013-08-03 14:37:51

totolotto
Member
From: Hungary
Registered: 2012-11-13
Posts: 114

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

I had the same error message but I continued the process anyway and created arch.conf and loader.conf (because I thought the gummiboot was complaining about these files). And after reboot it worked, and has been working gummiboot since then.

Offline

#10 2013-08-03 21:09:23

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

@totolotto, this is because the "gummiboot install" also copies itself to the "default" spot (which is \EFI\BOOT\BOOTX64.EFI).  So when that disk is selected to boot, this is what will be automatically booted.  You may want to try using an efibootmgr command manually.  I recently had to rest my bios, and I too noticed that the command failed to create an entry (though it did not tell me so).  But doing it manually was no problem.  Otherwise, it could be that the efivars module was not loaded.  That would certainly prevent the gummiboot command from creating an entry, and unlike in the past, the efivars module is not automatically loaded (and it is not built into the kernel like it was at first in the Arch kernel).

Offline

#11 2013-08-03 21:50:30

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

I do love the idea of giving your BIOS a rest - are we talking soft pillows and lullabies or luxurious breaks on exotic beaches?


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#12 2013-08-04 06:46:26

totolotto
Member
From: Hungary
Registered: 2012-11-13
Posts: 114

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

WonderWoofy wrote:

  You may want to try using an efibootmgr command manually.

1. The list of boot entries in UEFI Shell 2.0 shows 6 options, one of them is "UEFI: Samsung SSD....". This one is used for booting into Arch Linux.

2. The "efibootmgr" command returns with:

Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables.
Try 'modprobe efivars' as root.

After trying 'modprobe efivars' the command 'efibootmgr' returns with nothing - it should list the available entires, shouldn't it?

Does this mean that something is not okay and I still have some work to do here?

Offline

#13 2013-08-04 14:09:06

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

totolotto wrote:

After trying 'modprobe efivars' the command 'efibootmgr' returns with nothing - it should list the available entires, shouldn't it?

Yes. It should. What is in /sys/firmware/efi before and after you modprobe efivars? If you have sub-directories like efivars or vars, are they populated?


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#14 2013-08-04 14:55:12

totolotto
Member
From: Hungary
Registered: 2012-11-13
Posts: 114

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

My bad - even just for listing the entries efibootmgr needs to be run as sudo. Now I can see the options.

However my question still stands becasue WonderWoofy's respond implies that I have not done something correclty. Can you make a comment on that?

Offline

#15 2013-08-04 15:25:38

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

It isn't necessarily that you did anything incorrectly. I don't use gummiboot but as I understand it, it sometimes fails to create the boot menu entry properly. You are probably booted using EFI/boot/bootx64.efi as gummiboot copies itself here as well. This is a "fallback" entry which the firmware uses if it cannot find a valid EFI boot menu entry. This is fine and sometimes the only option but boot managers/loaders tend to fight over this spot. So you could try adding an entry for gummiboot manually using efibootmgr afer modprobing efivars. The wiki explains how to do this. This would point to the EFI application in e.g. EFI/gummiboot/ or whatever. (I'm not sure what gummiboot uses so this is just for example.)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#16 2013-08-04 16:00:38

totolotto
Member
From: Hungary
Registered: 2012-11-13
Posts: 114

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

What is the difference between a valid EFI boot menu entry (created either by a boot manager or manually) and the "fallback" entry? I did not do the manual addition bacuase it just works. You also wrote that the fallback entry is fine but I am curious if there is any advantage in creating a new entry manually. Thanks for your help & time.

Offline

#17 2013-08-04 17:15:33

srs5694
Member
From: Woonsocket, RI
Registered: 2012-11-06
Posts: 719
Website

Re: [MOOT]gummiboot install: Failed to create EFI boot variable entry

totolotto wrote:

What is the difference between a valid EFI boot menu entry (created either by a boot manager or manually) and the "fallback" entry?

The EFI boot process goes something like this:

  1. The firmware reads a list of boot loaders from NVRAM and tries to run each of them in the order specified in the NVRAM. If one of them boots an OS, then that OS takes control and the rest of the process is aborted.

  2. The firmware tries to run the fallback boot loader -- that is, the EFI/BOOT/bootx64.efi boot file (on x86-64 systems). If this boots an OS, then the rest of the process is aborted.

  3. The firmware launches its own user interface or system-specific boot program. (Some launch an EFI shell program, for instance, if one is available. Some launch EFI/Microsoft/Boot/bootmgfw.efi. Others just enter the firmware setup utility.) There's a lot of system-to-system variability in this step.

As a practical matter, the fallback boot loader works much like a boot loader registered in the NVRAM. There are some subtle differences, though:

  • Because the fallback boot loader is launched last, NVRAM entries generally take precedence, so an OS installer can't really count on the fallback boot loader ever being run. You as an administrator might be able to assume it will be run, but only if you fully understand what (if anything) is in your NVRAM boot list and you know that nothing there is valid or will be run first.

  • The fallback loader's filename is generic and gives no clues about what it is. This makes it awkward to administer or diagnose system problems.

  • Depending on how a boot loader is coded, it might require configuration files in the EFI/BOOT directory, in the directory in which the program would ordinarily be installed, or in some other fixed location. This creates more configuration options and can create confusion if you don't have an expert understanding of how the programs work.

  • Some EFIs don't use the fallback filename at all, except on removable media.

  • Some EFIs are broken and keep forgetting their NVRAM entries or ignore these entries unless they contain certain data (such as if they point to EFI/Microsoft/Boot/bootmgfw.efi or have a name of "Windows Boot Manager").

I did not do the manual addition bacuase it just works. You also wrote that the fallback entry is fine but I am curious if there is any advantage in creating a new entry manually. Thanks for your help & time.

Creating a proper NVRAM entry is theoretically the right way to do it. As a practical matter, though, EFI bugs sometimes necessitate using the fallback filename. Even when this isn't strictly necessary, using the fallback filename often works fine, although the uncertainties about what's really in that file mean that you'd better understand your setup when you do this -- if you post asking for help, it will take longer for your helper to figure out how your system should be working if you use the fallback boot file.

As a practical matter, if your system is booting correctly by using the fallback boot loader filename, you could follow the adage, "if it ain't broke, don't fix it." Just be aware of how the system is configured so that when (not if) it requires maintenance in the future, you'll be able to manage it. (Note that the "when" clause isn't a put-down of the fallback boot loader method of booting; it's just that all computers need boot loader maintenance, sooner or later, except for computers that fail catastrophically early in life.)

Offline

Board footer

Powered by FluxBB