You are not logged in.
First of let me apologize if I'm making no sense at all. This isn't really my area of expertise.
I just recently stumbled upon some rather interesting "news" about the linux kernel developers working to implement a an EFI/GTP (I think) bootloader in the kernel it self. I would very much like to know if this is actually true, I'd like to learn more and follow the development, but I haven't been able to find any relevant information, appart from the incomplete mailing list I stumbled upon.
I suspect that I'm simply using the wrong search parameters. Again, it's not like I know too much about what I'm doing.
In any case, if you have even the slightest idea what I'm talking about, please do guide me in the right direction.
Best regards.
Last edited by zacariaz (2012-03-01 20:02:04)
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
See Archwiki UEFI page.
Offline
They're not putting a bootloader into the kernel, they've made the kernel into an EFI app so that it can be loaded without a bootloader.
CONFIG_EFI_STUB:
This kernel feature allows a bzImage to be loaded directly
by EFI firmware without the use of a bootloader.
Offline
They're not putting a bootloader into the kernel, they've made the kernel into an EFI app so that it can be loaded without a bootloader.
CONFIG_EFI_STUB:
This kernel feature allows a bzImage to be loaded directly
by EFI firmware without the use of a bootloader.
So what you're saying is that there is no need for a bootloader anymore?
It's all very confusing.
anyway, config_efi_stub is a rather specific term, so I suppose finding further information should be easier now
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
Well, I think I've got the gist of it now, though there's still a few gaping holes as to how you make use of this feature in reality, but then again, it will be a couple of months before I actually need to know.
So thanks for the help.
If you know of some good resources on the subject of UEFI not involving grub2 and similar, please do let me know, otherwise have a nice day.
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
Just a little extra note.
As I now understand it, the CONFIG_EFI_STUB is only part of kernel 3.3 and later, so it's no surprise really that I've had a hard time finding information, since we're currently at 3.3-RC5
Just wanted to mention it in case I'm wrong and also if anyone would dare to speculate when 3.3 is ready.
I am a philosopher, of sorts, not a troll or an imbecile.
My apologies that this is not always obvious, despite my best efforts.
Offline
Does this mean that we don't need the Windows 8 controversy anymore?
I may have to CONSOLE you about your usage of ridiculously easy graphical interfaces...
Look ma, no mouse.
Offline
I wonder if EFI_STUB will also work with something like rEFIt...
ᶘ ᵒᴥᵒᶅ
Offline
Isn't rEFIt a bootloader? The point of EFI_STUB is that the kernel is loaded directly from the efi firmware, not from a bootloader. Of course the kernel is still normally loadable from a bootloader, even on a BIOS machine.
Last edited by Gusar (2012-03-18 19:10:40)
Offline
Isn't rEFIt a bootloader? The point of EFI_STUB is that the kernel is loaded directly from the efi firmware, not from a bootloader. Of course the kernel is still normally loadable from a bootloader, even on a BIOS machine.
Hmm you could well be right, this EFI stuff still eludes me a bit... I was mainly thinking about a way to boot straight into Arch from rEFIt without chainloading grub/syslinux first.
ᶘ ᵒᴥᵒᶅ
Offline
Does this mean that we don't need the Windows 8 controversy anymore?
This has nothing to do with secure boot. This is about the kernel being a uefi bootloader for itself.
Offline
Gusar wrote:Isn't rEFIt a bootloader? The point of EFI_STUB is that the kernel is loaded directly from the efi firmware, not from a bootloader. Of course the kernel is still normally loadable from a bootloader, even on a BIOS machine.
Hmm you could well be right, this EFI stuff still eludes me a bit... I was mainly thinking about a way to boot straight into Arch from rEFIt without chainloading grub/syslinux first.
http://www.rodsbooks.com/efi-bootloaders/efistub.html
http://www.rodsbooks.com/refind/linux.html
https://aur.archlinux.org/packages.php?ID=57632
CONFIG_EFI_STUB has been enabled in linux-3.3 pkg which should hit testing soon.
Offline
Isn't rEFIt a bootloader? The point of EFI_STUB is that the kernel is loaded directly from the efi firmware, not from a bootloader. Of course the kernel is still normally loadable from a bootloader, even on a BIOS machine.
No, rEFIt is a boot manager. It is not a boot loader, in the sense it cannot directly launch the kernel and initramfs, like grub or syslinux. All rEFIt or rEFInd does is to chainload another UEFI application, which may or may not be a bootloader.
Last edited by the.ridikulus.rat (2012-03-19 15:40:44)
Offline
I suggest changing the title to be more specific like "Linux Kernel 3.3+ EFISTUB bootloader" as the title might give an idea that in the kernel may not need a bootloader in any system (bios/uefi).
Last edited by the.ridikulus.rat (2012-04-20 19:19:41)
Offline
Just a little extra note.
As I now understand it, the CONFIG_EFI_STUB is only part of kernel 3.3 and later, so it's no surprise really that I've had a hard time finding information, since we're currently at 3.3-RC5Just wanted to mention it in case I'm wrong and also if anyone would dare to speculate when 3.3 is ready.
Offline
I was mainly thinking about a way to boot straight into Arch from rEFIt without chainloading grub/syslinux first.
Thanks to the info and links the.ridikulus.rat provided, I've now learned a bit more about this stuff (I'm probably still missing a lot ). Basically, rEFIt is a manager that launches bootloaders. With EFI_STUB, the kernel is it's own bootloader, so what you say is indeed possible - start linux from rEFIt without going through grub/syslinux. Well, it would be possible if there wasn't for one huge problem - rEFIt doesn't allow passing options, which is needed in this case. But that's where rEFIt's fork (rEFInd) comes into play.
Further, there are patches on the kernel mailing list that will make it possible for an EFI_STUB kernel to read options from a file. Then not even rEFInd will be needed. Strictly speaking it isn't needed even now, but you need to type the options manually on the efi shell, which isn't very convenient. Fun stuff all this, innit? . It's a whole new crazy world.
Offline
litemotiv wrote:I was mainly thinking about a way to boot straight into Arch from rEFIt without chainloading grub/syslinux first.
Thanks to the info and links the.ridikulus.rat provided, I've now learned a bit more about this stuff (I'm probably still missing a lot ). Basically, rEFIt is a manager that launches bootloaders. With EFI_STUB, the kernel is it's own bootloader, so what you say is indeed possible - start linux from rEFIt without going through grub/syslinux. Well, it would be possible if there wasn't for one huge problem - rEFIt doesn't allow passing options, which is needed in this case. But that's where rEFIt's fork (rEFInd) comes into play.
Further, there are patches on the kernel mailing list that will make it possible for an EFI_STUB kernel to read options from a file. Then not even rEFInd will be needed. Strictly speaking it isn't needed even now, but you need to type the options manually on the efi shell, which isn't very convenient. Fun stuff all this, innit? . It's a whole new crazy world.
Cool, thanks for the pro-active research!
ᶘ ᵒᴥᵒᶅ
Offline
Further, there are patches on the kernel mailing list that will make it possible for an EFI_STUB kernel to read options from a file. Then not even rEFInd will be needed. Strictly speaking it isn't needed even now, but you need to type the options manually on the efi shell, which isn't very convenient. Fun stuff all this, innit? . It's a whole new crazy world.
Well I think efistub will become the preferred boot method uefi systems. But needs the kernels and initramfs files to be in UEFISYS partition. Even if rEFInd's linux.conf may not be required once this efistub config file support is added in 3.4, it still provides a nice menu for efistub kernels.
Offline
Alright, rEFInd installed, looking forward to try out EFI_STUB one of these days when a suitable kernel lands.
ᶘ ᵒᴥᵒᶅ
Offline
Alright, rEFInd installed, looking forward to try out EFI_STUB one of these days when a suitable kernel lands.
testing/linux-3.3 has CONFIG_EFI_STUB enabled and it boots via UEFI Shell. Didn't try rEFInd yet.
Offline
litemotiv wrote:Alright, rEFInd installed, looking forward to try out EFI_STUB one of these days when a suitable kernel lands.
testing/linux-3.3 has CONFIG_EFI_STUB enabled and it boots via UEFI Shell. Didn't try rEFInd yet.
I'm not having luck booting STUB through rEFInd yet, i'm using this config:
menuentry Linux {
loader /efi/linux/vmlinuz-linux
initrd /efi/linux/initramfs-linux.img
icon /efi/refind/icons/os_linux.icns
options "root=/dev/sda5 ro init=/bin/systemd"
}
$ ls /efi/linux
initramfs-linux.img vmlinuz-linux.efi
The initramfs boots, but triggers an immediate "unable to mount root fs on unknown block(0,0).
ᶘ ᵒᴥᵒᶅ
Offline
Update: i am now succesfully booting the stock Arch 3.3 kernel from rEFInd with EFI_STUB. The main tweaks i had to make were:
Rename the kernel and initramfs files to include version numbers:
$ ls /efi/linux
vmlinuz-linux-3.3.0.efi
initrd.img-3.3.0
linux.conf
Other filenames might work too, but the autodetection mechanism is not 100% yet. For instance using the filename initramfs-linux.img didn't work.
linux.conf contains the kernel parameters:
$ cat linux.conf
"Default" "root=/dev/sda5 ro"
Last edited by litemotiv (2012-03-23 15:29:35)
ᶘ ᵒᴥᵒᶅ
Offline
@litemotiv: Is your system mac or non-mac?
Offline
@litemotiv: Is your system mac or non-mac?
Macbook Air (4,2). I've reported the bug with the filenames to Rod Smith and he's going to address that, so in the near future it should be a matter of placing the Arch kernel/ramfs in the appropriate location and including a linux.conf file with the kernel parameters.
edit: the filename issue will be fixed in rEFInd 0.2.1.2
Last edited by litemotiv (2012-03-23 20:28:54)
ᶘ ᵒᴥᵒᶅ
Offline
edit: the filename issue will be fixed in rEFInd 0.2.1.2
I updated the refind-x86_64 AUR package to 0.2.2 which fixed the autodetection of kernels with no version numbers in their filenames (like Arch's kernel files). It also detects Arch's initramfs files (corresponding to the kernel files).
I also renamed (via sed in refind source) linux.conf to refind_linux.conf (requested Rod Smith to change it upstream) so that it does not conflict with the proposed linux.conf efistub config file https://lkml.org/lkml/2012/3/18/45 .
Last edited by the.ridikulus.rat (2012-03-25 11:02:31)
Offline