Debian Bug report logs - #832687
support uefi

Full log

🔗 View this message in rfc822 format

X-Loop: [email protected]
Subject: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
Reply-To: "Thomas Schmitt" <[email protected]>, [email protected]
Resent-From: "Thomas Schmitt" <[email protected]>
Resent-To: [email protected]
Resent-CC: Debian QA Group <[email protected]>
X-Loop: [email protected]
Resent-Date: Sat, 23 Jan 2016 08:24:01 +0000
Resent-Message-ID: <[email protected]>
Resent-Sender: [email protected]
X-Debian-PR-Message: followup 731709
X-Debian-PR-Package: live-build
X-Debian-PR-Keywords: patch
X-Debian-PR-Source: live-build
Received: via spool by [email protected] id=B731709.145353726915841
          (code B ref 731709); Sat, 23 Jan 2016 08:24:01 +0000
Received: (at 731709) by bugs.debian.org; 23 Jan 2016 08:21:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.4.0-bugs.debian.org_2005_01_02
	(2014-02-07) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-5.2 required=4.0 tests=BAYES_00,FOURLA,FREEMAIL_FROM,
	HAS_BUG_NUMBER,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,RP_MATCHES_RCVD,SPF_PASS,
	URIBL_CNKR autolearn=ham autolearn_force=no
	version=3.4.0-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 27; hammy, 150; neutral, 375; spammy,
	0. spammytokens: hammytokens:0.000-+--UD:iso, 0.000-+--reproducibly,
	0.000-+--amd64, 0.000-+--qemu, 0.000-+--grubefi
Received: from mout.gmx.net ([212.227.17.21])
	by buxtehude.debian.org with esmtps (TLS1.2:DHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.84)
	(envelope-from <[email protected]>)
	id 1aMtRU-00046L-Ay
	for [email protected]; Sat, 23 Jan 2016 08:21:09 +0000
Received: from scdbackup.webframe.org ([91.63.100.181]) by mail.gmx.com
 (mrgmx103) with ESMTPSA (Nemesis) id 0MVNWU-1acrS91eWc-00Yl6G; Sat, 23 Jan
 2016 09:20:59 +0100
Date: Sat, 23 Jan 2016 09:21:52 +0100
From: "Thomas Schmitt" <[email protected]>
To: [email protected]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Cc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected]
References: <[email protected]>
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
X-Provags-ID: V03:K0:L4VRnWkDF1BRjXl/Gr/LyPkCZY/532phbEoBBzVmQ9zJJLJna7B
 p3CywgZRGLCzzld5V6gpZSmjFGRBNJJdv8GRUQJxkXO+3WOrmuwqZjzYe8dlJdhs9BZQHQ6
 /6/1z8m1yJ8wQjegFZa2eGIGi6dNmXOLJFjU6RpMpH9PyGoToBJ82Ba6nm06VDQqst9VEVd
 L1qzPtrWwgbPwLwbtRGlQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:DzOWhN6IYm8=:ohg0RsgVJSghWQ8p2h+H6l
 deZaNAUUq0xu5m9D6bNCQ7fZZSouKvuOUQhRhSdL0CkiVpdkWKawn9WRjZo1W5SS9VlKZ3SVG
 +llMfQCGkqN2qRq47PWiswPJ/+HLaOMQrZ+41BJQX8ZLMEO34obFwunsVfPha/QzGfNIuEyX8
 U+sKa1wvh/r3kEYxzsetSRvbqRKdg/CtL8+2n713DmyCFQzSD9CUwiEV+JcM6eHyltvYQ9Bwv
 jBHBOfckmei4k+Eb6S/Tox0ogHYbfouSl15jkxCrbVwE18De8AUoWrGQGR3Y23REKaOiXMQzN
 RnuxDaRU4+OZaaESGUZ7JpkuvqBYOR2H2XtibTwO4Xq/FSE2XIS7YMKh/ekf4piHQFAQsgehu
 5U9PjTXLz9OogxaENf7IENRGefOJbmdFjw27Ol4yy1fGSuABxIh0inAdReuCVt7V9asEt1IFz
 IfbLzpGP7hDvpGZZJMmdkhMwxVLGa5vt7leRlhfdNskxwVIxrIIv+jSJJJcahWtPVHIA9AdQE
 ZCDCaqTSX2PTsF51qA9RrYIrGbjaIUxzu8EFAWCywNoG5wXjrxhfLQ9FjlkhNMccVdI/jNbMP
 c8JjIM46+n2EbwLyZB2qihspj5Pd4SZaTCo/dfunXCz8ESdObrhEjJ/m12i8EX2mJvBVLVfEy
 Or8Y0dS2TuEpekfz2sZQJOIzufUnxtTNeHKVDGPCZTEIgAXkPLZYR/PgQxQldZEWfptyK0btp
 OWllfKMqMun0AhH2KIbbUZ6xLTxsgqZ9LDqDaCS1EEu7W1D4ZD5n7035IEqesVzUg/ZZrV+4k
 2G1gk2Q

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

Send a report that this bug log contains spam.