You are not logged in.
Perhaps a separate wiki page for efistub booting with/without refind? (as an alternative for grub2-efi-x86_64)
Offline
Perhaps a separate wiki page for efistub booting with/without refind? (as an alternative for grub2-efi-x86_64)
Ah yes, coincidentally i was just typing a wiki example for dual-booting OSX/linux with EFI_STUB on Macs.
ᶘ ᵒᴥᵒᶅ
Offline
I have uploaded refind-x86_64-git https://aur.archlinux.org/packages.php?ID=57966 (repo at http://sourceforge.net/p/refind/code/)
Offline
To those of you who have tried it now: is it noticeably faster than before?
Offline
To those of you who have tried it now: is it noticeably faster than before?
Well, the boot process itself takes the same amount of time as before, but getting to the boot process is a lot faster, almost instantly. For me personally though, the idea of getting rid of those stupid bootloaders (grub and friends) is the most important part.
ᶘ ᵒᴥᵒᶅ
Offline
Sounds cool, I'm now one step closer to having Arch on my MacBook
Offline
Sounds cool, I'm now one step closer to having Arch on my MacBook
Here's a video of an EFI_STUB boot: http://youtu.be/Mi_XZocjoIA
ᶘ ᵒᴥᵒᶅ
Offline
interesting. too bad the "boot manager" is still needed. I mean, my UEFI-enabled laptop has a fancy menu where you can select what to boot. if i could just add all arguments in there, that would be neat.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
interesting. too bad the "boot manager" is still needed. I mean, my UEFI-enabled laptop has a fancy menu where you can select what to boot. if i could just add all arguments in there, that would be neat.
You could give this a try.
Offline
interesting. too bad the "boot manager" is still needed. I mean, my UEFI-enabled laptop has a fancy menu where you can select what to boot. if i could just add all arguments in there, that would be neat.
Or you can do using startup.nsh with efi-shell, like I have done temporary for archiso[#1],
[#1] http://mailman.archlinux.org/pipermail/ … 02451.html
Last edited by djgera (2012-04-03 22:36:41)
Offline
Experimental linux based "bless" utility by Fedora devs at https://aur.archlinux.org/packages.php?ID=54847 . Please test it (I haven't because I don't own a Mac).
Offline
Experimental linux based "bless" utility by Fedora devs at https://aur.archlinux.org/packages.php?ID=54847 . Please test it (I haven't because I don't own a Mac).
Cool, 'experimental' sounds a bit scary though...
ᶘ ᵒᴥᵒᶅ
Offline
Archiso getting UEFI boot support (but no GPT+UEFI support in AIF yet) via Shell+EFISTUB (x86_64 only, but nothing stopping you from creating a 32-bit EFI bootable USB in similar way).
Instructions for creating UEFI bootable iso - https://bbs.archlinux.org/viewtopic.php … 9#p1083439
Relevant Archiso git commit - http://projects.archlinux.org/archiso.g … 4350a11056
Last edited by the.ridikulus.rat (2012-04-17 07:25:04)
Offline
Offline
I just tried this on my system with an Intel DH67GD following this and the aforementioned mailing list entry.
I was surprised that I actually got this to work, just wanted to share my experience:
I got the UEFI shell to boot from a USB stick with the instructions from the wiki. Unfortunately UEFI Shell 2.0 didn't work for me, I get a strange ASSERT_EFI_ERROR on boot. UEFI Shell 1.0 booted just fine however.
Then I copied /boot/initramfs-linux.img and /boot/vmlinuz-linux (as bzImage.efi) to the USB stick. Then I could boot from the Shell with:
bzImage.efi initrd=\initramfs-linux.img root=/dev/mapper/crypt cryptdevice=/dev/sda3:crypt ro quiet
Then I put this in the file "startup.nsh" so it automatically boots after a 5 second timer.
... the proposed linux.conf efistub config file https://lkml.org/lkml/2012/3/18/45
Do I understand this correctly that I could then boot the kernel directly without having to load a UEFI Shell first? If so, how would the boot menu of the mainboard know that it is supposed to load the kernel? Simply replace the bootx64.efi in efi/boot/ with bzImage.efi ?
edit: nevermind: the archiso commit pretty much clears this up for me
Last edited by 65kid (2012-04-18 18:35:29)
Offline
Forgive my disbelief, but are you guys really saying that, as of kernel 3.3, it's possible to install Arch Linux on the GPT-formatted SSD of my UEFI-equipped computer and boot directly into Arch without using Grub2 or any other bootloader?
Does this mean that I no longer need a dedicated 200Mb FAT32 partition for EFI?
Assuming I use Archboot to install, I would skip the install-bootloader step entirely, right?
Then, what do I have to do to direct UEFI to boot my Arch installation?
Last edited by dhave (2012-04-18 22:14:45)
Offline
Forgive my disbelief, but are you guys really saying that, as of kernel 3.3, it's possible to install Arch Linux on the GPT-formatted SSD of my UEFI-equipped computer and boot directly into Arch without using Grub2 or any other bootloader?
Does this mean that I no longer need a dedicated 200Mb FAT32 partition for EFI?
Assuming I use Archboot to install, I would skip the install-bootloader step entirely, right?
Then, what do I have to do to direct UEFI to boot my Arch installation?
You place the kernel / initramfs directly on the EFI partition, that's how it boots.
ᶘ ᵒᴥᵒᶅ
Offline
dhave wrote:Forgive my disbelief, but are you guys really saying that, as of kernel 3.3, it's possible to install Arch Linux on the GPT-formatted SSD of my UEFI-equipped computer and boot directly into Arch without using Grub2 or any other bootloader?
Does this mean that I no longer need a dedicated 200Mb FAT32 partition for EFI?
Assuming I use Archboot to install, I would skip the install-bootloader step entirely, right?
Then, what do I have to do to direct UEFI to boot my Arch installation?
You place the kernel / initramfs directly on the EFI partition, that's how it boots.
And nothing else needs to be on the EFI partition? Does the EFI partition still need to be formatted FAT32? Thanks *very* much. I'm eager to try this. It would be great to leapfrog directly to the kernel without going through a bootloader.
I'll worry about how to enter on-the-fly boot-time kernel options later.
Offline
And nothing else needs to be on the EFI partition? Does the EFI partition still need to be formatted FAT32? Thanks *very* much. I'm eager to try this. It would be great to leapfrog directly to the kernel without going through a bootloader.
I'll worry about how to enter on-the-fly boot-time kernel options later.
Yes as far as i know, the requirements for the EFI partition stay the same, the kernel just functions as an EFI application itself.
ᶘ ᵒᴥᵒᶅ
Offline
dhave wrote:And nothing else needs to be on the EFI partition? Does the EFI partition still need to be formatted FAT32? Thanks *very* much. I'm eager to try this. It would be great to leapfrog directly to the kernel without going through a bootloader.
I'll worry about how to enter on-the-fly boot-time kernel options later.
Yes as far as i know, the requirements for the EFI partition stay the same, the kernel just functions as an EFI application itself.
Thanks. I know you guys have said that ("the kernel just functions as an EFI application itself") a half-dozen times in this thread alone, but that statement is so mind-blowing that I've had trouble taking it in.
Next thing I know, you're going to be saying that there is a Santa Claus, after all.
Offline
I patched my kernel with the efi config file patch and it works perfectly, the UEFI firmware boots the kernel directly without having to load a UEFI Shell or a bootloader.
# ls -l /boot/efi/boot/
total 7244
-rwxr-xr-x 1 root root 3324176 Apr 19 14:20 bootx64.efi
-rwxr-xr-x 1 root root 4092145 Apr 19 14:20 initramfs-linux.img
-rwxr-xr-x 1 root root 126 Apr 19 14:20 linux.conf
# cat /boot/efi/boot/linux.conf
root=/dev/mapper/crypt cryptdevice=/dev/sda3:crypt ro quiet initrd=\efi\boot\initramfs-linux.img
the best thing about this is that I can now do this:
# pacman -R syslinux
only bad news: as far as I can see the patch didn't make it into 3.4
Offline
I patched my kernel with the efi config file patch and it works perfectly, the UEFI firmware boots the kernel directly without having to load a UEFI Shell or a bootloader.
# ls -l /boot/efi/boot/ total 7244 -rwxr-xr-x 1 root root 3324176 Apr 19 14:20 bootx64.efi -rwxr-xr-x 1 root root 4092145 Apr 19 14:20 initramfs-linux.img -rwxr-xr-x 1 root root 126 Apr 19 14:20 linux.conf
# cat /boot/efi/boot/linux.conf root=/dev/mapper/crypt cryptdevice=/dev/sda3:crypt ro quiet initrd=\efi\boot\initramfs-linux.img
the best thing about this is that I can now do this:
# pacman -R syslinux
only bad news: as far as I can see the patch didn't make it into 3.4
Thanks for the report. I'll try this this weekend. Meanwhile, a pre-patched efi config enabled kernel would be a cool thing to see on the AUR, if anybody is so inclined.
Offline
Thanks for the report. I'll try this this weekend. Meanwhile, a pre-patched efi config enabled kernel would be a cool thing to see on the AUR, if anybody is so inclined.
I will upload an AUR package tomorrow.
Offline
I patched my kernel with the efi config file patch and it works perfectly, the UEFI firmware boots the kernel directly without having to load a UEFI Shell or a bootloader.
(
I'm getting an error when I try to apply the patch you linked:
patching file arch/x86/boot/compressed/eboot.c
Hunk #1 FAILED at 486.
patch: **** malformed patch at line 28: handle_ramdisks(efi_loaded_image_t *image,
I can't seem to track down the problem. Any ideas?
EDIT: I'm pretty sure these are trivial formatting problems.
Last edited by dhave (2012-04-19 18:34:57)
Offline
dhave wrote:Thanks for the report. I'll try this this weekend. Meanwhile, a pre-patched efi config enabled kernel would be a cool thing to see on the AUR, if anybody is so inclined.
I will upload an AUR package tomorrow.
Thanks. I'll look forward to that, especially since I'm botching the patch job.
Offline