Re: [arch-releng] [DRAFT][RFC][PATCH][archiso] Add UEFI boot support via Linux >= 3.3 EFI boot stub.
---------- Forwarded message ---------- From: Rod Smith <rodsmith@rodsbooks.com> Date: Fri, Mar 30, 2012 at 04:21 Subject: Re: [arch-releng] [DRAFT][RFC][PATCH][archiso] Add UEFI boot support via Linux >= 3.3 EFI boot stub. To: Keshav P R <the.ridikulus.rat@gmail.com> On 03/29/2012 01:20 PM, Keshav P R wrote: See my comments below....
On Tue, Mar 27, 2012 at 18:56, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 03/27/2012 02:31 AM, Keshav P R wrote:
On Tue, Mar 27, 2012 at 07:04, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 03/26/2012 11:16 AM, Keshav P R wrote:
On Tue, Mar 20, 2012 at 23:15, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
> > > This is going to increase the iso size like hell. Having the kernel > and initrd files within a FAT image inside the iso is not a good idea. > A 32 MB fat image, come on. I know this is required for CD booting, > but this is not a good idea with efistub efilinux or elilo etc. For > USB booting you can just have the files in the iso itself, wherein the > user simply extract the iso in a FAT32 USB and boots from it. I say > drop support for iso booting via this fat fs image and support uefi > boot only in case of USBs. > > Regards. > > Keshav > OK, so just ignore this draft patch. UEFI boot support can be made manually by the user, just doing a copy of vmlinuz to the right place and optionally installing a boot manager.
A documentation on the wiki is sufficient.
You might be interested in rEFInd-x86_64 https://aur.archlinux.org/packages.php?ID=57632 which provides a nice menu for EFISTUB kernels.
Related info : http://www.rodsbooks.com/refind/linux.html http://www.rodsbooks.com/efi-bootloaders/efistub.html
[QUOTE from http://www.rodsbooks.com/refind/linux.html] rEFInd looks for a file called linux.conf in the same directory as the kernel file. This file is a practical requirement for booting from an auto-detected kernel. It consists of a series of lines, each of which consists of a label followed by a series of kernel options. The first line sets default options, and subsequent lines set options that are accessible from the main menu tag's submenu screen.
The intent of this system is that distribution maintainers can place their kernels, initial RAM disks, and a linux.conf file in their own subdirectory on the ESP. rEFInd will detect their kernels and create one main menu entry for each kernel. Each entry will implement as many options as there are lines in the linux.conf file. In this way, two or more distributions can each maintain their boot loader entries, without being too concerned for who maintains rEFInd as a whole. [/QUOTE]
The filename has been changed to refind_linux.conf in the upstream git repo so that it does not conflict with the proposed efistub config file by kernel devs
(http://sourceforge.net/p/refind/code/ci/c09200e2220b05bbade961bdc35f7da90d31...).
This should be pretty straightforward to implement in Archiso. For non-EFISTUB kernels like LTS ones, you can use efilinux-x86_64 https://aur.archlinux.org/packages.php?ID=57972 (Usage instructions - http://thread.gmane.org/gmane.linux.kernel/1172645 and http://article.gmane.org/gmane.linux.kernel/1175060). This might be a good alternative for grub2 uefi boot, although booting i686 kernels in x86_64 UEFI will not be supported by EFISTUB (which can be done using grub2). Support for mixed arch booting seems to have been merged for 3.4-rc1 .
Regards.
Keshav
Thanks for the work.
But this only added the advantage of passing command line options to the kernel. We still need a "FAT image" with bootx64.efi (rEFInd) + vmlinuz.efi + archiso.img (initramfs) + refind*.conf (for El Torito) that was the main dissapointed issue. Otherwise rEFInd can not find what file to load.
No. In this case just rEFInd (and the required icons - not all of them) needs to be in the FAT image. The kernels and initramfs can be in (ISO)/efi/(SUBDIR)/ along with (ISO)/efi/(SUBDIR)/refind_linux.conf containing the kernel parameters. If the (SUBDIR) is "arch" , ie. (ISO)/efi/arch/ , then refind will even display Archlinux icon making it easy for the user to differentiate the iso kernels from other kernels.
All the answers are at http://www.rodsbooks.com/refind/ .
Regards.
Keshav
Are you sure?
The only thing that can do rEFInd is launch EFI apps from drives listed by EFI firmware. A filesystem ISO9660 is not listed as a drive with filesystem by EFI, and rEFInd does not understand about ISO9660.
Thanks.
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Rod?
Some EFI implementations detect ISO-9660 filesystems and can read them, but I'm pretty sure that this is NOT true of all of them. VirtualBox's EFI can certainly do it. I've never gotten it to work on my laptop running UEFI DUET, but I think that's at least partly an issue with detecting disc changes on the laptop's optical drive. IIRC, at least one of my two UEFI PCs can read ISO-9660 *and* the contents of El Torito disk images, which can result in duplicated boot loader entries in some situations; but I think the other one can't read ISO-9660. On the flip side, I've heard that most Macs can't read the El Torito images, although they can read ISO-9660. (I haven't verified this, though.) I know that the Fedora/Red Hat people have been working on this. For instance, Matthew Garret has blogged about it publicly: http://mjg59.dreamwidth.org/4957.html At present, if you want an ISO-9660 image file to be bootable on EFI systems, your best bet is to put an EFI boot loader *BOTH* in the ISO-9660 filesystem *AND* in an El Torito image on the disc. If size is an issue, that means you'll probably need a boot loader that can read ISO-9660 so that it can read the kernel and initrd from outside the image file. AFAIK, that limits your choices to GRUB 2. In theory, another possibility would be to include a (presumably small) ISO-9660 driver for EFI in the El Torito image. That would broaden your choices of boot loaders considerably; however, if such a driver exists I don't know where it might be found. FWIW, in my tests, Ubuntu uses GRUB 2, Fedora uses GRUB Legacy, and OpenSUSE uses ELILO on their EFI-bootable optical disc images. If Fedora or OpenSUSE has found a way to "cheat," I don't know what they've done; but it looks like they've just swallowed the extra size requirements: - An Ubuntu 12.04 beta image has a file, boot/grub/efi.img, that holds a 512 KiB FAT filesystem with GRUB 2 (bootx64.efi). If they've got kernels buried in another image file, I've not found it. Since GRUB 2 has its own ISO-9660 driver, my guess is they use it to boot the kernel. - A Fedora 16 image has TWO image files, images/efiboot.img (916 KiB) and images/efidisk.img (135 MiB). The former holds GRUB Legacy, and the latter holds a GPT-partitioned whole-disk image with a boot loader, kernel, and initial RAM disk. I don't know why they've got two images. - An OpenSUSE 12.1 image has an image file, boot/x86_64/efi (44 MiB) that in turn holds ELILO, a kernel, and an initial RAM disk. It's conceivable that Fedora and/or OpenSUSE "cheat" by creating weird mapping in the filesystem so that the same sectors corresponding to the kernel can be accessed both directly as ISO-9660 files and inside FAT image files. If so, I don't know what software they might have done to do it. -- Rod Smith rodsmith@rodsbooks.com http://www.rodsbooks.com
On 03/30/2012 05:39 AM, Keshav P R wrote:
---------- Forwarded message ---------- From: Rod Smith<rodsmith@rodsbooks.com> Date: Fri, Mar 30, 2012 at 04:21 Subject: Re: [arch-releng] [DRAFT][RFC][PATCH][archiso] Add UEFI boot support via Linux>= 3.3 EFI boot stub. To: Keshav P R<the.ridikulus.rat@gmail.com>
On 03/29/2012 01:20 PM, Keshav P R wrote:
See my comments below....
On Tue, Mar 27, 2012 at 18:56, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 03/27/2012 02:31 AM, Keshav P R wrote:
On Tue, Mar 27, 2012 at 07:04, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 03/26/2012 11:16 AM, Keshav P R wrote:
On Tue, Mar 20, 2012 at 23:15, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote: >> >> This is going to increase the iso size like hell. Having the kernel >> and initrd files within a FAT image inside the iso is not a good idea. >> A 32 MB fat image, come on. I know this is required for CD booting, >> but this is not a good idea with efistub efilinux or elilo etc. For >> USB booting you can just have the files in the iso itself, wherein the >> user simply extract the iso in a FAT32 USB and boots from it. I say >> drop support for iso booting via this fat fs image and support uefi >> boot only in case of USBs. >> >> Regards. >> >> Keshav >> > OK, so just ignore this draft patch. UEFI boot support can be made > manually by the user, just doing a copy of vmlinuz to the right place > and > optionally installing a boot manager. > > A documentation on the wiki is sufficient.
You might be interested in rEFInd-x86_64 https://aur.archlinux.org/packages.php?ID=57632 which provides a nice menu for EFISTUB kernels.
Related info : http://www.rodsbooks.com/refind/linux.html http://www.rodsbooks.com/efi-bootloaders/efistub.html
[QUOTE from http://www.rodsbooks.com/refind/linux.html] rEFInd looks for a file called linux.conf in the same directory as the kernel file. This file is a practical requirement for booting from an auto-detected kernel. It consists of a series of lines, each of which consists of a label followed by a series of kernel options. The first line sets default options, and subsequent lines set options that are accessible from the main menu tag's submenu screen.
The intent of this system is that distribution maintainers can place their kernels, initial RAM disks, and a linux.conf file in their own subdirectory on the ESP. rEFInd will detect their kernels and create one main menu entry for each kernel. Each entry will implement as many options as there are lines in the linux.conf file. In this way, two or more distributions can each maintain their boot loader entries, without being too concerned for who maintains rEFInd as a whole. [/QUOTE]
The filename has been changed to refind_linux.conf in the upstream git repo so that it does not conflict with the proposed efistub config file by kernel devs
(http://sourceforge.net/p/refind/code/ci/c09200e2220b05bbade961bdc35f7da90d31...).
This should be pretty straightforward to implement in Archiso. For non-EFISTUB kernels like LTS ones, you can use efilinux-x86_64 https://aur.archlinux.org/packages.php?ID=57972 (Usage instructions - http://thread.gmane.org/gmane.linux.kernel/1172645 and http://article.gmane.org/gmane.linux.kernel/1175060). This might be a good alternative for grub2 uefi boot, although booting i686 kernels in x86_64 UEFI will not be supported by EFISTUB (which can be done using grub2). Support for mixed arch booting seems to have been merged for 3.4-rc1 .
Regards.
Keshav
Thanks for the work.
But this only added the advantage of passing command line options to the kernel. We still need a "FAT image" with bootx64.efi (rEFInd) + vmlinuz.efi + archiso.img (initramfs) + refind*.conf (for El Torito) that was the main dissapointed issue. Otherwise rEFInd can not find what file to load.
No. In this case just rEFInd (and the required icons - not all of them) needs to be in the FAT image. The kernels and initramfs can be in (ISO)/efi/(SUBDIR)/ along with (ISO)/efi/(SUBDIR)/refind_linux.conf containing the kernel parameters. If the (SUBDIR) is "arch" , ie. (ISO)/efi/arch/ , then refind will even display Archlinux icon making it easy for the user to differentiate the iso kernels from other kernels.
All the answers are at http://www.rodsbooks.com/refind/ .
Regards.
Keshav
Are you sure?
The only thing that can do rEFInd is launch EFI apps from drives listed by EFI firmware. A filesystem ISO9660 is not listed as a drive with filesystem by EFI, and rEFInd does not understand about ISO9660.
Thanks.
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Rod?
Some EFI implementations detect ISO-9660 filesystems and can read them, but I'm pretty sure that this is NOT true of all of them. VirtualBox's EFI can certainly do it. I've never gotten it to work on my laptop running UEFI DUET, but I think that's at least partly an issue with detecting disc changes on the laptop's optical drive. IIRC, at least one of my two UEFI PCs can read ISO-9660 *and* the contents of El Torito disk images, which can result in duplicated boot loader entries in some situations; but I think the other one can't read ISO-9660. On the flip side, I've heard that most Macs can't read the El Torito images, although they can read ISO-9660. (I haven't verified this, though.)
I know that the Fedora/Red Hat people have been working on this. For instance, Matthew Garret has blogged about it publicly:
http://mjg59.dreamwidth.org/4957.html
At present, if you want an ISO-9660 image file to be bootable on EFI systems, your best bet is to put an EFI boot loader *BOTH* in the ISO-9660 filesystem *AND* in an El Torito image on the disc. If size is an issue, that means you'll probably need a boot loader that can read ISO-9660 so that it can read the kernel and initrd from outside the image file. AFAIK, that limits your choices to GRUB 2.
In theory, another possibility would be to include a (presumably small) ISO-9660 driver for EFI in the El Torito image. That would broaden your choices of boot loaders considerably; however, if such a driver exists I don't know where it might be found.
FWIW, in my tests, Ubuntu uses GRUB 2, Fedora uses GRUB Legacy, and OpenSUSE uses ELILO on their EFI-bootable optical disc images. If Fedora or OpenSUSE has found a way to "cheat," I don't know what they've done; but it looks like they've just swallowed the extra size requirements:
- An Ubuntu 12.04 beta image has a file, boot/grub/efi.img, that holds a 512 KiB FAT filesystem with GRUB 2 (bootx64.efi). If they've got kernels buried in another image file, I've not found it. Since GRUB 2 has its own ISO-9660 driver, my guess is they use it to boot the kernel.
- A Fedora 16 image has TWO image files, images/efiboot.img (916 KiB) and images/efidisk.img (135 MiB). The former holds GRUB Legacy, and the latter holds a GPT-partitioned whole-disk image with a boot loader, kernel, and initial RAM disk. I don't know why they've got two images.
- An OpenSUSE 12.1 image has an image file, boot/x86_64/efi (44 MiB) that in turn holds ELILO, a kernel, and an initial RAM disk.
It's conceivable that Fedora and/or OpenSUSE "cheat" by creating weird mapping in the filesystem so that the same sectors corresponding to the kernel can be accessed both directly as ISO-9660 files and inside FAT image files. If so, I don't know what software they might have done to do it.
-- Rod Smith rodsmith@rodsbooks.com http://www.rodsbooks.com
Nice. Then for archiso we have only one choice (since grub2 is not an option): The boot method used by original patch. The FAT img can be reduced to ~22MB, (anyway the size is not a big issue). Maybe remove (kernel/initramfs) files from <iso9660>/EFI/archiso, since they do not have any effect, unless they are copied to a disk FAT-formatted medium like USB-disk, but they already exists directly on <iso9660>/arch/boot/$arch/. I guess can be a good idea including an EFI shell for systems that do not have it, since we need it to pass kernel parameters for now. (or for optional kernel parameters in a future if "linux.conf" is implemented in EFI_STUB). ISO size will be incremented only in x86_64 and dual images. Or maybe we can choice make only one of them EFI booteable, for example netinstall-dual. Doing in this way, we can guess that will works in all system. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
On Fri, Mar 30, 2012 at 18:14, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 03/30/2012 05:39 AM, Keshav P R wrote:
---------- Forwarded message ---------- From: Rod Smith<rodsmith@rodsbooks.com> Date: Fri, Mar 30, 2012 at 04:21 Subject: Re: [arch-releng] [DRAFT][RFC][PATCH][archiso] Add UEFI boot support via Linux>= 3.3 EFI boot stub. To: Keshav P R<the.ridikulus.rat@gmail.com>
On 03/29/2012 01:20 PM, Keshav P R wrote:
See my comments below....
On Tue, Mar 27, 2012 at 18:56, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 03/27/2012 02:31 AM, Keshav P R wrote:
On Tue, Mar 27, 2012 at 07:04, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 03/26/2012 11:16 AM, Keshav P R wrote: > > > On Tue, Mar 20, 2012 at 23:15, Gerardo Exequiel Pozzi > <vmlinuz386@yahoo.com.ar> wrote: >>> >>> >>> This is going to increase the iso size like hell. Having the kernel >>> and initrd files within a FAT image inside the iso is not a good >>> idea. >>> A 32 MB fat image, come on. I know this is required for CD booting, >>> but this is not a good idea with efistub efilinux or elilo etc. For >>> USB booting you can just have the files in the iso itself, wherein >>> the >>> user simply extract the iso in a FAT32 USB and boots from it. I say >>> drop support for iso booting via this fat fs image and support uefi >>> boot only in case of USBs. >>> >>> Regards. >>> >>> Keshav >>> >> OK, so just ignore this draft patch. UEFI boot support can be made >> manually by the user, just doing a copy of vmlinuz to the right >> place >> and >> optionally installing a boot manager. >> >> A documentation on the wiki is sufficient. > > > You might be interested in rEFInd-x86_64 > https://aur.archlinux.org/packages.php?ID=57632 which provides a nice > menu for EFISTUB kernels. > > Related info : > http://www.rodsbooks.com/refind/linux.html > http://www.rodsbooks.com/efi-bootloaders/efistub.html > > [QUOTE from http://www.rodsbooks.com/refind/linux.html] > rEFInd looks for a file called linux.conf in the same directory as > the > kernel file. This file is a practical requirement for booting from an > auto-detected kernel. It consists of a series of lines, each of which > consists of a label followed by a series of kernel options. The first > line sets default options, and subsequent lines set options that are > accessible from the main menu tag's submenu screen. > > The intent of this system is that distribution maintainers can place > their kernels, initial RAM disks, and a linux.conf file in their own > subdirectory on the ESP. rEFInd will detect their kernels and create > one main menu entry for each kernel. Each entry will implement as > many > options as there are lines in the linux.conf file. In this way, two > or > more distributions can each maintain their boot loader entries, > without being too concerned for who maintains rEFInd as a whole. > [/QUOTE] > > The filename has been changed to refind_linux.conf in the upstream > git > repo so that it does not conflict with the proposed efistub config > file by kernel devs > > > > (http://sourceforge.net/p/refind/code/ci/c09200e2220b05bbade961bdc35f7da90d31...). > > This should be pretty straightforward to implement in Archiso. For > non-EFISTUB kernels like LTS ones, you can use efilinux-x86_64 > https://aur.archlinux.org/packages.php?ID=57972 (Usage instructions - > http://thread.gmane.org/gmane.linux.kernel/1172645 and > http://article.gmane.org/gmane.linux.kernel/1175060). This might be a > good alternative for grub2 uefi boot, although booting i686 kernels > in > x86_64 UEFI will not be supported by EFISTUB (which can be done using > grub2). Support for mixed arch booting seems to have been merged for > 3.4-rc1 . > > Regards. > > Keshav > Thanks for the work.
But this only added the advantage of passing command line options to the kernel. We still need a "FAT image" with bootx64.efi (rEFInd) + vmlinuz.efi + archiso.img (initramfs) + refind*.conf (for El Torito) that was the main dissapointed issue. Otherwise rEFInd can not find what file to load.
No. In this case just rEFInd (and the required icons - not all of them) needs to be in the FAT image. The kernels and initramfs can be in (ISO)/efi/(SUBDIR)/ along with (ISO)/efi/(SUBDIR)/refind_linux.conf containing the kernel parameters. If the (SUBDIR) is "arch" , ie. (ISO)/efi/arch/ , then refind will even display Archlinux icon making it easy for the user to differentiate the iso kernels from other kernels.
All the answers are at http://www.rodsbooks.com/refind/ .
Regards.
Keshav
Are you sure?
The only thing that can do rEFInd is launch EFI apps from drives listed by EFI firmware. A filesystem ISO9660 is not listed as a drive with filesystem by EFI, and rEFInd does not understand about ISO9660.
Thanks.
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Rod?
Some EFI implementations detect ISO-9660 filesystems and can read them, but I'm pretty sure that this is NOT true of all of them. VirtualBox's EFI can certainly do it. I've never gotten it to work on my laptop running UEFI DUET, but I think that's at least partly an issue with detecting disc changes on the laptop's optical drive. IIRC, at least one of my two UEFI PCs can read ISO-9660 *and* the contents of El Torito disk images, which can result in duplicated boot loader entries in some situations; but I think the other one can't read ISO-9660. On the flip side, I've heard that most Macs can't read the El Torito images, although they can read ISO-9660. (I haven't verified this, though.)
I know that the Fedora/Red Hat people have been working on this. For instance, Matthew Garret has blogged about it publicly:
http://mjg59.dreamwidth.org/4957.html
At present, if you want an ISO-9660 image file to be bootable on EFI systems, your best bet is to put an EFI boot loader *BOTH* in the ISO-9660 filesystem *AND* in an El Torito image on the disc. If size is an issue, that means you'll probably need a boot loader that can read ISO-9660 so that it can read the kernel and initrd from outside the image file. AFAIK, that limits your choices to GRUB 2.
In theory, another possibility would be to include a (presumably small) ISO-9660 driver for EFI in the El Torito image. That would broaden your choices of boot loaders considerably; however, if such a driver exists I don't know where it might be found.
FWIW, in my tests, Ubuntu uses GRUB 2, Fedora uses GRUB Legacy, and OpenSUSE uses ELILO on their EFI-bootable optical disc images. If Fedora or OpenSUSE has found a way to "cheat," I don't know what they've done; but it looks like they've just swallowed the extra size requirements:
- An Ubuntu 12.04 beta image has a file, boot/grub/efi.img, that holds a 512 KiB FAT filesystem with GRUB 2 (bootx64.efi). If they've got kernels buried in another image file, I've not found it. Since GRUB 2 has its own ISO-9660 driver, my guess is they use it to boot the kernel.
- A Fedora 16 image has TWO image files, images/efiboot.img (916 KiB) and images/efidisk.img (135 MiB). The former holds GRUB Legacy, and the latter holds a GPT-partitioned whole-disk image with a boot loader, kernel, and initial RAM disk. I don't know why they've got two images.
- An OpenSUSE 12.1 image has an image file, boot/x86_64/efi (44 MiB) that in turn holds ELILO, a kernel, and an initial RAM disk.
It's conceivable that Fedora and/or OpenSUSE "cheat" by creating weird mapping in the filesystem so that the same sectors corresponding to the kernel can be accessed both directly as ISO-9660 files and inside FAT image files. If so, I don't know what software they might have done to do it.
-- Rod Smith rodsmith@rodsbooks.com http://www.rodsbooks.com
Nice. Then for archiso we have only one choice (since grub2 is not an option): The boot method used by original patch.
I don't plan to remove grub2 in Archboot since it is the only way to boot non-efistub (LTS) and i686 kernels from x86_64 UEFI firmware.
The FAT img can be reduced to ~22MB, (anyway the size is not a big issue). Maybe remove (kernel/initramfs) files from <iso9660>/EFI/archiso, since they do not have any effect, unless they are copied to a disk FAT-formatted medium like USB-disk, but they already exists directly on <iso9660>/arch/boot/$arch/.
I still don't like this whole kernel files within fat image idea. Anyway VirtualBox EFI has support for ISO9660 fs for which the code is at https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/EFI/Firmware2... . Its not difficult for me to compile the uefi driver and load it in the firmware while booting (via UEFI Shell). I do have an idea but i have to test it first.
I guess can be a good idea including an EFI shell for systems that do not have it, since we need it to pass kernel parameters for now. (or for optional kernel parameters in a future if "linux.conf" is implemented in EFI_STUB).
ISO size will be incremented only in x86_64 and dual images. Or maybe we can choice make only one of them EFI booteable, for example netinstall-dual.
Doing in this way, we can guess that will works in all system.
Regards. Keshav
On 03/30/2012 10:38 AM, Keshav P R wrote:
On Fri, Mar 30, 2012 at 18:14, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 03/30/2012 05:39 AM, Keshav P R wrote:
---------- Forwarded message ---------- From: Rod Smith<rodsmith@rodsbooks.com> Date: Fri, Mar 30, 2012 at 04:21 Subject: Re: [arch-releng] [DRAFT][RFC][PATCH][archiso] Add UEFI boot support via Linux>= 3.3 EFI boot stub. To: Keshav P R<the.ridikulus.rat@gmail.com>
On 03/29/2012 01:20 PM, Keshav P R wrote:
See my comments below....
On Tue, Mar 27, 2012 at 18:56, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 03/27/2012 02:31 AM, Keshav P R wrote:
On Tue, Mar 27, 2012 at 07:04, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote: > > On 03/26/2012 11:16 AM, Keshav P R wrote: >> >> On Tue, Mar 20, 2012 at 23:15, Gerardo Exequiel Pozzi >> <vmlinuz386@yahoo.com.ar> wrote: >>>> >>>> This is going to increase the iso size like hell. Having the kernel >>>> and initrd files within a FAT image inside the iso is not a good >>>> idea. >>>> A 32 MB fat image, come on. I know this is required for CD booting, >>>> but this is not a good idea with efistub efilinux or elilo etc. For >>>> USB booting you can just have the files in the iso itself, wherein >>>> the >>>> user simply extract the iso in a FAT32 USB and boots from it. I say >>>> drop support for iso booting via this fat fs image and support uefi >>>> boot only in case of USBs. >>>> >>>> Regards. >>>> >>>> Keshav >>>> >>> OK, so just ignore this draft patch. UEFI boot support can be made >>> manually by the user, just doing a copy of vmlinuz to the right >>> place >>> and >>> optionally installing a boot manager. >>> >>> A documentation on the wiki is sufficient. >> >> You might be interested in rEFInd-x86_64 >> https://aur.archlinux.org/packages.php?ID=57632 which provides a nice >> menu for EFISTUB kernels. >> >> Related info : >> http://www.rodsbooks.com/refind/linux.html >> http://www.rodsbooks.com/efi-bootloaders/efistub.html >> >> [QUOTE from http://www.rodsbooks.com/refind/linux.html] >> rEFInd looks for a file called linux.conf in the same directory as >> the >> kernel file. This file is a practical requirement for booting from an >> auto-detected kernel. It consists of a series of lines, each of which >> consists of a label followed by a series of kernel options. The first >> line sets default options, and subsequent lines set options that are >> accessible from the main menu tag's submenu screen. >> >> The intent of this system is that distribution maintainers can place >> their kernels, initial RAM disks, and a linux.conf file in their own >> subdirectory on the ESP. rEFInd will detect their kernels and create >> one main menu entry for each kernel. Each entry will implement as >> many >> options as there are lines in the linux.conf file. In this way, two >> or >> more distributions can each maintain their boot loader entries, >> without being too concerned for who maintains rEFInd as a whole. >> [/QUOTE] >> >> The filename has been changed to refind_linux.conf in the upstream >> git >> repo so that it does not conflict with the proposed efistub config >> file by kernel devs >> >> >> >> (http://sourceforge.net/p/refind/code/ci/c09200e2220b05bbade961bdc35f7da90d31...). >> >> This should be pretty straightforward to implement in Archiso. For >> non-EFISTUB kernels like LTS ones, you can use efilinux-x86_64 >> https://aur.archlinux.org/packages.php?ID=57972 (Usage instructions - >> http://thread.gmane.org/gmane.linux.kernel/1172645 and >> http://article.gmane.org/gmane.linux.kernel/1175060). This might be a >> good alternative for grub2 uefi boot, although booting i686 kernels >> in >> x86_64 UEFI will not be supported by EFISTUB (which can be done using >> grub2). Support for mixed arch booting seems to have been merged for >> 3.4-rc1 . >> >> Regards. >> >> Keshav >> > Thanks for the work. > > But this only added the advantage of passing command line options to > the > kernel. We still need a "FAT image" with bootx64.efi (rEFInd) + > vmlinuz.efi > + archiso.img (initramfs) + refind*.conf (for El Torito) that was the > main > dissapointed issue. Otherwise rEFInd can not find what file to load. > No. In this case just rEFInd (and the required icons - not all of them) needs to be in the FAT image. The kernels and initramfs can be in (ISO)/efi/(SUBDIR)/ along with (ISO)/efi/(SUBDIR)/refind_linux.conf containing the kernel parameters. If the (SUBDIR) is "arch" , ie. (ISO)/efi/arch/ , then refind will even display Archlinux icon making it easy for the user to differentiate the iso kernels from other kernels.
All the answers are at http://www.rodsbooks.com/refind/ .
Regards.
Keshav
Are you sure?
The only thing that can do rEFInd is launch EFI apps from drives listed by EFI firmware. A filesystem ISO9660 is not listed as a drive with filesystem by EFI, and rEFInd does not understand about ISO9660.
Thanks.
-- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
Rod?
Some EFI implementations detect ISO-9660 filesystems and can read them, but I'm pretty sure that this is NOT true of all of them. VirtualBox's EFI can certainly do it. I've never gotten it to work on my laptop running UEFI DUET, but I think that's at least partly an issue with detecting disc changes on the laptop's optical drive. IIRC, at least one of my two UEFI PCs can read ISO-9660 *and* the contents of El Torito disk images, which can result in duplicated boot loader entries in some situations; but I think the other one can't read ISO-9660. On the flip side, I've heard that most Macs can't read the El Torito images, although they can read ISO-9660. (I haven't verified this, though.)
I know that the Fedora/Red Hat people have been working on this. For instance, Matthew Garret has blogged about it publicly:
http://mjg59.dreamwidth.org/4957.html
At present, if you want an ISO-9660 image file to be bootable on EFI systems, your best bet is to put an EFI boot loader *BOTH* in the ISO-9660 filesystem *AND* in an El Torito image on the disc. If size is an issue, that means you'll probably need a boot loader that can read ISO-9660 so that it can read the kernel and initrd from outside the image file. AFAIK, that limits your choices to GRUB 2.
In theory, another possibility would be to include a (presumably small) ISO-9660 driver for EFI in the El Torito image. That would broaden your choices of boot loaders considerably; however, if such a driver exists I don't know where it might be found.
FWIW, in my tests, Ubuntu uses GRUB 2, Fedora uses GRUB Legacy, and OpenSUSE uses ELILO on their EFI-bootable optical disc images. If Fedora or OpenSUSE has found a way to "cheat," I don't know what they've done; but it looks like they've just swallowed the extra size requirements:
- An Ubuntu 12.04 beta image has a file, boot/grub/efi.img, that holds a 512 KiB FAT filesystem with GRUB 2 (bootx64.efi). If they've got kernels buried in another image file, I've not found it. Since GRUB 2 has its own ISO-9660 driver, my guess is they use it to boot the kernel.
- A Fedora 16 image has TWO image files, images/efiboot.img (916 KiB) and images/efidisk.img (135 MiB). The former holds GRUB Legacy, and the latter holds a GPT-partitioned whole-disk image with a boot loader, kernel, and initial RAM disk. I don't know why they've got two images.
- An OpenSUSE 12.1 image has an image file, boot/x86_64/efi (44 MiB) that in turn holds ELILO, a kernel, and an initial RAM disk.
It's conceivable that Fedora and/or OpenSUSE "cheat" by creating weird mapping in the filesystem so that the same sectors corresponding to the kernel can be accessed both directly as ISO-9660 files and inside FAT image files. If so, I don't know what software they might have done to do it.
-- Rod Smith rodsmith@rodsbooks.com http://www.rodsbooks.com
Nice. Then for archiso we have only one choice (since grub2 is not an option): The boot method used by original patch. I don't plan to remove grub2 in Archboot since it is the only way to boot non-efistub (LTS) and i686 kernels from x86_64 UEFI firmware. This is archiso :) Archiso does not provide boot to LTS kernels.
The FAT img can be reduced to ~22MB, (anyway the size is not a big issue). Maybe remove (kernel/initramfs) files from<iso9660>/EFI/archiso, since they do not have any effect, unless they are copied to a disk FAT-formatted medium like USB-disk, but they already exists directly on <iso9660>/arch/boot/$arch/. I still don't like this whole kernel files within fat image idea. This is what works in all cases without doing "hacks".
Even I can reduce initramfs image removing uneeded things for EFI. (like network boot, thats introduce lots of fw and lkm). The "FAT image" can be reduced to ~12M if size matters.
Anyway VirtualBox EFI has support for ISO9660 fs for which the code is at https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Devices/EFI/Firmware2... . Its not difficult for me to compile the uefi driver and load it in the firmware while booting (via UEFI Shell).
I do have an idea but i have to test it first. Sounds good, but for this, we need at least that such package hits [community].
Of course, I can not take the last decision here, I am just a "contributor" to archiso. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1
participants (2)
-
Gerardo Exequiel Pozzi
-
Keshav P R