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