[arch-releng] [DRAFT][RFC][PATCH][archiso] Add UEFI boot support via Linux >= 3.3 EFI boot stub.

[Keshav P R]

On Fri, Mar 30, 2012 at 18:14, Gerardo Exequiel Pozzi
<vmlinuz386 at yahoo.com.ar> wrote:
> On 03/30/2012 05:39 AM, Keshav P R wrote:
>>
>> ---------- Forwarded message ----------
>> From: Rod Smith<rodsmith at 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 at 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 at 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 at 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 at 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/c09200e2220b05bbade961bdc35f7da90d318abf/).
>>>>>>>
>>>>>>> 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 at 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/VBoxPkg/VBoxFsDxe/VBoxIso9660.inf
. 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