Closed user-27-here closed 8 years ago
I'm so sorry for SCREAMING. When I pasted those lines they were preceded by a "#" Won't do it again.
A hint for future github comments.
https://help.github.com/articles/github-flavored-markdown/#fenced-code-blocks
thanks floppym - very helpful
@user-27-here being the author of the issue you can always go in and edit your entry and get it all fixed
Hi, Can you please try with the patches I have just pushed? They solve this issue for me.
Attempted first test. Errors in OP did not manifest when running efibootmgr
(good), but Linux notebook failed to boot (bad). I ran out of time to test further, but will try again later.
Found a bit of time for testing.
Here's the command I use to set boot option 0000 to boot my linux kernel directly.
echo 'rw nomodeset gpt add_efi_map rootdelay=10 libata.force=nohrst i915.modeset=1 i915.semaphores=1 ssldec=/dev/disk/by-label/keys:ext2:zen.ssl cryptdevice=/dev/disk/by-uuid/29202844-88a2-400d-826d-e0347ec29466:root.dec root=/dev/mapper/root.dec initrd=\EFI\arch\initramfs-4.4.5-1-zen.img' | iconv -f ascii -t ucs2 | efibootmgr -b 0000 -g -L 'Zen' -l '\EFI\arch\linux-4.4.5-1-zen.efi' -q -u -@ -
In the distant past before this patch was necessary, the initial version of this worked flawlessly. I could update the kernel and initramfs version, run the command, and reboot my laptop immediately into linux without grub or refind, etc.
I'm not certain whether all the options I'm using are still necessary, so let me know if I'm doing it wrong.
At the moment, if boot option 0000 exists, my command does not replace/modify it. Whatever existed previously remains, and my command is a no-op. This wasn't the behavior in that distant past I mentioned; if modification should work, I can open a new issue. Currently, I just use -B
to clear the existing boot option before running the above command.
With the following, I do get what appears to be an error message that has no effect.
su
efibootmgr -B -b 0
echo 'rw nomodeset gpt add_efi_map rootdelay=10 libata.force=nohrst i915.modeset=1 i915.semaphores=1 ssldec=/dev/disk/by-label/keys:ext2:zen.ssl cryptdevice=/dev/disk/by-uuid/29202844-88a2-400d-826d-e0347ec29466:root.dec root=/dev/mapper/root.dec initrd=\EFI\arch\initramfs-4.4.5-1-zen.img' | iconv -f ascii -t ucs2 | efibootmgr -v -g -c -b 0 -L 'Zen' -l '\EFI\arch\linux-4.4.5-1-zen.efi' -u -@ -
efibootmgr: Could not parse device path: Success
And my system booted fine! I think this patch does work.
I noticed my command uses the -c
create boot option flag and took that out thinking I could then modify an existing boot option, but efibootmgr -v
doesn't show any change to the existing boot option, so I'll continue to delete first.
This seems to work for me in the current tree: trillian:~/devel/github.com/efivar$ echo 'rw nomodeset gpt add_efimap rootdelay=10 libata.force=nohrst i915.modeset=1 i915.semaphores=1 ssldec=/dev/disk/by-label/keys:ext2:zen.ssl cryptdevice=/dev/disk/by-uuid/29202844-88a2-400d-826d-e0347ec29466:root.dec root=/dev/mapper/root.dec initrd=\EFI\arch\initramfs-4.4.5-1-zen.img' | iconv -f ascii -t ucs2 | sudo efibootmgr -v -g -c -b 1 -L 'Zen' -l '\EFI\arch\linux-4.4.5-1-zen.efi' -u -@ - BootCurrent: 0001 Timeout: 0 seconds BootOrder: 0001,0000 Boot0000* Fedora HD(1,GPT,2cf5261b-7b98-48c0-ae54-463dbd23e65b,0x800,0x64000)/File(\EFI\fedora\shim.efi) Boot0001* Zen HD(1,GPT,2cf5261b-7b98-48c0-ae54-463dbd23e65b,0x800,0x64000)/File(\EFI\arch\linux-4.4.5-1-zen.efi)r.w. .n.o.m.o.d.e.s.e.t. .g.p.t. .a.d.d..e.f.i._.m.a.p. .r.o.o.t.d.e.l.a.y.=.1.0. .l.i.b.a.t.a...f.o.r.c.e.=.n.o.h.r.s.t. . .i.9.1.5...m.o.d.e.s.e.t.=.1. .i.9.1.5...s.e.m.a.p.h.o.r.e.s.=.1. .s.s.l.d.e.c.=./.d.e.v./.d.i.s.k./.b.y.-.l.a.b.e.l./.k.e.y.s.:.e.x.t.2.:.z.e.n...s.s.l. .c.r.y.p.t.d.e.v.i.c.e.=./.d.e.v./.d.i.s.k./.b.y.-.u.u.i.d./.2.9.2.0.2.8.4.4.-.8.8.a.2.-.4.0.0.d.-.8.2.6.d.-.e.0.3.4.7.e.c.2.9.4.6.6.:.r.o.o.t...d.e.c. .r.o.o.t.=./.d.e.v./.m.a.p.p.e.r./.r.o.o.t...d.e.c. .i.n.i.t.r.d.=..E.F.I..a.r.c.h..i.n.i.t.r.a.m.f.s.-.4...4...5.-.1.-.z.e.n...i.m.g... trillian:~/devel/github.com/efivar$
Is it still an issue for you?
I updated my efivar and efibootmgr to the latest in master. The efibootmgr: Could not parse device path: Success
error message no longer appears.
Many thanks.
I use a bash script to add items to the efi menu using the following code:
It always worked great before the update from efibootmgr-0.11.0, but now I get the following errors:
efibootmgr: get_extra_args: No such file or directory efibootmgr: Could not set variable: No such file or directory efibootmgr: Could not prepare boot variable: No such file or directory
Further testing shows that the problem seems to be related to reading from stdin. If I break the above command into two commands using a tempfile, it works as before:
I tried replacing "-@ -" with "-@ /dev/stdin" and it adds the entry to the efi menu without error, but the extra args from stdin don't get appended.