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

Fri Mar 30 08:44:12 EDT 2012

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.
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