FS#34641 - [linux] 3.8.x - 3.9.x Efibootmgr do nothing

Attached to Project: Arch Linux
Opened by UnicornDarkness (Xorg) - Saturday, 06 April 2013, 13:34 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Sunday, 23 June 2013, 12:10 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 11
Private No

Details

Description:
Since kernel 3.8.X, I can't create entries in my UEFI with 'efibootmgr' command.
It was working fine with kernel 3.7.X.

But recreate a same entry print this error :
** Warning ** : Boot0000 has same label ArchLinux
And do nothing changes.


Additional info:
* package version(s) :
extra/efibootmgr 0.6.0-1
core/linux 3.8.5-1 (base)

* config and/or log files etc.
x86_64 BIOS EFI AMI (motherboard : Asus P8P67)


Steps to reproduce:
In a root terminal, I do this :
# echo "root=UUID=792e28b7-7115-4879-9f80-29c517b4ca9f ro quiet nomodeset vga=0 fglrxfb fbcon=scrollback:512k resume=/dev/md1 rootfstype=ext4 add_efi_memmap initrd=\EFI\arch\initramfs-arch.img" | iconv -f ascii -t ucs2 | efibootmgr --verbose -c -g -d /dev/sda -p 2 -L "ArchLinux" -l '\EFI\arch\vmlinuz-arch.efi' --append-binary-args -
Or :
# echo "initrd=\EFI\arch\initramfs-arch.img root=/dev/md0 ro quiet" | iconv -f ascii -t ucs2 | efibootmgr --verbose -c -g -d /dev/sda -p 2 -L "ArchLinux" -l '\EFI\arch\vmlinuz-arch.efi' --append-binary-args -
And there are no output.
Then, when I use this command, to verify :
# efibootmgr -v
There is not the entry who was created.

Efibootmgr is crucial for EFI Boot Stub. Without, it is not possible to boot without using a bootloader.
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Sunday, 23 June 2013, 12:10 GMT
Reason for closing:  None
Additional comments about closing:  https://bugs.archlinux.org/task/34641#co mment111365
Comment by Ankur (ankzkothari) - Sunday, 07 April 2013, 04:58 GMT
Same problem for me. Trying to add an EFI stub entry (which I have run successfully on older kernels), efibootmgr exits 1, and the entry is not created. I was able to delete the boot order but any other modifications, including setting a new boot order don't work.
Motherboard is Asus P8H77-M Pro.
Possibly related to <https://bbs.archlinux.org/viewtopic.php?id=160583>?
Comment by UnicornDarkness (Xorg) - Sunday, 07 April 2013, 07:53 GMT
I went to the ARM website (http://arm.konnichi.com), I've found package efibootmgr-0.5.4-3-x86_64 (here : http://arm.konnichi.com/2012/06/01/extra/os/x86_64/), and I've downgrade efibootmgr-0.6.0-1 to efibootmgr-0.5.4-3.
I'm still on kernel 3.8.X, it's the same result.
So I think problem is not efibootmgr's version but the kernel 3.8.X.
Comment by Erich Luckerbauer (moleculecolony) - Monday, 08 April 2013, 23:37 GMT
Had the same problem. After downgrading the Kernel to 3.7.10 efibootmgr-0.6.0-1 works without problem.

Xorg, you can install gummiboot once (by temporarily downgrading the kernel), and then use it to boot any new efistub you get without ever needing efibootmgr anymore.
Comment by UnicornDarkness (Xorg) - Monday, 15 April 2013, 14:35 GMT
Thanks Moleculecolony. I have already an efistub entry, so for me, I haven't problem to boot; problem is for people who don't have or who want modify.


Kernel upgrade, new version is Linux 3.8.7-1, and problem still exists.
Comment by felix (fstirlitz) - Friday, 26 April 2013, 16:32 GMT
Got the same problem on 3.8.8-2. Running strace efibootmgr -c reveals that writing to /sys/firmware/efi/vars/new_var fails with ENOSPC. I can create boot entries with EFI setup utility just fine, however.
Comment by RK (keoz) - Sunday, 28 April 2013, 16:22 GMT
Same problem here.
Comment by Yangtse Su (yangtsesu) - Thursday, 02 May 2013, 06:39 GMT
Same problem with kernel 3.9.x
Comment by UnicornDarkness (Xorg) - Saturday, 04 May 2013, 09:06 GMT
Maybe solution is here : https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=42c01745c223eaca46f2bfe628ba70a686cf2cb2 ?
Comment by Xentec (Xentec) - Wednesday, 08 May 2013, 21:50 GMT
Had the same problem, but it seems to work now.

Linux 3.9.0-2-ARCH
UEFI 2.00 (American Megatrends 4.640)

Gummiboot also updates flawlessly.
Comment by XazZ (XazZ) - Thursday, 09 May 2013, 16:02 GMT
Didn't work for me with 3.8.x but it just worked with 3.9.1-1-ARCH (x86_64).
Comment by Leonud Selivanov (bravebug) - Thursday, 09 May 2013, 20:59 GMT
Works now on Linux 3.9.1-1-ARCH x86_64
Comment by Jerome (sinatosk) - Sunday, 12 May 2013, 23:52 GMT
I'm using linux 3.9.2-1 x86_64 and it's not working for me... silently fails using efibootmgr 0.6.0-1

efibootmgr 0.6.0-1 gives me the ENOSPC (No space left on device)
efibootmgr 0.5.4-3 gives me the EIO (Input/Output error)

Mobo: Asus Sabertooth 990FX R2.0
BIOS: 1503

update1 at 01:24 GMT : Booted into linux-lts 3.0.77-1 x86_64 using efibootmgr 0.6.0-1 and it works fine.
Comment by Ankur (ankzkothari) - Friday, 17 May 2013, 11:18 GMT
Not working for me with linux 3.9.2-1 and efibootmgr 0.6.0-1.
Comment by UnicornDarkness (Xorg) - Saturday, 18 May 2013, 14:29 GMT
I use Linux 3.9.2-1 and Efibootmgr 0.6.0-1.
When I boot using EFI Stub, Efibootmgr silently fails, but when I boot using GRUB 2, it's work. Boots parameters are sames...
Comment by Jerome (sinatosk) - Saturday, 18 May 2013, 19:53 GMT
Xorg ( the user above me )

I just tried this myself and same thing happens with me... EFISTUB not working, GRUB2 works
Comment by felix (fstirlitz) - Friday, 24 May 2013, 19:20 GMT
Seems to work for me again as of efibootmgr 0.6.0-2 and kernel 3.9.3-1. (Never booted using anything else than GRUB2.)
Comment by Tobit R (0xtobit) - Tuesday, 28 May 2013, 20:34 GMT
It's still broken for me with kernel 3.9.4-1 and efibootmgr 0.6.0-2. It seems even more broken with the latest kernel update. I can't even see any entries, this is the output I see with the -v option:
# efibootmgr -v
Timeout: 2 seconds
Comment by Keshav Amburay (the.ridikulus.rat) - Saturday, 15 June 2013, 14:19 GMT
You can try booting the kernel with "efi_no_storage_paranoia" parameter to make efibootmgr work again. It worked for me.
Comment by Tobit R (0xtobit) - Monday, 17 June 2013, 21:09 GMT
That appears to have worked for me. Thanks!
Comment by UnicornDarkness (Xorg) - Monday, 17 June 2013, 21:20 GMT
Maybe it's a solution, but if you have an UEFI like me where you can't change kernel parameter, it's an other problem.
But I have Grub2 to troubleshoot myself, so it's a good alternative to boot with "efi_no_storage_paranoia" parameter, I know. Thanks !
Comment by Ankur (ankzkothari) - Tuesday, 18 June 2013, 09:22 GMT
efi_no_storage_paranoia worked for me.
Comment by Keshav Amburay (the.ridikulus.rat) - Tuesday, 18 June 2013, 12:19 GMT
This issue is due to some efi variable storage checks in kernel >=3.8 (to prevent Samsung UEFI like issues) and due to the inclusion of support for storing pstore dumps in efi variable storage. Without "efi_no_storage_paranoia" the kernel will refuse to write/modify any efivar if the firmware reports that more than half of its total efivar storage space is already used up. The parameter "efi_no_storage_paranoia" disables this check.

Check for existence of /sys/firmware/efi/efivars/dump-* files. If they exist delete them (ie. pstore dumps stored in efivars) and reboot. You should be able to use efibootmgr properly without "efi_no_storage_paranoia". For a similar discussion in Fedora's bugzilla see https://bugzilla.redhat.com/show_bug.cgi?id=947142 . https://bugzilla.redhat.com/show_bug.cgi?id=919485 may also be helpful.

Loading...