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

[Keshav P R]

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