Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
Hi,
adrian15 wrote:
> 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.
For now i only state that this is a model by which one
can describe the purpose of boot loaders in an ISO filesystem.
> And, well, how would you go into enabling or not a given bootloader given a
> Medium?, Firmware?, Architecture? combination.
I am pondering a better language for describing the boot
equipment to xorriso. It would have to be less tricky than the
zoo of inherited and self-invented mkisofs options.
Not easy.
> I'm not sure I understand why we need this.
Mainly take care not to create a terminology which contradicts
the correct model. (As far as it is identified yet.)
> Your proposal begins to make sense although I'm not 100% convinced ;).
I am not convinced either. The model matches the facts, so far.
But its straightforward implementation is not yet clear to me.
There is a fourth dimension to be expressed: Bootloader.
Then there is the dimension of ISO filesystem objects.
A user wish would contain at least
ISO-Object, Bootloader, Medium, Firmware, Architecture
E.g.
Appended Partition, with GRUB2 content, for CDROM and HDD, via EFI, on i386
ISO Data File, with SYSLINUX content, for HDD, via BIOS, on i386 and amd64
I am not sure whether this list of more or less combinable
dimensions is complete yet.
Further one will want to express whether the gaps between partitions
should be filled, which kinds of partition tables shall emerge, ...
These properties are global to the ISO, not specific to a single
boot image. Some are combinable, some are mutally exclusive.
(Maybe it is time to break out an UML editor.)
> > [SYSLINUX]
> > Did you try whether it boots via EFI if no BIOS boot equipment
> > is in the ISO ?
> Well, I tried: kvm -bios /usr/share/ovmf/OVMF.fd -boot d -cdrom file.iso .
More we cannot expect. :)
The fact that there is a minimal operating system in the EFI
System Partition explains why it works.
> > debian-cd has an MBR partition 0xef and a GPT
> > partition which point to that EFI boot image. (The GPT is to be
> > ignored by all sane EFI implementations.)
> Ok. Did you mean "NOT to be ignored"?
No. The GPT is surplus, according to UEFI 2.4 specs.
Either you have an MBR partition 0xef or you have GPT. Not both.
But Matthew Garrett had reason to produce it.
Re-reading his blog
http://mjg59.dreamwidth.org/11285.html
i get the suspicion, that he first tried GPT alone, then added
MBR partition 0xef, and so invalidated his original GPT approach.
> Maybe that's why the syslinux-efi does not boot. I could give it a try
> changing the partition type and see what happens.
Rather not. The presence of MBR partition 0xef should cause
EFI to simply not look for GPT partitions.
> > I recently tested on my Sid VM with various combinations of grub-pc,
> > grub-efi-ia32-bin, and grub-efi-amd64-bin. All together, pair-wise, alone.
> > They all booted with qemu via its default BIOS and via OVMF (as EFI).
> Did you try to boot them either as a cdrom or as a hard disk? I think that
> EFI + hard disk was the one failed for me.
Hopefully i tested all reasonable combinations. (But i begin to doubt
that i tried an i386 VM. Will have to check.)
> That's interesting. So we have Fedora, debian-cd, grub-mkimage ways of
> dealing with UEFI. Probably Ubuntu has also its own way of handling it too.
Fedora, Debian, Ubuntu use the Matthew Garrett layout.
Debian and Ubuntu omit the HFS+ aspect of that layout, though.
OpenSuSE is different. They have a mountable ISO partition after
the EFI System Partition. For that stunt they cut off the head
of a first ISO and prepend it to a second, reproducibly built
ISO, which lacks the EFI partition data file.
(In american length units, Frankenstein castle is not very far
from Nuremberg.)
grub-mkrescue layout is rarely used for distro ISOs.
I blame this on the existing SYSLINUX based production software
for distro ISOs. In principle, a pure GRUB2 or a pure SYSLINUX
equipment appears to be the more reasonable choice.
> So you don't like the primary or secondary terms.
> How does xorriso name them?
They have no partitcular name in the docs.
Joerg Schilling obviously considered them "alternative" when he
invented option name -eltorito-alt-boot.
We should not put too much weight on that options naming tradition.
It grew slowly and in part cluelessly. (Joerg's and mine alike.)
> Maybe we can just name them as:
> "Main bootloader"
> and
> "Alternate bootloader".
The model does not imply any ranking. "First", "Second", "Third"
could be justified, because there are lists in El Torito and
partition tables where the boot entries have to line up in sequence.
For my taste, "Main" or "Primary" too much implies a rank.
> So that we can force a given bootloader to be used only as a "Main eltorito
entry" ?
Currently this would be done by mentioning it in the xorrisofs
argument list as first of the El Torito boot images.
If you do not add options to make it visible in partition tables,
then some other boot loader can be first (or "Main") in those tables.
> So... what if there is a fourth dimension for
> choosing if the job description goes first or second in the mkisofs command?
The lists depend on the target Medium. CDROM has El Torito.
HDD has various partition tables and possibly the MBR boot code.
In my model the positions in lists are implicitely given
by the sequence of model statements. This is because i deem
the sequence not to be decisive.
Of course we can add modifiers to "Medium". Like "MBR2" or "GPT3".
This opens a new can of worms: colliding and empty list entries.
(I planned to let xorriso arrange the desired entries in
compact lists without entries being requested twice.)
Have a nice day :)
Thomas
Reply to: