Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 21/01/16 a las 10:13, Thomas Schmitt escribió:
Hi,
For the nomenclature: "USB" alone is misleading because there are
also optical drives attachable to USB. Better distinguish the boot
media families CDROM (CD, DVD, BD) and HDD (hard disk, USB stick,
memory card, ...).
Sorry. I was refering to USB stick then.
adrian15 wrote:
Grub-pc would be the one installed to be boot but syslinux files would be
there for Multi-USB tools to know how to understand the iso and put it into
an USB.
You mean the capability to boot the ISO via BIOS from USB stick ?
(Known with SYSLINUX as "isohybrid".)
grub-pc is supposed to be bootable that way too. Have a look at the
result of grub-mkrescue.
When running xorriso -as mkisofs, the decisive trick of grub-mkrescue
for BIOS bootability from HDD is:
--grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
(It is obvious that only one bootloader can put its MBR at the
start of the ISO. So additional -isohybrid-mbr for SYSLINUX
would conflict.)
CDROM bootability via BIOS is caused by
-b boot/grub/i386-pc/eltorito.img \
-no-emul-boot -boot-load-size 4 -boot-info-table \
--grub2-boot-info
(Options learned from grub-mkrescue tests on Debian Sid.)
Well, yes, I know that you can use grub-pc to be able to boot a single
image that boots from either a hard disk / USB stick / CDROM media in a
BIOS system.
I did use that setup for building earlier versions of Rescatux (which
included native Super Grub2 Disk in them).
My first will on putting both syslinux and grub-pc in the same media had
not the purpose of making it bootable with two methods but rather to:
* Default boot into Grub2 (so that Super Grub2 Disk could be used natively).
* Confuse multi usb stick tools such as yumi to think that the iso was
actually isolinux based. That way they can easily extract iso contents
and put it into a multi usb stick device.
As I said before this was the original idea that made me add the primary
and secondary bootloaders concept to live-build.
--bootloaders="syslinux,grub-efi,syslinux-efi"
Here i wonder whether (or how) your syslinux-efi boots out of an
ISO 9660 filesystem. My current knowledge is that SYSLINUX cannot
do this.
Yeah, you are right. You can take a look at what I have left from
Hertzog patch here:
https://github.com/adrian15/live-build/commit/1397b6fc3dbf7d7f1e6a077a37b9f2e6ee7d7f39
His workaround for syslinux-efi not being able to boot out of an ISO
9660 filesystem is to put the bootloader files, kernel and initrd on the
efi image.
That way the efi image should be able to load the initrd in the ram so
that the rest of the system can be found.
(Back in the day in some old systems you had to do this trick, e.g., add
these files to the old IDE attached disk because BIOS was unable to boot
the SATA attached disk. But the initrd, yes, knew how to handle it.)
Now primary means: "First lure" and secondary means "Second lure" by your
definition.
There are normally two lures per firmware-hardware combination.
Depending on the medium, the lures are recognized in El Torito,
or in MBR, or in partition tables.
In general we have theses dimensions
{Medium: CDROM, HDD} x
{Firmware: BIOS, EFI, ... exotic others ...} x
{Hardware: i386, amd64, ... exotic others ...}
Not all tuples chosen from these sets are valid and not all
valid tuples can be combined in one ISO filesystem.
But the 8 main combinations for PC hardware are valid and
combinable.
I would avoid ranking terms like "first" or "primary".
Job descriptions for bootloaders could rather look like
(CDROM + HDD, BIOS, i386 + amd64)
(HDD, EFI, i386)
(HDD, EFI, amd64)
Some of them can hardly be separated from each other.
E.g. (HDD, BIOS, i386) and (HDD, BIOS, amd64) have identical
technical properties.
I am sorry. I agree with you but I'm not going to change my current
naming without further input. I would need a patch from you or a
concrete new naming system with examples that replace the current names.
It seems you are proposing to add like three tags: Medium?, Firmware?,
Architecture? but I don't get how that would transform into options that
the final user can use.
And, well, how would you go into enabling or not a given bootloader
given a Medium?, Firmware?, Architecture? combination.
I mean, don't get me wrong, I want to code this right but I'm not sure I
understand why we need this. I mean, I know that the medium already
choosing by either binary_hdd or binary_iso . And, the architectures can
also be choosen if needed (LB_ARCHITECTURES if I'm not mistaken). Not
sure why you want to question of all that out of a sudden.
Anyway, as I said, maybe giving me concrete examples might make me
change my mind. If we are going to implement UEFI support into
live-build let's do it right.
Given the way that both grub-efi and syslinux-efi use:
/efi/boot/bootia32.efi
and
/efi/boot/bootx64.efi
the last one to be run would overwrite the first one efi files.
You could combine bootia32.efi from the one boot loader and
bootx64.efi from the other boot loader, if you find a use case
for that stunt.
Without such a use case, i would decide for one boot loader per
firmware. Just to keep things simple.
So... when binary_grub-efi or binary_syslinux-efi start to run they
check if LB_FIRMWARE_EFI_DEFINED is set or not. If it's already set then
they fail.
Your proposal begins to make sense although I'm not 100% convinced ;).
So... How would you go about for a:
--bootloaders="syslinux,grub-efi,syslinux-efi"
I'd state that you don't need syslinux-efi if you have grub-efi
which is much better exercised with ISO 9660.
As said, nobody ever reported about success of SYSLINUX from
CDROM via EFI. I dimly remember that hpa, the author of SYSLINUX,
once stated on syslinux@zytor.com that the capability was missing
in SYSLINUX EFI to hop from the FAT filesystem into the ISO filesystem.
I agree. See above about how initrd is used here.
they would overwrite their /efi/boot/boot*efi files ?
The EFI startup binaries of grub-efi and syslinux-efi would conflict
inside your FAT filesystem, indeed. There are supposed to be ways to
solve this conflict and offer the choice at boot time. For that you'd
need to have own EFI startup binaries which then hop on the programs
of one of the offered boot loaders.
But, well, what would be the use case for such a choice ?
Just testing which boots in more systems ? Well, I think it's a better
choice to test only-grub-efi and only-syslinux-efi ISOs instead :).
Basically the use case was the final user requesting it and then, us, as
developers, deciding if we could offer that functionality or not.
Now, it's clear to me that it's better not to offer it.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Reply to: