On Fri, Mar 30, 2012 at 18:14, Gerardo Exequiel Pozzi <[email protected]> wrote: > On 03/30/2012 05:39 AM, Keshav P R wrote: >> >> ---------- Forwarded message ---------- >> From: Rod Smith<[email protected]> >> 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<[email protected]> >> >> >> 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 >>> <[email protected]> wrote: >>>> >>>> On 03/27/2012 02:31 AM, Keshav P R wrote: >>>>> >>>>> >>>>> On Tue, Mar 27, 2012 at 07:04, Gerardo Exequiel Pozzi >>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> On 03/26/2012 11:16 AM, Keshav P R wrote: >>>>>>> >>>>>>> >>>>>>> On Tue, Mar 20, 2012 at 23:15, Gerardo Exequiel Pozzi >>>>>>> <[email protected]> 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 >> [email protected] >> 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
