rhboot / efibootmgr

efibootmgr development tree
GNU General Public License v2.0
519 stars 99 forks source link

efibootmgr-0.12: -@ (--append-binary-args) seems to be broken #39

Closed user-27-here closed 8 years ago

user-27-here commented 9 years ago

I use a bash script to add items to the efi menu using the following code:

echo "foo" | iconv -f ascii -t ucs2 | efibootmgr -q -c -d /dev/sda -p 1 -L linux-4.2-rc6 -l "\efi\boot\\linux-4.2-rc6.efi" -@ -

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:

echo "foo" | iconv -f ascii -t ucs2 > tempfile
efibootmgr -q -c -d /dev/sda -p 1 -L linux-4.2-rc6 -l "\efi\boot\\linux-4.2-rc6.efi" -@ tempfile

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.

user-27-here commented 9 years ago

I'm so sorry for SCREAMING. When I pasted those lines they were preceded by a "#" Won't do it again.

floppym commented 9 years ago

A hint for future github comments.

https://help.github.com/articles/github-flavored-markdown/#fenced-code-blocks

user-27-here commented 9 years ago

thanks floppym - very helpful

idella commented 9 years ago

@user-27-here being the author of the issue you can always go in and edit your entry and get it all fixed

vathpela commented 8 years ago

Hi, Can you please try with the patches I have just pushed? They solve this issue for me.

boxofrox commented 8 years ago

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.

boxofrox commented 8 years ago

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.

vathpela commented 8 years ago

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?

boxofrox commented 8 years ago

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.