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

Fri Mar 30 10:33:02 EDT 2012

On 03/30/2012 10:38 AM, Keshav P R wrote:
> 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.
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/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.
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