You are not logged in.
The config headers says it's a 3.3.4-2 versions config. Did you use "make oldconfig" to make new config for the 3.5-rc1 kernel? Or did you just copy your old config and compiled the kernel with that?
Offline
The latter, and compiled the new one after answering n to all the new config keys I could scrape the resulting file from somewhere, but it's basically the same as that one.
I can go further, this same config file works for 3.4 and doesn't for 3.5-rc1.
Offline
Ok, it really shouldn't make any difference at all, i haven't seen any new EFI related options in the 3.5-rc1 config.
Is there any way of debugging efi boot further? I mean i can't see anything on the console, my thinkpad just falls back to the selection of boot media.
Offline
I have no idea, it just fails on me as well. I believe that the only way forward is a bug report
EDIT: bug reported here, please add info
https://bugzilla.kernel.org/show_bug.cgi?id=43345
Last edited by alexcriss (2012-06-06 15:48:06)
Offline
I'm having a Thinkpad x220 with bios ver 1.29.
@the.ridikulus.rat What hardware do you have?
I tried booting with a UEFI entry via "efibootmgr" and via rEFInd. Both works with 3.4 but not with 3.5-rc1
I use Tianocore DUET. Anyway can you post the command you used to launch the kernel as well the file-structure of your UEFISYS partition.
Offline
Sure,
/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
Offline
Here you are:
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 -
Offline
@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.
@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.
Offline
@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
Offline
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 )
Offline
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
Last edited by alexcriss (2012-06-07 10:58:37)
Offline
refind-x86_64 (stable) package has been renamed as refind-efi-x86_64 and moved to [extra] repo http://www.archlinux.org/packages/extra … fi-x86_64/ . The refind-x86_64-git package in AUR has been renamed as refind-efi-x86_64-git https://aur.archlinux.org/packages.php?ID=59810 .
Last edited by the.ridikulus.rat (2012-06-07 17:04:43)
Offline
Hello. Since this is the thread that all the efibootmgr and EFISTUB discusion takes place, and i don't want to start another thread, i have a couple of questions:
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.
Offline
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>
Last edited by Whef (2012-08-27 10:27:38)
Offline
I managed to do this on Fedora 18 installed on VMware by using:
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?
Last edited by DislikeYou (2013-01-03 01:46:35)
Offline
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.
Offline
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
Offline
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.
Last edited by bloom (2013-01-14 15:53:43)
Offline
The new kernel 3.7.3-1 boots faster for me.. i have quiet added to bootefimgr and now it does not show any status messages [OK] it just shows some text fast and then boots into xfce.
Offline