You are not logged in.
Pages: 1
Topic closed
Installing gummiboot gives me an error: "Failed to create EFI Boot variable entry: No space left on device". Gummiboot copies the .efi files correctly however, and the machine boots (presumably from /EFI/Boot/BOOTX64.EFI). I am in EFI mode, and efivars is mounted automatically.
Gummiboot is able to list the variables:
[topyli@hyry ~]$ sudo gummiboot
Boot Loader Binaries:
ESP: /dev/disk/by-partuuid/28961f34-6164-4f9a-a3e4-9551fe7e4f4c
File: └─/EFI/gummiboot/gummibootx64.efi (gummiboot 39)
File: └─/EFI/Boot/BOOTX64.EFI (gummiboot 39)
Boot Loader Entries in EFI Variables:
Title: opensuse
ID: 0x000A
Status: active, boot-order
Partition: /dev/disk/by-partuuid/f6f58236-3c1f-4d05-a066-77995c1c5c9a
File: └─/EFI/opensuse/grubx64.efi
Title: Linux Boot Manager
ID: 0x000B
Status: active
Partition: /dev/disk/by-partuuid/f6f58236-3c1f-4d05-a066-77995c1c5c9a
File: └─/EFI/gummiboot/gummibootx64.efi
but efibootmgr is not:
[topyli@hyry ~]$ sudo efibootmgr
efibootmgr: Cannot allocate memory
Like I said, the machine boots. However, I would like to get rid of the "opensuse" leftover which still shows in my EFI BIOS's boot options, and make the "Linux Boot Manager" entry active. How should I proceed?
Offline
Full nvram can be a dangerous situation. This is what lead to the bricked samsungs a few months back. But it would appear as though you don't have much in the way of efibootmgr entries, so that shouldn't be the issue. To remove that old entry, you simply need to use efibootmgr. See the man page for more info (of the --help).
You should also have a look here to make sure that the pstore area is not full. In Arch, this is no longer mounted by default and thus dumps do not get written there. But when this functionality first came about, we did do it. I have no idea what OpenSuse might do, so checking it to make sure its not full of shit is probably a good idea.
If you are absolutely sure that writing an nvram entry should be safe, you can boot temporarily with the efi_no_storage_paranoia kernel command line option. Do NOT boot with this option regularly, as it disables the safegards that are in place to ensure that the system doesn't fill the nvram.
Edit: I should mention that I had my Thinkpad bricked immediately following a kernel panic. I don't know for sure, but I suspect that it was due to the nvram being filled. The machine was under warranty and the motherboard was replaced. After this occurred, I contacted Matthew Garrett about the situation and described what had happened. He also suspected the same thing and mentioned that this bricking risk is not unique to samsungs. But anyway, that is why I know about this crap.
Last edited by WonderWoofy (2013-12-01 20:56:43)
Offline
edit
Last edited by Grant (2013-12-01 20:58:31)
Offline
edit
Offline
Grant wrote:edit
I was going to check a thing I was unsure, but you answer should have solved his doubts, then my answer is no longer useful. I don't really care of the post counter but I wouldn't rather write rubbish.
Offline
Thank you WonderWoofy. I'll study a bit more and then maybe take a look at what I can accomplish with efibootmgr. This is only my second EFI install (the opensuse being first), so I'm not too afraid of nvram really being full.
BTW, this machine of mine is also a ThinkPad (Edge), and also still under warranty. :-)
Offline
Cool, I have an E430. Maybe you should check for a bios update for your machine. They update it fairly frequently so maybe you have something buggy in the firmware. UEFI bugs are not partiuclarly uncommon since it is new and vendors slap a bunch of proprietary crap on top of the Tianocore base.
You should know that using the \EFI\boot\bootx64.efi method of booting is not a terrible option either.
Offline
UEFI bugs are not partiuclarly uncommon since it is new and vendors slap a bunch of proprietary crap on top of the Tianocore base.
You should check the edk2-devel mailing list, where the Tianocore developers hang out. Lots of bug fixes get committed there on a regular basis. In other words, bugs exist in the base Tianocore code, not just in the stuff that vendors add. That said, it's the vendor-specific bugs that are the worst, because they vary from one computer to another.
You should know that using the \EFI\boot\bootx64.efi method of booting is not a terrible option either.
If you're not booting Windows, using EFI/BOOT/bootx64.efi is, in some ways, better than the "official" way (with an OS-specific boot loader file and NVRAM entry), because this method won't be disturbed should the NVRAM be accidentally erased. If you're dual-booting or if you want to install several boot loaders and switch between them at will, though, using EFI/BOOT/bootx64.efi will just complicate matters and may be impractical.
Offline
If you're not booting Windows, using EFI/BOOT/bootx64.efi is, in some ways, better than the "official" way (with an OS-specific boot loader file and NVRAM entry), because this method won't be disturbed should the NVRAM be accidentally erased. If you're dual-booting or if you want to install several boot loaders and switch between them at will, though, using EFI/BOOT/bootx64.efi will just complicate matters and may be impractical.
This is a good point. I don't multi-boot and I don't actually have any particular urge to watch bootloaders advertising themselves or the systems they are about to boot. I just sleep less well when something doesn't work exactly like I meant it to.
Offline
I had the same problem, after a lot of trial and error I installed a BIOS update which (somehow) fixed it.
Offline
Please do not "necrobump" old threads.
Closed.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Pages: 1
Topic closed