bloom wrote:Is it me or is EFISTUB missing from 3.6.11?
No, it is not missing.
You must be right.
I've downgraded to 3.6.10 and noticed no improvements: I'm still stuck at the “rEFInd - Booting OS” stage, no error messages whatsoever.
]]>Does anyone know how i can hide the "status messages" (i think it is called that) at boot..
http://www.youtube.com/watch?v=Mi_XZocjoIA
If you take a look at the video above you can see that when his PC boots, it shows only 1 line of text before showing the desktop so it boots a bit faster then on my PC. I sent his a message on youtube and asked but he has not replied so i thought i should ask here instead. I did add quiet to efibootmgr but that does not hide everything.
This really should go in a new thread but it isn't worth it now: https://bbs.archlinux.org/viewtopic.php?pid=1179833
]]>Is it me or is EFISTUB missing from 3.6.11?
No, it is not missing.
----
Does anyone know how i can hide the "status messages" (i think it is called that) at boot..
http://www.youtube.com/watch?v=Mi_XZocjoIA
If you take a look at the video above you can see that when his PC boots, it shows only 1 line of text before showing the desktop so it boots a bit faster then on my PC. I sent his a message on youtube and asked but he has not replied so i thought i should ask here instead. I did add quiet to efibootmgr but that does not hide everything.
]]>efibootmgr --create --gpt --label "Fedora Kernel Boot" --loader \\EFI\\fedora\\vmlinuz.efi -u "root=/dev/mapper/fedora-root ro initrd=\\EFI\\fedora\\initramfs.img"
How would i do this on a USB stick with a live linux distro on it so i can boot without the need of grub?
]]>so after a lot of time wasted trying to get this work on another machine of mine, I came to the conclusion that you don't actually need this patch...
On my Intel board I just had to create "/boot/efi/boot/bootx64.efi" and I could automatically boot from the SATA drive. On my ASUS board however, this works only for external devices (I guess bootx64.efi is actually only meant for external devices but my Intel board does it for internal devices anyway!?). So it turned out I had to write the boot entry manually into the UEFI firmware with efibootmgr (available in [extra]). Going through the man page I noticed this option:-@ | --append-binary-args append extra variable args from file (use - to read from stdin). Data in file is appended as command line arguments to the boot loader command, with no modification to the data, so you can pass any binary or text data necessary.
so wait a minute? I can write the kernel parameters directly into the UEFI firmware? Wish I would have known this sooner... -.- Well, this stuff happens when you try to boot your kernel with UEFI without having a good understanding of how UEFI works.
At this point I finally realized how you are actually supposed to set this up (at least I hope so):ls -l /boot/efi/arch/ total 15429 -rwxr-xr-x 1 root root 8383484 Apr 20 01:14 initramfs-linux-fallback.img -rwxr-xr-x 1 root root 4091692 Apr 20 01:14 initramfs-linux.img -rwxr-xr-x 1 root root 3322896 Apr 20 01:28 vmlinuz-linux.efi
So I first tried:
echo "initrd=\efi\arch\initramfs-linux.img root=/dev/mapper/crypt cryptdevice=/dev/sda3:crypt ro quiet" | efibootmgr --create --gpt --disk /dev/sda --part 1 --label "Arch Linux" --loader '\efi\arch\vmlinuz-linux.efi' --append-binary-args -
Didn't work, the kernel crashed, probably because it didn't get the initrd parameter. Then I remember that there was something about character conversion in the archiso commit.
So I tried:echo "initrd=\efi\arch\initramfs-linux.img root=/dev/mapper/crypt cryptdevice=/dev/sda3:crypt ro quiet" | iconv -f ascii -t ucs2 | efibootmgr --create --gpt --disk /dev/sda --part 1 --label "Arch Linux" --loader '\efi\arch\vmlinuz-linux.efi' --append-binary-args -
Works!
You can now also easily create another entry for the fallback image:echo "initrd=\efi\arch\initramfs-linux-fallback.img root=/dev/mapper/crypt cryptdevice=/dev/sda3:crypt ro quiet" | iconv -f ascii -t ucs2 | efibootmgr --create --gpt --disk /dev/sda --part 1 --label "Arch Linux (Fallback)" --loader '\efi\arch\vmlinuz-linux.efi' --append-binary-args -
The stupid thing about this is that you have to boot via UEFI to be able to modify the UEFI bootloader with efibootmgr. I simply booted with an UEFI based USB stick to do this.
After reviewing man efibootmgr (I suggest you all skim it, it's short), I've updated your solution:
efibootmgr --create --gpt --label "Arch Linux" --loader \\EFI\\Arch\\vmlinuz-linux.efi -u "root=/dev/sda2 ro initrd=\\EFI\\arch\\initramfs-linux.img"
And of course you can include whatever other kernel parameters you use. Also note that if your EFI System Parition isn't on /dev/sda1, then you'll still have to use --disk and --part args to specify that, but at least now you don't have to do the binary piping for flags.
Someone should probably update the Archwiki entry.
Edit: Also here's an example of how you can modify the boot parameters:
# efibootmgr
BootCurrent: 0000
BootOrder: 0000
Boot0000* Arch Linux
# efibootmgr -b 0000 -u <params>
1) The ArchWiki states that from Kernel 3.5 the is going to be a linux.conf file that will have all the kernel parameters in it. Anyone booting with an efibootmgr entry has passed parameters using the command on the wiki (echo "root.... etc,etc). In case someone doesn't change the entry which parameters are going to be respected by the kernel. The ones in the file or the ones passed with the command???
2)The second is more of a problem. Efiboomgr doesn't seem to respect the bootnext command. I try to boot it in UEFI from a Archboot.iso usb -both with bootnext and by the bios setting menu (boot usb etc)- but it ends up using the normal boot in the harddrive. I can fix problems by changing the bios menu and booting in legacy but in case something goes wrong with EFI i wont be able to use new parameters since you cant do anything EFI related unless you boot with it. Any ideas on where the problem might lie would be greatly appreciated.
]]>The initrd= command need a absolute path of the initramfs file. So you need to use "initrd=\\initramfs-linux.img" in efibootmgr command and not just "initrd=initramfs-linux.img" . That might be the cause of the error.
Doesn't help. Neither adding it to efibootmgr or when directly booting through the UEFI shell
I don't think its a kernel issue. Seems to be an issue with efibootmgr or the way efibootmgr stores arguments in Thinkpad UEFI firmwares. SO maybe a efibootmgr-Thinkpad issue.
An how do you explain the fact that it fails when booting through the UEFI shell? I am strongly convinced that efibootmgr works fine, since boot fails even when I am not using it!
EDIT: apparently it is a kernel bug, and a commit linked in the bug report I listed before fixes it Now I can enjoy my prerelease kernel build
]]>In fact, the output of efibootmgr -v using my -u version or using the echo " ... " | ... | efibootmgr ... --append-binary-args - is the same, and reads as:
Boot0019* UEFI Shell HD(4,6f00800,cc70f,fd46a5e6-a6a6-4522-9a8c-2f0fecd0891f)File(\shellx64.efi) Boot001A* Arch Linux HD(4,6f00800,cc70f,fd46a5e6-a6a6-4522-9a8c-2f0fecd0891f)File(\vmlinuz.efi)i.n.i.t.r.d.=.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g. .i.n.i.t.=./.b.i.n./.s.y.s.t.e.m.d. .r.o.o.t.=./.d.e.v./.d.i.s.k./.b.y.-.u.u.i.d./.4.f.f.e.7.3.d.4.-.9.e.5.6.-.4.7.1.f.-.8.7.f.c.-.a.1.0.6.e.e.1.f.5.3.f.2. .r.e.s.u.m.e.=./.d.e.v./.d.i.s.k./.b.y.-.u.u.i.d./.0.4.a.7.2.e.9.b.-.6.f.8.1.-.4.6.b.5.-.8.e.d.c.-.3.1.6.3.b.3.e.0.4.3.2.1. .r.o. .q.u.i.e.t. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.r.c.6.=.7. .i.9.1.5...s.e.m.a.p.h.o.r.e.s.=.1. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.f.b.c.=.1. .i.9.1.5...l.v.d.s._.d.o.w.n.c.l.o.c.k.=.1. .p.r.o.c.e.s.s.o.r...i.g.n.o.r.e._.p.p.c.=.1. .p.c.i.e._.a.s.p.m.=.f.o.r.c.e...
The initrd= command need a absolute path of the initramfs file. So you need to use "initrd=\\initramfs-linux.img" in efibootmgr command and not just "initrd=initramfs-linux.img" . That might be the cause of the error. See https://git.kernel.org/?p=linux/kernel/ … xt;hb=HEAD for more info.
The only solution is notifying kernel developers and wait for their words
I don't think its a kernel issue. Seems to be an issue with efibootmgr or the way efibootmgr stores arguments in Thinkpad UEFI firmwares. SO maybe a efibootmgr-Thinkpad issue.
Rather than contacting kernel developers try contacting efibootmgr upstream maintainer (current) Jordan Hargrave (his email at http://linux.dell.com/cgi-bin/gitweb/gi … 0271cd8bf3 ), or former upstream maintainer Matt Domsch (email: http://linux.dell.com/cgi-bin/gitweb/gi … 10e0a749ac )
]]>@alexcriss and RobertBuhren: Post the outputs of "efibootmgr --verbose" command. Can you guys also try booting via UEFI Shell or rEFInd. In that way we can know whether the problem is due to efistub itself or due to efibootmgr.
Booting through the UEFI shell gives
Load: Error
@alexcriss: You don't have any initramfs defined. Also I don't think you can skip "--append-binary-args -" with "-u" . Try "-u --append-binary-args -".
I have an initrd command, and the initramfs-linux.img file is there, plus it always worked up to 3.5-rc1
The --append-binary thing is not really necessary, look here https://groups.google.com/forum/#!msg/l … sIyinxDKEJ
In fact, the output of efibootmgr -v using my -u version or using the echo " ... " | ... | efibootmgr ... --append-binary-args - is the same, and reads as:
Boot0019* UEFI Shell HD(4,6f00800,cc70f,fd46a5e6-a6a6-4522-9a8c-2f0fecd0891f)File(\shellx64.efi)
Boot001A* Arch Linux HD(4,6f00800,cc70f,fd46a5e6-a6a6-4522-9a8c-2f0fecd0891f)File(\vmlinuz.efi)i.n.i.t.r.d.=.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g. .i.n.i.t.=./.b.i.n./.s.y.s.t.e.m.d. .r.o.o.t.=./.d.e.v./.d.i.s.k./.b.y.-.u.u.i.d./.4.f.f.e.7.3.d.4.-.9.e.5.6.-.4.7.1.f.-.8.7.f.c.-.a.1.0.6.e.e.1.f.5.3.f.2. .r.e.s.u.m.e.=./.d.e.v./.d.i.s.k./.b.y.-.u.u.i.d./.0.4.a.7.2.e.9.b.-.6.f.8.1.-.4.6.b.5.-.8.e.d.c.-.3.1.6.3.b.3.e.0.4.3.2.1. .r.o. .q.u.i.e.t. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.r.c.6.=.7. .i.9.1.5...s.e.m.a.p.h.o.r.e.s.=.1. .i.9.1.5...i.9.1.5._.e.n.a.b.l.e._.f.b.c.=.1. .i.9.1.5...l.v.d.s._.d.o.w.n.c.l.o.c.k.=.1. .p.r.o.c.e.s.s.o.r...i.g.n.o.r.e._.p.p.c.=.1. .p.c.i.e._.a.s.p.m.=.f.o.r.c.e...
But i suggest using rEFInd as efibootmgr's ars support seems to be unstable ATM.
I'd rather keep 3.4 than installing yet another another thing that I do not need. It worked beautifully up to today, it has to work in the future. The only solution is notifying kernel developers and wait for their words
]]>@alexcriss: You don't have any initramfs defined. Also I don't think you can skip "--append-binary-args -" with "-u" . Try "-u --append-binary-args -". But i suggest using rEFInd as efibootmgr's ars support seems to be unstable ATM.
]]>alessandro at alessandro-thinky in ~
$ tree /boot/efi/
/boot/efi/
|-- initramfs-linux.img
|-- linux.conf
|-- shellx64.efi
`-- vmlinuz.efi
The efibootmgr command I used is
efibootmgr --create --gpt --disk /dev/sdb --part 4 --write-signature --label "Arch Linux" --loader '\vmlinuz.efi' -u initrd=initramfs-linux.img init=/bin/systemd root=/dev/disk/by-uuid/4ffe73d4-9e56-471f-87fc-a106ee1f53f2 resume=/dev/disk/by-uuid/04a72e9b-6f81-46b5-8edc-3163b3e04321 ro quiet i915.i915_enable_rc6=7 i915.semaphores=1 i915.i915_enable_fbc=1 i915.lvds_downclock=1 processor.ignore_ppc=1 pcie_aspm=force
where the -u does the same thing as the echo "args" | iconv -f ascii -t ucs2 | efibootmgr ... --append-binary-args -
]]>/boot/efi/
`-- efi
|-- arch
| |-- initramfs-linux.img
| |-- refind
| | |-- icons
| | | |-- arrow_left.icns
| | | |-- arrow_right.icns
| | | |-- boot_linux.icns
| | | |-- boot_win.icns
| | | |-- func_about.icns
| | | |-- func_exit.icns
| | | |-- func_reset.icns
| | | |-- func_shutdown.icns
| | | |-- os_arch.icns
| | | |-- os_centos.icns
| | | |-- os_debian.icns
| | | |-- os_ecomstation.icns
| | | |-- os_fedora.icns
| | | |-- os_freebsd.icns
| | | |-- os_freedos.icns
| | | |-- os_gentoo.icns
| | | |-- os_hwtest.icns
| | | |-- os_legacy.icns
| | | |-- os_linux.icns
| | | |-- os_linuxmint.icns
| | | |-- os_mac.icns
| | | |-- os_mandriva.icns
| | | |-- os_netbsd.icns
| | | |-- os_openbsd.icns
| | | |-- os_redhat.icns
| | | |-- os_refit.icns
| | | |-- os_slackware.icns
| | | |-- os_suse.icns
| | | |-- os_ubuntu.icns
| | | |-- os_unknown.icns
| | | |-- os_win.icns
| | | |-- tool_part.icns
| | | |-- tool_shell.icns
| | | |-- vol_external.icns
| | | |-- vol_internal.icns
| | | `-- vol_optical.icns
| | |-- refind.conf
| | |-- refind_linux.conf
| | `-- refindx64.efi
| |-- refind_linux.conf
| |-- vmlinuz-linux.efi
| |-- vmlinuz-linux-fastboot.efi
| |-- vmlinuz-linux-noinitrd.efi
| `-- vmlinuz-linux-rc.efi
`-- arch_grub
`-- grubx64.efi
vmlinuz-linux-ec.rfi is the 3.5-rc1 kernel
and i added this kernel to my bootlist using efibootmgr:
echo "root=/dev/sda4 ro init=/bin/systemd quiet systemd.show_status=0 rootfstype=ext4 libahci.ignore_sss=1 add_efi_memmap raid=noautodetect selinux=0 " | iconv -f ascii -t ucs2 | efibootmgr --create --gpt --disk /dev/sda --part 2 --label "Archlinux (EFISTUB) - 3.5-rc1" --loader "\\EFI\\arch\\vmlinuz-linux-rc.efi" --append-binary-args -
Regards,
Robert
]]>