Debian Bug report logs - #832687
support uefi

Reply or subscribe to this bug.

Display info messages

Message #5 received at [email protected] (full text, mbox, reply):

From: Raphaël Hertzog <[email protected]>

To: Debian Bug Tracking System <[email protected]>

Subject: live-build: UEFI boot support

Date: Mon, 18 Nov 2013 10:19:12 +0100

Package: live-build
Version: 3.0.5-1
Severity: wishlist

I would like to be able to boot live images using UEFI instead of the
traditional BIOS. I know that syslinux 6 somehow supports EFI boot but
the documentation is rather short and I'm not sure what this involves.

I'd like to help make this happen and if someone can provide some guidance
it might happen quickly. If I have to discover everything by myself, it
might take some time.
 
I just found some introductory document that might be useful:
http://www.rodsbooks.com/efi-bootloaders/index.html

Cheers,
 Raphaël.

Message #10 received at [email protected] (full text, mbox, reply):

From: Daniel Baumann <[email protected]>

To: [email protected]

Subject: Re: Bug#729844: live-build: UEFI boot support

Date: Mon, 18 Nov 2013 10:41:35 +0100

retitle 729844 support for syslinux-efi
thanks

On 11/18/2013 10:19 AM, Raphaël Hertzog wrote:
> I would like to be able to boot live images using UEFI instead of the
> traditional BIOS.

it needs finalized debianization of syslinux 6 first, which will have to
go through NEW (again; after passing NEW for years it was now rejected
because of its embedded gpxe that has not/never been in
debian/copyright. as that is a major task to go through >>800 files
manually, i have no ETA for this). after that, support for it can be
added in live-build which is trivial.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          [email protected]
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #17 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Daniel Baumann <[email protected]>

Cc: [email protected]

Subject: Re: Bug#729844: live-build: UEFI boot support

Date: Tue, 19 Nov 2013 14:52:50 +0100

Hi,

Please keep the submitter in CC, I wasn't aware of your reply.

On Mon, 18 Nov 2013, Daniel Baumann wrote:
> it needs finalized debianization of syslinux 6 first, which will have to
> go through NEW (again; after passing NEW for years it was now rejected
> because of its embedded gpxe that has not/never been in
> debian/copyright. as that is a major task to go through >>800 files
> manually, i have no ETA for this). after that, support for it can be
> added in live-build which is trivial.

Can you point me to your updated syslinux package (either git repository
or .dsc) so that I can help you to update debian/copyright?

In the mean time, please push in a topic branch whatever you already
have in terms of live-build support. We should be able to test it
with the current syslinux in experimental, no? Otherwise we should
be able to test with the updaded syslinux package that you'll
point us to.

Thank you in advance.
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Message #22 received at [email protected] (full text, mbox, reply):

From: Daniel Baumann <[email protected]>

To: Raphael Hertzog <[email protected]>

Cc: [email protected]

Subject: Re: Bug#729844: live-build: UEFI boot support

Date: Tue, 19 Nov 2013 15:00:26 +0100

On 11/19/2013 02:52 PM, Raphael Hertzog wrote:
> Can you point me to your updated syslinux package (either git repository
> or .dsc) so that I can help you to update debian/copyright?

there's a vcs field in debian/control.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          [email protected]
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #27 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Daniel Baumann <[email protected]>

Cc: [email protected]

Subject: Re: Bug#729844: live-build: UEFI boot support

Date: Thu, 28 Nov 2013 20:54:48 +0100

[Message part 1 (text/plain, inline)]

Hello,

On Mon, 18 Nov 2013, Daniel Baumann wrote:
> it needs finalized debianization of syslinux 6 first, which will have to
> go through NEW (again; after passing NEW for years it was now rejected
> because of its embedded gpxe that has not/never been in
> debian/copyright. as that is a major task to go through >>800 files
> manually, i have no ETA for this).

Please find attached a patch documenting the missing licenses. I discussed
with Paul Tagliamonte who rejected your syslinux upload and he explained
that nowadays he would accept the package but file an RC bug to get the
copyright file fixed.

I believe that with this patch, your package should be safe to go through
NEW anyway. Let's go ahead and make some progress.

(BTW the switch to syslinux 6 should happen sooner rather than later, i.e.
well before the jessie freeze, let's not redo the same mistake than last
time.)

Cheers,

PS: This mail concerns syslinux and not live-build obviously, but since
the discussion started here, I send it here. If you can't merge it
quickly, and would prefer a dedicated bug against syslinux, let me know.
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

[0001-Update-debian-copyright-to-mention-all-missing-licen.patch (text/x-diff, attachment)]

Message #32 received at [email protected] (full text, mbox, reply):

From: Daniel Baumann <[email protected]>

To: Raphael Hertzog <[email protected]>

Cc: [email protected]

Subject: Re: Bug#729844: live-build: UEFI boot support

Date: Sun, 08 Dec 2013 20:40:20 +0100

reassign 729844 syslinux
retitle 729844 make debian/copyright complete
thanks

On 11/28/2013 08:54 PM, Raphael Hertzog wrote:
> Please find attached a patch documenting the missing licenses.

thanks, but i don't think that this is an acceptable debian/copyright
missing the individual File:/Copyright:/License: stanzas.

> I believe that with this patch, your package should be safe to go through
> NEW anyway.

did an ftp-master comment on your patch?

> BTW the switch to syslinux 6 should happen sooner rather than later, i.e.
> well before the jessie freeze, let's not redo the same mistake than last
> time.

there was no 'mistake' the 'last time', except that syslinux 5 for
jessie shoudn't have gone to unstable while wheezy was frozen.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          [email protected]
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #43 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Daniel Baumann <[email protected]>

Cc: [email protected]

Subject: Re: Bug#729844: live-build: UEFI boot support

Date: Sun, 8 Dec 2013 21:26:31 +0100

Control: clone 729844 -1
Control: reassign -1 live-build
Control: retitle -1 live-build: UEFI boot support

On Sun, 08 Dec 2013, Daniel Baumann wrote:
> reassign 729844 syslinux
> retitle 729844 make debian/copyright complete

Sorry, I'd like to keep a bug on live-build to track the progress of the
UEFI support.

> thanks, but i don't think that this is an acceptable debian/copyright
> missing the individual File:/Copyright:/License: stanzas.
[...] 
> did an ftp-master comment on your patch?

Yes, I showed it to Paul Tagliamonte who rejected your package:

<buxy> paultag: would something like that do it?  http://paste.debian.net/68270/
<paultag> buxy: that looks like a massive improvement in syntax, though
<paultag> huge, like, awesome.
<paultag> even though DEP5 advocates wouldn't like it, it's really perfectly fine 
in terms of policy

So it's perfectly acceptable for ftp-masters. And you seemed to be annoyed
by this busy-work so I helped you. I hope you won't require more than what
ftpmasters do require. :-)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Message #56 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: [email protected]

Subject: Preliminary patch for EFI boot support in live-build

Date: Fri, 28 Mar 2014 23:00:54 +0100

[Message part 1 (text/plain, inline)]

Hello,

I worked on EFI boot support for Kali's live+installer image and
this resulted in the attached patch for live-build 3.0.5.

Some comments:

* The patch can't be used as-is because it assumes that syslinux 6
  is packaged like syslinux 4 in wheezy (eg almost everything in syslinux-common).
  See http://git.kali.org/gitweb/?p=packages/syslinux.git;a=shortlog;h=refs/heads/master
  for the version that Kali is using currently.

* The change to binary_iso is inspired by the EFI support in debian-cd.

* Syslinux EFI support needs the kernel/initrd in the EFI FAT partition.
  So those files are duplicated, once in the ISO filesystem, once in the
  embedded FAT filesystem (boot/efi.img). With xorriso of wheezy, it's
  even worse as boot/efi.img is also duplicated as a separate partition.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

[add-efi-support.patch (text/x-diff, attachment)]

Message #61 received at [email protected] (full text, mbox, reply):

From: Daniel Baumann <[email protected]>

To: Raphael Hertzog <[email protected]>

Cc: [email protected]

Subject: Re: Bug#731709: Preliminary patch for EFI boot support in live-build

Date: Sat, 29 Mar 2014 14:02:41 +0100

On 03/28/2014 11:00 PM, Raphael Hertzog wrote:
> I worked on EFI boot support for Kali's live+installer image and
> this resulted in the attached patch for live-build 3.0.5.

thanks. however, i'm not in favour of merging that for following reasons:

  * it's against 3.x instead of 4.x
  * syslinux is not in the final layout yet.
  * i don't like a few defaults/filenames/etc and need to familiarize
    myself and think again about some internals first before being able
    to give concrete 'specifications' for a binary-syslinux-efi lb
    command if someone else does it (or do it myself).
  * right now i'd perfere not merge patches introducing other copyright
    holders. that probably changes in ~october this year though.

-- 
Address:        Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email:          [email protected]
Internet:       http://people.progress-technologies.net/~daniel.baumann/

Message #66 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: Preliminary patch for EFI boot support in live-build

Date: Mon, 31 Mar 2014 23:04:31 +0200

Hi,

thank you for flying xorriso.

I already asked at debian-cd why the option -isohybrid-apm-hfsplus
is used with a boot image that contains a FAT filesystem.
The option advertises the FAT in an Apple Partition Map as HFS+
partition.
It is rather intended to advertise a HFS+ image for booting Macs
according to  http://mjg59.dreamwidth.org/11285.html .

So my question here too:
Is there any system known which would demand the EFI image to be
presented in an Apple Partition Map as HFS+ ?

If this is just a copy from debian-cd without particular reason,
then please consider to omit -isohybrid-apm-hfsplus and to watch
out for some user who would really need it.
In this case i am willing to develop a xorrisofs option which is
more appropriate for FAT in APM.
But actually i doubt that this is ever needed.


Further:
Be warned that xorriso-1.2.4 to xorriso-1.2.8 produced a wrong CRC
in the GPT header. See Debian bug 740504.
It seems not to hamper bootability but keeps partition editors
from working on the partition map.
Current release is:
  http://www.gnu.org/software/xorriso/xorriso-1.3.6.pl01.tar.gz


(Please Cc: me with replies. Somehow bug subscription does not
 work for me.)

Have a nice day :)

Thomas

Message #71 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Thomas Schmitt <[email protected]>

Cc: [email protected]

Subject: Re: Preliminary patch for EFI boot support in live-build

Date: Tue, 1 Apr 2014 00:10:03 +0200

On Mon, 31 Mar 2014, Thomas Schmitt wrote:
> It is rather intended to advertise a HFS+ image for booting Macs
> according to  http://mjg59.dreamwidth.org/11285.html .
> 
> So my question here too:
> Is there any system known which would demand the EFI image to be
> presented in an Apple Partition Map as HFS+ ?
> 
> If this is just a copy from debian-cd without particular reason,
> then please consider to omit -isohybrid-apm-hfsplus and to watch
> out for some user who would really need it.

Yes, it's really a copy of the debian-cd logic. I'll try without that
option.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Message #76 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Daniel Baumann <[email protected]>

Cc: [email protected]

Subject: Re: Bug#731709: Preliminary patch for EFI boot support in live-build

Date: Wed, 10 Dec 2014 01:26:29 +0100

[Message part 1 (text/plain, inline)]

Control: tag -1 patch

On Sat, 29 Mar 2014, Daniel Baumann wrote:
> On 03/28/2014 11:00 PM, Raphael Hertzog wrote:
> > I worked on EFI boot support for Kali's live+installer image and
> > this resulted in the attached patch for live-build 3.0.5.
> 
> thanks. however, i'm not in favour of merging that for following reasons:
> 
>   * it's against 3.x instead of 4.x
>   * syslinux is not in the final layout yet.

Both those points are addressed in the updated patch attached.

Note that we disabled a test on the xorriso version in use (in binary_iso)
as we had better results with the old method in use before xorriso gained
knowledge of registering the EFI image as an alternate eltorrito boot
record.

>   * i don't like a few defaults/filenames/etc and need to familiarize
>     myself and think again about some internals first before being able
>     to give concrete 'specifications' for a binary-syslinux-efi lb
>     command if someone else does it (or do it myself).
>   * right now i'd perfere not merge patches introducing other copyright
>     holders. that probably changes in ~october this year though.

On this there's nothing that I can do though.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

[0002-Add-support-for-EFI-boot-with-syslinux-efi.patch (text/x-diff, attachment)]

Message #83 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: Bug#731709: Preliminary patch for EFI boot support in live-build

Date: Wed, 10 Dec 2014 09:18:46 +0100

Hi,

Raphaël Hertzog wrote:
> Note that we disabled a test on the xorriso version in use (in binary_iso)
> as we had better results with the old method in use before xorriso gained
> knowledge of registering the EFI image as an alternate eltorrito boot
> record.

Please give me more details about this issue.

How was the result from older xorriso better than from
the newer one ?

Which particular version produced better, which version
produced the worse image ?

Are there ISO images from both versions available for
inspection ?


Have a nice day :)

Thomas

Message #88 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: Thomas Schmitt <[email protected]>

Cc: [email protected]

Subject: Re: Bug#731709: Preliminary patch for EFI boot support in live-build

Date: Wed, 10 Dec 2014 09:39:09 +0100

Hi,

On Wed, 10 Dec 2014, Thomas Schmitt wrote:
> How was the result from older xorriso better than from
> the newer one ?
> 
> Which particular version produced better, which version
> produced the worse image ?

It's not about a particular version of xorriso, but about the set of
command-line options that we use depending on the xorriso version:

+       #if [ "$XORRISO_VER" -le 10202 ]; then
+               # 1.2.2 shipping in wheezy
+               Echo "Using older EFI command line for xorriso $XORRISO_VER"
+               # Tell xorriso to create a secondary ElTorito boot record for the
+               # EFI bootloader
+               XORRISO_OPTIONS="${XORRISO_OPTIONS} -eltorito-alt-boot --efi-boot boot/efi.img"
+               # Add the efi image as a FAT partition too, so our CD image will
+               # also boot on a USB key (like isohybrid, just implemented
+               # differently)
+               XORRISO_OPTIONS="${XORRISO_OPTIONS} -append_partition 2 0x01 binary/boot/efi.img"
+       #else
+       #       Echo "Using newer EFI support in xorriso $XORRISO_VER"
+       #       XORRISO_OPTIONS="${XORRISO_OPTIONS} -eltorito-alt-boot -e boot/efi.img -no-emul-boot"
+       #       XORRISO_OPTIONS="${XORRISO_OPTIONS} -isohybrid-gpt-basdat"
+       #fi

In our tests, there are more computers where EFI boot works (from an USB key) when we use
"-eltorito-alt-boot --efi-boot boot/efi.img -append_partition 2 0x01 binary/boot/efi.img"
compared to when we use "-eltorito-alt-boot -e boot/efi.img -isohybrid-gpt-basdat".
In particular a number of macbook.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Message #93 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: Bug#731709: Preliminary patch for EFI boot support in live-build

Date: Wed, 10 Dec 2014 12:02:58 +0100

Hi,

> It's not about a particular version of xorriso, but about the set of
> command-line options that we use depending on the xorriso version

No regression then. :)

Were the problems with CD/DVD or with USB sticks ?


> In our tests, there are more computers where EFI boot works (from an USB
> key) when we use
> "-eltorito-alt-boot --efi-boot boot/efi.img -append_partition 2 0x01
> binary/boot/efi.img"
> compared to when we use "-eltorito-alt-boot -e boot/efi.img
> -isohybrid-gpt-basdat".
> In particular a number of macbook.

The novelty is in the existence of GPT, which might confuse the
firmware by its nested partitions.
Further the ___location and partition type of MBR partition 2 differs.
The new type is 0xef and partition 2 is inside partition 2.

GRUB2's grub-mkrescue lets xorriso write strictly disjoint
partition tables. But the ISOLINUX/GRUB2 mix according to Matthew
Garrett's http://mjg59.dreamwidth.org/11285.html prescribes the
FAT (for EFI) and HFS+ (for "some" Macs) partitions to sit inside
the ISO image.  Thus their partitions sit inside partition 1,
which claims the whole ISO and is mountable.
(Note: debian-cd does not include a HFS+ filesystem.)
GRUB2 grub-mkrescue produces no mountable ISO partition. One
has to mount the base device, which is unusual with USB sticks.

It would be interesting to learn whether the Mac firmwares take
offense from the existence of GPT, from the MBR partition type 0xef,
or from partition nesting.

There are known but diffuse problems with Macs and BIOS+EFI
capable ISOs. Ubuntu offers BIOS-only images for EFI Macs.
See Colin Watson's answer to
  http://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image


Experiment proposals for those who have a vulnerable Mac at hand:

- Remove GPT from a "worse" ISO:
    iso="....iso"
    backup_gpt=$(expr $(isosize "$iso") / 512 - 1)
    dd of="$iso" conv=notrunc if=/dev/zero bs=512 seek=1 count=63
    dd of="$iso" conv=notrunc if=/dev/zero bs=512 seek=$backup_gpt count=1

  Does it boot now ?

- Change the type of MBR partition 2 in a "better" ISO.
  Since the partitions are disjoint and only an MBR is present,
  program fdisk should do.
  Alternatively write byte 0xef = 0357 at position 466:
    echo $'\357' | dd of="$iso" bs=1 conv=notrunc seek=466 count=1

  Does the image get unbootable by this ?
  To verify proper manipulation: Does it get bootable again by
    echo $'\001' | dd of="$iso" bs=1 conv=notrunc seek=466 count=1

- In a "better" ISO's MBR move the end of partition 1 after the end
  of partition 2.
  I could not find a command in fdisk which would do that. So one
  would have to learn start and size of partition 2 by e.g. fdisk,
  compute a new end block address after partition 2, and write
  the result as little-endian 32-bit number into bytes 458 to 461
  of the ISO.
  If there is interest in this test, i could write a little C
  program which does this.

  Does the image get unbootable by this ?
  To verify proper manipulation: Does it get bootable again by
  writing the old end address into partition slot 1 ?

 
Have a nice day :)

Thomas
 

Message #98 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: Bug#731709: Preliminary patch for EFI boot support in live-build

Date: Wed, 10 Dec 2014 12:10:01 +0100

Hi,

Raphael Hertzog:
> > EFI boot [...] (from an USB key)
me:
> Were the problems with CD/DVD or with USB sticks ?

Please ignore this obsolete question of mine.


Have a nice day :)

Thomas

Message #103 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: [email protected]

Subject: Updated EFI patch

Date: Thu, 11 Dec 2014 10:58:27 +0100

[Message part 1 (text/plain, inline)]

Attached is an updated patch that works on top of 4.0.4 (change needed
to replace LIVE_IMAGE_ARCHITECTURE with LB_ARCHITECTURES).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

[Add-support-for-EFI-boot-with-syslinux-efi.patch (text/x-diff, attachment)]

Message #108 received at [email protected] (full text, mbox, reply):

From: jnqnfe <[email protected]>

To: [email protected]

Cc: [email protected]

Subject: Re: Updated EFI patch

Date: Sat, 10 Jan 2015 20:44:54 +0000

In regards to the point in the binary build stage sequence at which your
new code executes the efi script, and the below quoted comment besides
it, I'm curious about what exactly you are worried about that prompted it?

"After includes/hooks because it copies in efi.img files that can be
overriden by binary_includes and modified by binary_hooks"

Do you have examples of existing hooks/includes which actually clash
with the new files? Or are you simply worried about a user adding an
include/hook which overwrites/deletes a file and thus breaks their image?

If the latter, then I really don't agree that it's an issue. The
includes and hooks scripts are there to allow last minute customisations
before compiling the image, and if a user foolishly misuses them to
break their image, then that's on them.

Message #113 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: jnqnfe <[email protected]>

Cc: [email protected]

Subject: Re: Updated EFI patch

Date: Sun, 11 Jan 2015 08:33:28 +0100

Hi,

On Sat, 10 Jan 2015, jnqnfe wrote:
> "After includes/hooks because it copies in efi.img files that can be
> overriden by binary_includes and modified by binary_hooks"
> 
> Do you have examples of existing hooks/includes which actually clash
> with the new files?

In Kali we use both of those features to modify the syslinux
configuration & related data (background image). If binary_efi copies the
syslinux configuration & data before those scripts have run, the EFI boot
menu doesn't have the correct content/look.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Message #118 received at [email protected] (full text, mbox, reply):

From: jnqnfe <[email protected]>

To: Raphael Hertzog <[email protected]>, [email protected]

Subject: Re: Bug#731709: Updated EFI patch

Date: Sun, 11 Jan 2015 17:02:12 +0000

What about the local config support provided? I.e placing a custom copy
of the default syslinux config files into config/bootloaders/${_BOOTLOADER}.

Were you aware that this functionality existed? Is it sufficient for
your needs, or if not, how specifically is it not?

I would like to help build UEFI support into LB, and I want to help
ensure that bootloader code supports needs such as this.

On 11/01/2015 07:33, Raphael Hertzog wrote:
> Hi,
>
> On Sat, 10 Jan 2015, jnqnfe wrote:
>> "After includes/hooks because it copies in efi.img files that can be
>> overriden by binary_includes and modified by binary_hooks"
>>
>> Do you have examples of existing hooks/includes which actually clash
>> with the new files?
> In Kali we use both of those features to modify the syslinux
> configuration & related data (background image). If binary_efi copies the
> syslinux configuration & data before those scripts have run, the EFI boot
> menu doesn't have the correct content/look.
>
> Cheers,

Message #123 received at [email protected] (full text, mbox, reply):

From: Raphael Hertzog <[email protected]>

To: jnqnfe <[email protected]>

Cc: [email protected]

Subject: Re: Bug#731709: Updated EFI patch

Date: Sun, 11 Jan 2015 20:33:43 +0100

On Sun, 11 Jan 2015, jnqnfe wrote:
> What about the local config support provided? I.e placing a custom copy
> of the default syslinux config files into config/bootloaders/${_BOOTLOADER}.
> 
> Were you aware that this functionality existed? Is it sufficient for
> your needs, or if not, how specifically is it not?

Yes, I knew about this but we prefer to not fork the whole configuration
and just apply our small changes and stay close to the standard Debian
syslinux config.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Message #128 received at [email protected] (full text, mbox, reply):

From: Gaudenz Steinlin <[email protected]>

To: [email protected]

Subject: EFI support for ISO images

Date: Fri, 21 Aug 2015 11:52:22 +0200

[Message part 1 (text/plain, inline)]

Hi

At Lernstick we use the patch attached to create ISO images which boot
on EFI systems. This does not include adding a EFI bootloader to the
image. We do that with config/includes.binary which is of course not a
complete solution.

The debian-cd folks (Steve McIntyre) did a lot of testing to find the
right combination of xorriso options to create an image which boots on
most EFI hardware. Because there are lots of broken implementations out
there.

The patch also adds a dependency on xorriso.

Gaudenz

[efi_iso.patch (text/x-diff, inline)]

commit c048047fb581e407db6059bd7de48b36f49a1baf
Author: Gaudenz Steinlin <[email protected]>
Date:   Wed Apr 30 10:50:39 2014 +0200

    Option to include an EFI image into ISO images
    
    --efi-boot option to include an EFI boot image as an alternative El
    Torrito boot image into the ISO image. This is necessary for booting an
    ISO image on most EFI implementations. Booting the ISO image also works
    from USB devices when writeing the image directly to the device. The EFI
    boot files must be present in binary/efi/boot already. Use a binary hook
    or include to copy the files to this directory.
    
    This code is an adaption of similar code present in debian-cd.

diff --git a/functions/defaults.sh b/functions/defaults.sh
index a1040d7..5b93698 100755
--- a/functions/defaults.sh
+++ b/functions/defaults.sh
@@ -700,6 +700,9 @@ Set_defaults ()
 		esac
 	fi
 
+	# Setting efi boot
+	LB_EFI_BOOT="${LB_EFI_BOOT:-false}"
+
 	# Setting checksums
 	case "${LB_MODE}" in
 		progress-linux)
diff --git a/manpages/en/lb_config.1 b/manpages/en/lb_config.1
index 4ef252a..2a6557a 100644
--- a/manpages/en/lb_config.1
+++ b/manpages/en/lb_config.1
@@ -41,6 +41,8 @@
 .br
 	[\fB\-\-bootloader\fR grub|grub2|syslinux]
 .br
+	[\fB\-\-efi\-boot\fR true|false]
+.br
 	[\fB\-\-cache\fR true|false]
 .br
 	[\fB\-\-cache\-indices\fR true|false]
@@ -265,6 +267,8 @@ sets boot parameters specific to debian\-installer, if included.
 sets boot parameters specific to debian\-live. A complete list of boot parameters can be found in the \fIlive\-boot\fR(7) and \fIlive\-config\fR(7) manual pages.
 .IP "\fB\-\-bootloader\fR grub|grub2|syslinux" 4
 defines which bootloader is being used in the generated image. This has only an effect if the selected binary image type does allow to choose the bootloader. For example, if you build a iso, always syslinux (or more precise, isolinux) is being used. Also note that some combinations of binary images types and bootloaders may be possible but live\-build does not support them yet. \fBlb config\fR will fail to create such a not yet supported configuration and give a explanation about it. For hdd images on amd64 and i386, the default is syslinux.
+.IP "\fB\-\-efi\-boot\fR true|false" 4
+control if an EFI boot image should be included as an alternate El Torrito image. This is necessary for booting an ISO image under EFI on most implementations. Booting the ISO image also works from USB devices when writeing the image directly to the device. The EFI boot files must be present in binary/efi/boot already. Use a binary hook or include to copy the files to this directory.
 .IP "\fB\-\-cache\fR true|false" 4
 defines globally if any cache should be used at all. Different caches can be controlled through the their own options.
 .IP "\fB\-\-cache\-indices\fR true|false" 4
diff --git a/scripts/build/binary_iso b/scripts/build/binary_iso
index 44a9418..0b0d5db 100755
--- a/scripts/build/binary_iso
+++ b/scripts/build/binary_iso
@@ -144,6 +144,30 @@ case "${LB_BOOTLOADER}" in
 		;;
 esac
 
+if [ "${LB_EFI_BOOT}" = "true" ]
+then
+	XORRISO_VER=$(xorriso --version 2>&1 | awk '
+			/^xorriso version/ {
+				split($4, ver, ".")
+				print ver[1]*10000+ver[2]*100+ver[3]
+			}')
+	# Ugh - different code here depending on the version of xorriso we've got
+	if [ $XORRISO_VER -le 10202 ] ; then
+		# 1.2.2 shipping in Wheezy
+		# Tell xorriso to create a secondary ElTorito boot record for the
+		# EFI bootloader
+		XORRISO_OPTIONS="${XORRISO_OPTIONS} -eltorito-alt-boot --efi-boot efi.img"
+		# Add the efi image as a FAT partition too, so our CD image will
+		# also boot on a USB key (like isohybrid, just implemented
+		# differently)
+		XORRISO_OPTIONS="${XORRISO_OPTIONS} -append_partition 2 0x01 binary/efi.img"
+
+	elif [ $XORRISO_VER -gt 10202 ] ; then
+		XORRISO_OPTIONS="${XORRISO_OPTIONS} -eltorito-alt-boot -e efi.img -no-emul-boot"
+		XORRISO_OPTIONS="${XORRISO_OPTIONS} -isohybrid-gpt-basdat -isohybrid-apm-hfsplus"
+	fi
+fi
+
 #if [ "${LB_DEBIAN_INSTALLER}" != "live" ]
 #then
 #	XORRISO_OPTIONS="${XORRISO_OPTIONS} -m ${XORRISO_EXCLUDE}"
@@ -181,6 +205,34 @@ else
 	echo "#!/bin/sh" > binary.sh
 fi
 
+if [ "${LB_EFI_BOOT}" = "true" ]
+then
+# The code below is adapted from tools/boot/jessie/boot-x86
+# in debian-cd
+
+# Stuff the EFI boot files into a FAT filesystem, making it as
+# small as possible.  24KiB headroom seems to be enough;
+# (x+31)/32*32 rounds up to multiple of 32.
+
+cat >> binary.sh << EOF
+
+efi_img="binary/efi.img"
+
+size=0
+for file in binary/efi/boot/*; do
+	size=\$((\$size + \$(stat -c %s "\$file")))
+done
+
+blocks=\$(((\$size / 1024 + 55) / 32 * 32 ))
+
+mkfs.msdos -C "\$efi_img" \$blocks >/dev/null
+mmd -i "\$efi_img" ::efi
+mmd -i "\$efi_img" ::efi/boot
+mcopy -i "\$efi_img" binary/efi/boot/* "::efi/boot"
+
+EOF
+fi
+
 cat >> binary.sh << EOF
 
 xorriso -as mkisofs ${XORRISO_OPTIONS} -o ${IMAGE} binary
diff --git a/scripts/build/config b/scripts/build/config
index 77f4029..2a7eaaf 100755
--- a/scripts/build/config
+++ b/scripts/build/config
@@ -33,6 +33,7 @@ USAGE="${PROGRAM}   [--apt apt|aptitude]\n\
 \t    [--bootappend-live PARAMETER|\"PARAMETERS\"]\n\
 \t    [--bootappend-live-failsafe PARAMETER|\"PARAMETERS\"]\n\
 \t    [--bootloader grub|grub2|syslinux]\n\
+\t    [--efi-boot true|false]\n\
 \t    [--cache true|false]\n\
 \t    [--cache-indices true|false]\n\
 \t    [--cache-packages true|false]\n\
@@ -138,7 +139,7 @@ Local_arguments ()
 		archive-areas:,parent-archive-areas:,chroot-filesystem:,
 		gzip-options:,image-name:,interactive:,keyring-packages:,linux-flavours:,linux-packages:,
 		security:,updates:,backports:,binary-filesystem:,binary-images:,
-		apt-indices:,bootappend-install:,bootappend-live:,bootappend-live-failsafe:,bootloader:,checksums:,compression:,config:,zsync:,build-with-chroot:,
+		apt-indices:,bootappend-install:,bootappend-live:,bootappend-live-failsafe:,bootloader:,efi-boot:,checksums:,compression:,config:,zsync:,build-with-chroot:,
 		debian-installer:,debian-installer-distribution:,debian-installer-preseedfile:,debian-installer-gui:,
 		grub-splash:,isohybrid-options:,hdd-label:,hdd-size:,iso-application:,iso-preparer:,iso-publisher:,
 		iso-volume:,jffs2-eraseblock:,memtest:,net-root-filesystem:,net-root-mountoptions:,
@@ -502,6 +503,11 @@ Local_arguments ()
 				shift 2
 				;;
 
+			--efi-boot)
+				LB_EFI_BOOT="${2}"
+				shift 2
+				;;
+
 			--checksums)
 				LB_CHECKSUMS="${2}"
 				shift 2
@@ -1163,6 +1169,10 @@ LB_BOOTAPPEND_LIVE_FAILSAFE="${LB_BOOTAPPEND_LIVE_FAILSAFE}"
 # (Default: ${LB_BOOTLOADER})
 LB_BOOTLOADER="${LB_BOOTLOADER}"
 
+# \$LB_EFI_BOOT: control if an EFI boot image should be included as an alternate El Torrito image
+# (Default: ${LB_EFI_BOOT})
+LB_EFI_BOOT="${LB_EFI_BOOT}"
+
 # \$LB_CHECKSUMS: set checksums
 # (Default: ${LB_CHECKSUMS})
 LB_CHECKSUMS="${LB_CHECKSUMS}"

[signature.asc (application/pgp-signature, inline)]

Message #133 received at [email protected] (full text, mbox, reply):

From: Has <[email protected]>

To: [email protected]

Subject: Status of 731709

Date: Tue, 22 Sep 2015 12:47:17 -0400

[Message part 1 (text/plain, inline)]

What's the status of this bug?

>Attached is an updated patch that works on top of 4.0.4

jessie live-build is at version 4.0.3, stretch is at 5.0. Does this patch
work in stretch? I'm hoping I can patch 5.0 and backport it to jessie as
this is a very important feature.

[Message part 2 (text/html, inline)]

Message #138 received at [email protected] (full text, mbox, reply):

From: Michal Suchanek <[email protected]>

To: Has <[email protected]>, [email protected]

Subject: Re: Bug#731709: Status of 731709

Date: Tue, 22 Sep 2015 20:58:32 +0200

Hello,

On 22 September 2015 at 18:47, Has <[email protected]> wrote:
> What's the status of this bug?
>
>>Attached is an updated patch that works on top of 4.0.4
>
> jessie live-build is at version 4.0.3, stretch is at 5.0. Does this patch
> work in stretch? I'm hoping I can patch 5.0 and backport it to jessie as
> this is a very important feature.

1) this patch is not complete

It should pull a bootloader from Debian packages and not depend on the
user adding it as binary include.

2) while includeing the EFI bootloader should make the image EFI
bootable it is not obvious

 - if the image is also BIOS bootable (possibly but not explicitly stated)
 - if the EFI method also works with HDD images with no ISO filesystem
 - what partitions the image includes and if rearranging the
partitions eg to add a data partition as the first entry affects
bootability (currently state of the art bootable USB stick with
Windows-compatible data storage is created by moving the partition
entry for Debian Live partition to second position and creating a data
partition at the first position in MBR using the unallocated space at
the end of the medium)

Thanks

Michal

Message #143 received at [email protected] (full text, mbox, reply):

From: Has <[email protected]>

To: [email protected]

Subject: Patch status

Date: Tue, 22 Sep 2015 16:14:36 -0400

[Message part 1 (text/plain, inline)]

I'm sorry for not quoting properly, to be clear I'm asking if either R.
Herzog's patch in Message #103 or in Message #76 will work with jessie's
version of live-build.

[Message part 2 (text/html, inline)]

Message #148 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Raphael Hertzog <[email protected]>, [email protected]

Subject: Re: Bug#731709: Updated EFI patch

Date: Sat, 16 Jan 2016 18:55:30 +0100

[Message part 1 (text/plain, inline)]

I attach a patch based on your work (which I have not tested so feedback 
is welcome).

You can find the specific modifications to your original commit/patch 
(which I had to cherry-pick) on branch:

https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd

Now I'm going to work on grub-efi support based on debian-cd / Lernstick 
work so that we can probably have also Secure Boot by default.

So, to make it clear, after my changes you would need to add or modify 
live config parametres to have:

--bootloaders="syslinux,syslinux-efi"

in order for it to work.



Do not expect me not to improve this patch even more because I'm going 
to add 'grub-efi' which it's going to be based on debian-cd. And that 
means some conflicts in the way of doing the final ISO.

And, well, then the final idea is to have the syslinux-efi as a backup 
method and the grub-efi would be the default one. I will make an 
specific commit for it.


So, yes, feedback is welcome for this patch and for my other ideas.


El 11/12/14 a las 10:58, Raphael Hertzog escribió:
> Attached is an updated patch that works on top of 4.0.4 (change needed
> to replace LIVE_IMAGE_ARCHITECTURE with LB_ARCHITECTURES).
>
> Cheers,
>

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

[syslinux-efi-support-2016.patch (text/x-patch, attachment)]

Message #153 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: [email protected]

Subject: grub-efi UEFI support based on debian-cd work complete

Date: Mon, 18 Jan 2016 05:04:31 +0100

[Message part 1 (text/plain, inline)]

These patches apply to current live-build master branch.

Each of one the patches have their own explanation based on a git commit.

Maybe I have missed to say that the grub-efi UEFI support which it's 
based on Debian-CD work not only supports to boot from UEFI 64 bit 
systems but also from UEFI 32 bit systems.

I have not tested myself if UEFI 32 bit boots or not but I don't know 
why it should not. Feedback is welcome.

As most email programs would show the attached text ready for you to 
quote I don't think I need to explain too much more about them.

The reason why I have up to 7 patches is because either each one of them 
focus in one task or I have thought you might want to use it or not 
(Well, it's mainly: 007-syslinux-grub-efi-default-bootloaders.diff which 
enforces every ISO to have UEFI support).

Finally loopback_cfg which renders grub.cfg shows us a blue raw grub 
menu which it's not fun but it's functional.

Maybe we could reuse some work from jnqnfe from #775322 but I'm not 
going to do that. Maybe in the future for using in Rescatux but not in 
the short term.

The other option is trying to reuse debian-cd or debian-installer 
scripts which let you translate syslinux configuration files into grub 
configuration files.

Feedback is welcome!

P.S.: I am going to release soon: Rescatux 0.40b3 which will be based on 
these commits so you will be able to see how it would perform the final 
product.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

[001-efi-image-and-grub-cpmodules.diff (text/plain, attachment)]

[002-lb-primary-bootloader-fix.diff (text/plain, attachment)]

[003-bootloaders-functions.diff (text/plain, attachment)]

[004-rewrite-bootloaders-to-use-new-functions.diff (text/plain, attachment)]

[005-binary_loopback_cfg_renders_grub_cfg.diff (text/plain, attachment)]

[006-uefi-support-based-on-grub-efi-and-debian-cd.diff (text/plain, attachment)]

[007-syslinux-grub-efi-default-bootloaders.diff (text/plain, attachment)]

Message #158 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: [email protected], Raphael Hertzog <[email protected]>

Subject: binary_syslinux-efi based on latest work on live-build master branch for grub-efi support

Date: Mon, 18 Jan 2016 05:10:59 +0100

[Message part 1 (text/plain, inline)]

So this is the patch from Raphael Hertzog that you all know but adapted 
to be used from my last work.

Unfortunately it does not seem to boot in my virtual machine test.

Raphael can you take a look at it just in case it's a minor problem?

I'm also interested in being able to make cdroms with syslinux-efi.

The quick and dirty branch where I worked on both grub-efi and 
syslinux-efi is here:

https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd

That branch is handy to understand the changes between Raphael's 
original patch and what I present here.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

[B-001-syslinux-efi-2016.diff (text/plain, attachment)]

Message #163 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: [email protected]

Cc: Raphael Hertzog <[email protected]>, jnqnfe <[email protected]>, Thomas Schmitt <[email protected]>, Gaudenz Steinlin <[email protected]>, Has <[email protected]>, Michal Suchanek <[email protected]>

Subject: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 18 Jan 2016 05:24:13 +0100

In my last message I forgot to CC many people who are involved in this 
bug so I'm going to refer to my former message, CC some people and 
finally point you to my repo/branches where you might find interesting 
commits.


1) My original message with attached patches (which you can download to 
your email program and reply from there) can be found at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#153


2) Repo / Branches:

* efi_support_based_on_debian_cd  ( 
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd 
) : Original dirty branch where I worked in both syslinux-efi and 
grub-efi bootloaders at the same time

* efi_support_based_on_debian_cd_rebased ( 
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased 
) : The same branch rebased to have minimal useful commits. syslinux-efi 
was removed from it because it did not boot.

* syslinux-efi-2016 ( 
https://github.com/adrian15/live-build/tree/syslinux-efi-2016 ) : This 
branch adds and enables the latest version of syslinux-efi (rebased) but 
it does not boot.


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #168 received at [email protected] (full text, mbox, reply):

From: Michal Suchanek <[email protected]>

To: adrian15 <[email protected]>

Cc: [email protected], Raphael Hertzog <[email protected]>, jnqnfe <[email protected]>, Thomas Schmitt <[email protected]>, Gaudenz Steinlin <[email protected]>, Has <[email protected]>

Subject: Re: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 18 Jan 2016 07:31:10 +0100

Hello,

thanks for working on this.

On 18 January 2016 at 05:24, adrian15 <[email protected]> wrote:
> In my last message I forgot to CC many people who are involved in this bug
> so I'm going to refer to my former message, CC some people and finally point
> you to my repo/branches where you might find interesting commits.
>
>
> 1) My original message with attached patches (which you can download to your
> email program and reply from there) can be found at:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#153
>
>
> 2) Repo / Branches:
>
> * efi_support_based_on_debian_cd  (
> https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd )
> : Original dirty branch where I worked in both syslinux-efi and grub-efi
> bootloaders at the same time
>
> * efi_support_based_on_debian_cd_rebased (
> https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased
> ) : The same branch rebased to have minimal useful commits. syslinux-efi was
> removed from it because it did not boot.

I have checked what EFI platforms I have and it seems neither would be
bootable with this.

1) a Windows tablet that needs signed bootloader - signed grub is
available as non-free package (because it cannot be modified to not
break the signature) and presumably allows booting on such systems
without going through the unlocking stuff which may break your windows
installation.

2) a mac mini which probably needs a GPT and the bootloader stored on
a HFS+ volume or something. Also the bootloader needs to be 'blessed'.
Command for that exists in grub and crashes. Never got this working on
an USB stick.

As to the primary and secondary bootloader - how is the efi bootloader
secondary? It boots the same as the legacy bootloader. You probably
want a concept of compatible bootloaders - that is pairs of
bootloaders that can be installed alongside on the same medium. Unless
the user requests two bootloaders that are incompatible the medium can
be created.

Ignoring bootloaders is not a good idea. If the user requested
something that is not possible the build should report an error and
stop.

Finally it seems that some of the patches reference grub-efi before
the patch that adds support for it. Support for grub-efi should
probably be added before it's referenced in other code (eg set as
default).

Thanks

Michal

Message #173 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: [email protected]

Cc: Michal Suchanek <[email protected]>, Raphael Hertzog <[email protected]>, jnqnfe <[email protected]>, Thomas Schmitt <[email protected]>, Gaudenz Steinlin <[email protected]>, Has <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 18 Jan 2016 10:43:44 +0100

El 18/01/16 a las 07:31, Michal Suchanek escribió:
> Hello,
>
> thanks for working on this.
>
> On 18 January 2016 at 05:24, adrian15 <[email protected]> wrote:
>> In my last message I forgot to CC many people who are involved in this bug
>> so I'm going to refer to my former message, CC some people and finally point
>> you to my repo/branches where you might find interesting commits.
>>
>>
>> 1) My original message with attached patches (which you can download to your
>> email program and reply from there) can be found at:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#153
>>
>>
>> 2) Repo / Branches:
>>
>> * efi_support_based_on_debian_cd  (
>> https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd )
>> : Original dirty branch where I worked in both syslinux-efi and grub-efi
>> bootloaders at the same time
>>
>> * efi_support_based_on_debian_cd_rebased (
>> https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased
>> ) : The same branch rebased to have minimal useful commits. syslinux-efi was
>> removed from it because it did not boot.
>
> I have checked what EFI platforms I have and it seems neither would be
> bootable with this.
>
> 1) a Windows tablet that needs signed bootloader - signed grub is
> available as non-free package (because it cannot be modified to not
> break the signature) and presumably allows booting on such systems
> without going through the unlocking stuff which may break your windows
> installation.
Yeah, that's the Microsoft Secure Boot. debian-cd people are working on 
bringing it into official Debian CDs. There is not a fixed date for that 
but everything points that it will be finished within 2016. Once they 
manage to do so I'll see how easy it is to port into this work.

You can always try virtual systems. This is how I currently test this:

kdesudo "kvm -bios /usr/share/ovmf/OVMF.fd -cdrom rescatux-0.40b3.iso 
-boot d -m 512"

.

> 2) a mac mini which probably needs a GPT and the bootloader stored on
> a HFS+ volume or something. Also the bootloader needs to be 'blessed'.
> Command for that exists in grub and crashes. Never got this working on
> an USB stick.
Well, I have not mentioned that this implementation (based on debian-cd 
team work) also would support intel based mac systems because it has an 
additional HFS+ volume.

I also have a mac book pro myself and the 'hybrid' version of Super 
Grub2 Disk 2.02s3 works for me (when using ALT key at boot). I don't 
remember having blessed it so... I'm unsure about the need (or not) to 
bless it.

So, the 'hybrid' Super Grub2 Disk 2.02s3 also has an additional HFS+ 
partition (as our current implementation here in these patches) put in 
place for mac book compatibility so I guess that this build will also 
boot in my system but I still need to test it.


> As to the primary and secondary bootloader - how is the efi bootloader
> secondary? It boots the same as the legacy bootloader. You probably
> want a concept of compatible bootloaders - that is pairs of
> bootloaders that can be installed alongside on the same medium.
* What is it a secondary bootloader?

It's what happens when you request mkisofs that your bootloader to be 
boot in second place or as a second partition. I don't know how it 
actually works.

So in grub-efi we just add to the xorriso options:

-eltorito-alt-boot \
 -e boot/grub/efi.img \
 -no-emul-boot \
 -isohybrid-gpt-basdat \
 -isohybrid-apm-hfsplus

And in syslinux-efi (currently) we add:

-eltorito-alt-boot \
 --efi-boot boot/efi.img \
 -append_partition 2 0x01 \
 binary/boot/efi.img

.

So, I guess the -eltorito-alt-boot does the magic but I'm not sure. 
Maybe someone else can explain it better than me.


* About current compatible bootloaders.
The technology is there. I mean. This is what it's currently available:

binary_grub-efi : Secondary bootloader
binary_grub-legacy : Primary bootloader
binary_grub-pc : Primary bootloader
binary_syslinux : Primary bootloader
binary_syslinux-efi : Secondary bootloader

so that means, in theory you can request one of these 9 combinations:

grub-legacy
grub-pc
syslinux

grub-legacy,grub-efi
grub-pc,grub-efi
syslinux,grub-efi

grub-legacy,syslinux-efi
grub-pc,syslinux-efi
syslinux,syslinux-efi


Why can't you request:

grub-efi
or
grub-efi,syslinux-efi

?

Because nobody has coded grub-efi installed as a primary bootloader yet. 
But the 'framework' is there.

You either need to improve binary_grub-efi or create another script file 
that does its job when ' Is_Primary_Bootloader "grub-efi" ' is true.


> Unless
> the user requests two bootloaders that are incompatible the medium can
> be created.
>
> Ignoring bootloaders is not a good idea. If the user requested
> something that is not possible the build should report an error and
> stop.
Yeah, that it's hard to implement from the perspective of a single 
bootloader script. So I decided not to implement it.

You could add an additional script or function named: 
check_compatible_bootable_pairs (as you propose) but then you need to 
maintain that fictional database each time a new bootloader gets in.

That's why I decide to avoid it using it.

What it's straight-forward to implement is one of the only-secondary 
bootloaders finding themselves as a primary bootloader and outputting a 
warning message. But, I'm not sure what to put there as a warning. Any 
suggestion?

Then, if the only-secondary bootloader script also implemented 
boot-as-primary functionality you would have to remove the warning.

> Finally it seems that some of the patches reference grub-efi before
> the patch that adds support for it. Support for grub-efi should
> probably be added before it's referenced in other code (eg set as
> default).
I have taken that into account with patch numeration. If you think I 
have missed something specifically please point it out.

> Thanks
Thanks for your feedback.
>
> Michal

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #178 received at [email protected] (full text, mbox, reply):

From: Michal Suchanek <[email protected]>

To: adrian15 <[email protected]>

Cc: [email protected], Raphael Hertzog <[email protected]>, jnqnfe <[email protected]>, Thomas Schmitt <[email protected]>, Gaudenz Steinlin <[email protected]>, Has <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 18 Jan 2016 12:57:09 +0100

On 18 January 2016 at 10:43, adrian15 <[email protected]> wrote:
> El 18/01/16 a las 07:31, Michal Suchanek escribió:
>>
>> Hello,
>>
>> thanks for working on this.
>>

>
>> As to the primary and secondary bootloader - how is the efi bootloader
>> secondary? It boots the same as the legacy bootloader. You probably
>> want a concept of compatible bootloaders - that is pairs of
>> bootloaders that can be installed alongside on the same medium.
>
> * What is it a secondary bootloader?
>
> It's what happens when you request mkisofs that your bootloader to be boot
> in second place or as a second partition. I don't know how it actually
> works.
>
> So in grub-efi we just add to the xorriso options:
>
> -eltorito-alt-boot \
>  -e boot/grub/efi.img \
>  -no-emul-boot \
>  -isohybrid-gpt-basdat \
>  -isohybrid-apm-hfsplus
>
> And in syslinux-efi (currently) we add:
>
> -eltorito-alt-boot \
>  --efi-boot boot/efi.img \
>  -append_partition 2 0x01 \
>  binary/boot/efi.img

-eltorito-alt-boot is not documented option of xorriso. For
genisoimage -eltorito-alt-boot denotes start of new bootloader
parameters. So any bootloader is made primary by leaving out
-eltorito-alt-boot.

>
> .
>
> So, I guess the -eltorito-alt-boot does the magic but I'm not sure. Maybe
> someone else can explain it better than me.
>
>
> * About current compatible bootloaders.
> The technology is there. I mean. This is what it's currently available:
>
> binary_grub-efi : Secondary bootloader
> binary_grub-legacy : Primary bootloader
> binary_grub-pc : Primary bootloader
> binary_syslinux : Primary bootloader
> binary_syslinux-efi : Secondary bootloader
>
> so that means, in theory you can request one of these 9 combinations:
>
> grub-legacy
> grub-pc
> syslinux
>
> grub-legacy,grub-efi
> grub-pc,grub-efi
> syslinux,grub-efi
>
> grub-legacy,syslinux-efi
> grub-pc,syslinux-efi
> syslinux,syslinux-efi

You can probably use only one legacy bootloader but syslinux-efi and
grub-efi use different files so it should be possible to install both.
I am not sure how selecting one or the other would work, though.

>
>> Unless
>> the user requests two bootloaders that are incompatible the medium can
>> be created.
>>
>> Ignoring bootloaders is not a good idea. If the user requested
>> something that is not possible the build should report an error and
>> stop.
>
> Yeah, that it's hard to implement from the perspective of a single
> bootloader script. So I decided not to implement it.
>
> You could add an additional script or function named:
> check_compatible_bootable_pairs (as you propose) but then you need to
> maintain that fictional database each time a new bootloader gets in.
>
> That's why I decide to avoid it using it.
>
> What it's straight-forward to implement is one of the only-secondary
> bootloaders finding themselves as a primary bootloader and outputting a
> warning message. But, I'm not sure what to put there as a warning. Any
> suggestion?

Unsupported bootloader combination or whatever.

It should not be a warning however. The script should avoid making
unbootable medium.

Thanks

Michal

Message #183 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 18 Jan 2016 13:38:57 +0100

Hi,

adrian15 wrote:
> * What is it a secondary bootloader?
> It's what happens when you request mkisofs that your bootloader to be 
> boot in second place or as a second partition. I don't know how it 
> actually works.

An ISO may contain several lures for boot firmware.

If it is booted from CD/DVD/BD, then the lures are in the El Torito
boot catalog. In case of debian-cd it contains two entries which
point to boot images. One entry is marked as suitable for BIOS and
one marked as suitable for EFI. The boot firmware then picks what
it deems right and starts it, or offers it to the user for starting.

If the ISO is presented on USB stick or alike, then BIOS looks
for the magic number of an MBR and if so, mindlessly executes
the x86 machine code that starts at byte 0 of the ISO.
This code then hops onto the same boot code that is advertised
by El Torito (because xorriso or isohybrid patched its block
address into the MBR code).

EFI looks on USB stick for an MBR partition of type 0xef or
for a single partition of type 0xee. In the latter case it assumes
the presence of GPT and looks for a GPT partition with type GUID
28732ac11ff8d211ba4b00a0c93ec93b.
Inside the found partition it expects a FAT filesystem and
particular binaries for each supported processor archictecture.
E.g. \EFI\BOOT\BOOTX64.EFI

The El Torito EFI boot image has the same content specification
as the EFI System Partition. Therefore both boot paths can share
the same data. 

My cheat sheet is at
  http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt

-----------------------------------------------------------------

> So, I guess the -eltorito-alt-boot does the magic but I'm not sure. 
> Maybe someone else can explain it better than me.

-eltorito-alt-boot is simply a separator between the options of
El Torito boot images. 
I assume your first boot image is announced by -b and gets
the usual options
   -no-emul-boot -boot-load-size 4 -boot-info-table

Before the announcement of the EFI boot image begins, option
-eltorito-alt-boot is needed to protect your -b and its helpers
from being overwritten.

> So in grub-efi we just add to the xorriso options:
> -eltorito-alt-boot \
>  -e boot/grub/efi.img \
>  -no-emul-boot \
>  -isohybrid-gpt-basdat \
>  -isohybrid-apm-hfsplus

Here a second boot image gets announced by -e and the next three
options apply to it.


> And in syslinux-efi (currently) we add:
> -eltorito-alt-boot \
> --efi-boot boot/efi.img \

Option --efi-boot is a shortcut for
  -eltorito-alt-boot -e ... -no-emul-boot -eltorito-alt-boot
normally used by grub-mkrescue. The SYSLINUX community prefers -e.


> -append_partition 2 0x01 \
>  binary/boot/efi.img

I wonder what EFI firmware would hop on an MBR partition of type 0x01.
An EFI System Partition in MBR should have type 0xef to be recognized.

It looks like this variant will not get GPT. That's fully compliant
to UEFI 2.4. Just the MBR partition type should be 0xef.

(Does "syslinux-efi" mean that you can boot from ISO via EFI
and SYSLINUX stuff to an operating system ? That would be new.)

---------------------------------------------------------------

Above options do not produce HFS+ with blessing.
Option -isohybrid-apm-hfsplus causes an Apple Partition Map entry
which points to the data content of boot/grub/efi.img.

There are two ways known to me how to get a boot path via HFS+:
Fedora Live CD as of Matthew Garrett
or grub-mkrescue as of Vladimir Serbinenko.

---------------------------------------------------------------

Fedora Live, e.g. 
  Fedora-Live-Xfce-x86_64-rawhide-20150704.iso
is the ancestor of debian-cd's layout. It contains a small HFS+
filesystem image as ISO data file
  /isolinux/macboot.img

debian-cd does not have such an HFS+ image file.
Image content and production is out of my scope.

xorriso would only bond it to El Torito, MBR, GPT, and APM. I understand
that APM leads some Macs to that HFS+ filesystem. Whether there are
customers for GPT is unclear. The lures in El Torito and MBR are
probably unused.

The essential xorriso -as mkisofs options are a superset of those
of debian-cd for amd64:

  -isohybrid-mbr /path/to/isohdpfx.bin
  -apm-block-size 2048
  -c '/isolinux/boot.cat'
  -b '/isolinux/isolinux.bin'
    -no-emul-boot
    -boot-load-size 4
    -boot-info-table
  -eltorito-alt-boot
  -e '/isolinux/efiboot.img'
    -no-emul-boot
    -isohybrid-gpt-basdat
    -isohybrid-apm-hfsplus
  -eltorito-alt-boot
  -e '/isolinux/macboot.img'
    -no-emul-boot
    -isohybrid-gpt-hfsplus
    -isohybrid-apm-hfsplus

(Options picked out of proposal of
   xorriso -hfsplus on \
           -indev Fedora-Live-Xfce-x86_64-rawhide-20150704.iso \
           -report_el_torito as_mkisofs
)

No UEFI compliant firmware should use the GPT in there, because
the MBR partition table contains a partition of type other than
0x00 and 0xee. EFI firmware should rather follow the MBR partition
of type 0xef if the ISO is presented on USB stick.

---------------------------------------------------------------

If you install on Sid: grub-pc-bin, grub-efi-ia32-bin, grub-efi-amd64-bin
and run

  mkdir minimal_dir
  echo dummy payload >minimal_dir/dummy_payload
  grub-mkrescue -o output.iso minimal_dir

then you get an image.iso with HFS+, GRUB2 style.
By incident i was spying on grub-mkrescue recently.
The options used were

  -graft-points
  --modification-date=2016011614071900
  -b boot/grub/i386-pc/eltorito.img
    -no-emul-boot
    -boot-load-size 4
    -boot-info-table
    --grub2-boot-info
  --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
  -hfsplus
  -apm-block-size 2048
  -hfsplus-file-creator-type chrp tbxj /System/Library/CoreServices/.disk_label
  -hfs-bless-by i /System/Library/CoreServices/boot.efi
  --efi-boot efi.img
  -efi-boot-part --efi-boot-image
  --protective-msdos-label
  -o output.iso
  -r
  /tmp/grub.ylUf65
  --sort-weight 0 /
  --sort-weight 1 /boot
  minimal_dir

/tmp/grub.ylUf65 was the disk tree with the GRUB files.

Here, the HFS+ filesystem gets created by xorriso (code contributed
by Vladimir Serbinenko).
Other than the Fedora layout, Vladimir's layout puts much emphasis
on disjoint partitions and pointing EFI towards GPT.

---------------------------------------------------------------

Have a nice day :)

Thomas

Message #188 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 18 Jan 2016 14:00:52 +0100

Hi,

Michal Suchanek wrote:
> -eltorito-alt-boot is not documented option of xorriso.

You need to look into man xorrisofs for the options of the -as mkisofs
emulation.

 -eltorito-alt-boot
      Finalize the current El Torito boot catalog entry  and  begin  a
      new  one.  A boot image file and all its necessary options shall
      be specified before option -eltorito-alt-boot.  All  further  El
      Torito  boot  options  apply  to the new catalog entry. Up to 32
      catalog entries are possible.


> So any bootloader is made primary by leaving out -eltorito-alt-boot.

There is no "primary" or "secondary" on the level of boot images
and loaders. (Of course you may call them this way in your project.)

There are first, second, third ... El Torito boot images or MBR, GPT,
APM partition entries.
The sequence is just needed because not all can be first in the list.

The boot firmware inspects the medium for its known lures,
picks a tasty one, and follows it to the boot loader or kernel.


> You can probably use only one legacy bootloader but syslinux-efi and
> grub-efi use different files so it should be possible to install both.
> I am not sure how selecting one or the other would work, though.

You can offer several EL Torito boot images for BIOS, indeed.
It will depend on your BIOS what it does in this case.

There can be only one MBR, though. So you would have to hop
by MBR x86 code to a standalone program which chooses among
the BIOS suitable El Torito boot images.

With EFI it makes few sense to offer more than one El Torito
boot image or EFI System Partition. UEFI 2.4 rather prescribes to
handle all alternatives inside the FAT filesystem. The firmware
will start the \EFI\BOOT\BOOT*.EFI binary which it deems suitable
for its processor type.
This binary is quite free in its further proceedings.


Have a nice day :)

Thomas

Message #193 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Michal Suchanek <[email protected]>

Cc: [email protected], Raphael Hertzog <[email protected]>, jnqnfe <[email protected]>, Thomas Schmitt <[email protected]>, Gaudenz Steinlin <[email protected]>, Has <[email protected]>

Subject: Re: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 18 Jan 2016 16:26:21 +0100

A quick update on my grub-efi work:

1) I have noticed I have missed to give execution permissions to many 
files when I rebased.

These are:
scripts/build/binary_grub-efi
scripts/build/binary_syslinux-efi
scripts/build/efi-image
scripts/build/grub-cpmodules

You can find additional commits to fix this situation on:
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased
and
https://github.com/adrian15/live-build/commits/syslinux-efi-2016
.

(I will probably do another rebase in another branch in the future with 
other of your suggestions and these fixes.)


2) I have released Rescatux 0.40 beta 5 based on: 
https://github.com/adrian15/live-build/tree/rescatux-0.40b5 (The patches 
you have already seen + execution permissions fixed) . It is built by using:
--bootloaders="syslinux,grub-efi" .

You can find more information about it and download links on:

http://www.supergrubdisk.org/2016/01/18/rescatux-0-40-beta-5-released/

Remember that if you want to test it into a USB drive you need to do the 
'dd' if you want it to work ok and that means DESTROYING your data in 
the USB drive.


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #198 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Michal Suchanek <[email protected]>

Cc: [email protected], Raphael Hertzog <[email protected]>, jnqnfe <[email protected]>, Thomas Schmitt <[email protected]>, Gaudenz Steinlin <[email protected]>, Has <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Thu, 21 Jan 2016 02:31:10 +0100

El 18/01/16 a las 12:57, Michal Suchanek escribió:

>>> Unless
>>> the user requests two bootloaders that are incompatible the medium can
>>> be created.
>>>
>>> Ignoring bootloaders is not a good idea. If the user requested
>>> something that is not possible the build should report an error and
>>> stop.
>>
>> Yeah, that it's hard to implement from the perspective of a single
>> bootloader script. So I decided not to implement it.
>>
>> You could add an additional script or function named:
>> check_compatible_bootable_pairs (as you propose) but then you need to
>> maintain that fictional database each time a new bootloader gets in.
>>
>> That's why I decide to avoid it using it.
>>
>> What it's straight-forward to implement is one of the only-secondary
>> bootloaders finding themselves as a primary bootloader and outputting a
>> warning message. But, I'm not sure what to put there as a warning. Any
>> suggestion?
>
> Unsupported bootloader combination or whatever.
>
> It should not be a warning however. The script should avoid making
> unbootable medium.
>
> Thanks
>
> Michal

I have implemented: Check_Primary_Bootloader_Role, 
Check_Secondary_Bootloader_Role functions for avoiding non supported 
bootloader combinations on:

https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased

So that part is solved.

(I'll send a proper rebased set of patches in the future).

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #203 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Thomas Schmitt <[email protected]>, [email protected]

Cc: [email protected], [email protected], [email protected], [email protected], [email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Thu, 21 Jan 2016 02:51:10 +0100

El 18/01/16 a las 14:00, Thomas Schmitt escribió:
>> So any bootloader is made primary by leaving out -eltorito-alt-boot.
>
> There is no "primary" or "secondary" on the level of boot images
> and loaders. (Of course you may call them this way in your project.)
>
> There are first, second, third ... El Torito boot images or MBR, GPT,
> APM partition entries.
> The sequence is just needed because not all can be first in the list.
>
> The boot firmware inspects the medium for its known lures,
> picks a tasty one, and follows it to the boot loader or kernel.

So, yes, I'm the one who invented the term primary for live-build. 
Actually, it was not meant for alt El Torito boot entries (or non first 
entries as you clarify).

The first idea was to add both syslinux and grub-pc in the same image. 
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.

The Grub-pc bits were thought in first place for Super Grub2 Disk (which 
it is Grub2 cfg files mainly).

(Now that I think of the current 'check primary bootloader role' 
functions unable me to perform that Super Grub2 Disk Debian Live that 
included the Syslinux bits too. Anyways I'll find a workaround for that 
in the future. Not a priority right now.)

Now primary means: "First lure" and secondary means "Second lure" by 
your definition.

Currently there's no way to stop you from requesting:

--bootloaders="syslinux,grub-efi,syslinux-efi"

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 can probably use only one legacy bootloader but syslinux-efi and
>> grub-efi use different files so it should be possible to install both.
>> I am not sure how selecting one or the other would work, though.
>
> You can offer several EL Torito boot images for BIOS, indeed.
> It will depend on your BIOS what it does in this case.
Interesting.

> There can be only one MBR, though. So you would have to hop
> by MBR x86 code to a standalone program which chooses among
> the BIOS suitable El Torito boot images.
>
> With EFI it makes few sense to offer more than one El Torito
> boot image or EFI System Partition. UEFI 2.4 rather prescribes to
> handle all alternatives inside the FAT filesystem. The firmware
> will start the \EFI\BOOT\BOOT*.EFI binary which it deems suitable
> for its processor type.
> This binary is quite free in its further proceedings.
So... How would you go about for a:

--bootloaders="syslinux,grub-efi,syslinux-efi"

to make sense if, as I have stated earlier (although I might have missed 
something there) they would overwrite their /efi/boot/boot*efi files ?



adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #208 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Thomas Schmitt <[email protected]>, [email protected]

Cc: [email protected], [email protected], [email protected], [email protected], [email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Thu, 21 Jan 2016 03:41:56 +0100

El 18/01/16 a las 13:38, Thomas Schmitt escribió:
> Hi,
>
> adrian15 wrote:
>> * What is it a secondary bootloader?
>> It's what happens when you request mkisofs that your bootloader to be
>> boot in second place or as a second partition. I don't know how it
>> actually works.
>
> An ISO may contain several lures for boot firmware.
>
> If it is booted from CD/DVD/BD, then the lures are in the El Torito
> boot catalog. In case of debian-cd it contains two entries which
> point to boot images. One entry is marked as suitable for BIOS and
> one marked as suitable for EFI. The boot firmware then picks what
> it deems right and starts it, or offers it to the user for starting.
Interesting.
>
> If the ISO is presented on USB stick or alike, then BIOS looks
> for the magic number of an MBR and if so, mindlessly executes
> the x86 machine code that starts at byte 0 of the ISO.
> This code then hops onto the same boot code that is advertised
> by El Torito (because xorriso or isohybrid patched its block
> address into the MBR code).
Aha.
>
> EFI looks on USB stick for an MBR partition of type 0xef or
> for a single partition of type 0xee. In the latter case it assumes
> the presence of GPT and looks for a GPT partition with type GUID
> 28732ac11ff8d211ba4b00a0c93ec93b.
> Inside the found partition it expects a FAT filesystem and
> particular binaries for each supported processor archictecture.
> E.g. \EFI\BOOT\BOOTX64.EFI
>
> The El Torito EFI boot image has the same content specification
> as the EFI System Partition. Therefore both boot paths can share
> the same data.
>
> My cheat sheet is at
>    http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt

Great! I want to document the different ways of how BIOS boot, UEFI boot 
and Secure Boot work and that might be helpful.

>
> -----------------------------------------------------------------
>
>> So, I guess the -eltorito-alt-boot does the magic but I'm not sure.
>> Maybe someone else can explain it better than me.
>
> -eltorito-alt-boot is simply a separator between the options of
> El Torito boot images.
> I assume your first boot image is announced by -b and gets
> the usual options
>     -no-emul-boot -boot-load-size 4 -boot-info-table
>
> Before the announcement of the EFI boot image begins, option
> -eltorito-alt-boot is needed to protect your -b and its helpers
> from being overwritten.

That it's quite interesting. Do you mean if you have:

xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2

you could just re-arrange them as:

xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1

and it would be fine?

So that it's not strictly necessary for syslinux or grub-pc to be a 
primary bootloader (or first lure in your definition) ?

That would also simplify my contributed code to live-build by not 
needing to handle if a bootloader is primary/secondary or not.

>
>> So in grub-efi we just add to the xorriso options:
>> -eltorito-alt-boot \
>>   -e boot/grub/efi.img \
>>   -no-emul-boot \
>>   -isohybrid-gpt-basdat \
>>   -isohybrid-apm-hfsplus
>
> Here a second boot image gets announced by -e and the next three
> options apply to it.
Ok.
>
>
>> And in syslinux-efi (currently) we add:
>> -eltorito-alt-boot \
>> --efi-boot boot/efi.img \
>
> Option --efi-boot is a shortcut for
>    -eltorito-alt-boot -e ... -no-emul-boot -eltorito-alt-boot
> normally used by grub-mkrescue. The SYSLINUX community prefers -e.
Knowing that I will probably expand that so that the syslinux-efi and 
grub-efi options are more similar and we can compare them in a more easy 
manner.
>
>
>> -append_partition 2 0x01 \
>>   binary/boot/efi.img
>
> I wonder what EFI firmware would hop on an MBR partition of type 0x01.
> An EFI System Partition in MBR should have type 0xef to be recognized.
That needs to be asked to Hertzog. I just tried to use his original work.
>
> It looks like this variant will not get GPT. That's fully compliant
> to UEFI 2.4. Just the MBR partition type should be 0xef.
>
> (Does "syslinux-efi" mean that you can boot from ISO via EFI
> and SYSLINUX stuff to an operating system ? That would be new.)
I don't know what you mean by 'SYLINUX stuff to an operating system. I 
understand that Hertzog work let's you boot into the cd booting by the 
means of EFI. The EFI image needs to include the configuration file (as 
opossed to the grub-efi implementation which only stores its 
configuration file in the CD/DVD/BD media).
>
> ---------------------------------------------------------------
>
> Above options do not produce HFS+ with blessing.
> Option -isohybrid-apm-hfsplus causes an Apple Partition Map entry
> which points to the data content of boot/grub/efi.img.

If I'm not mistaken Hertzog removed that option because you suggested to 
remove it on:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#66

Are you requesting to put this option back ?

>
> There are two ways known to me how to get a boot path via HFS+:
> Fedora Live CD as of Matthew Garrett
> or grub-mkrescue as of Vladimir Serbinenko.

The debian-cd method is one of them? Or is it not?
>
> ---------------------------------------------------------------
>
> Fedora Live, e.g.
>    Fedora-Live-Xfce-x86_64-rawhide-20150704.iso
> is the ancestor of debian-cd's layout. It contains a small HFS+
> filesystem image as ISO data file
>    /isolinux/macboot.img
>
> debian-cd does not have such an HFS+ image file.

The current debian-cd ( debian-8.2.0-amd64-i386-netinst.iso ) xorriso 
options are:

xorriso -as mkisofs -r \
-checksum_algorithm_iso md5,sha1,sha256,sha512 \
-V 'Debian 8.2.0 M-A 1' \
-o 
/org/cdbuilder.debian.org/dst/deb-cd/out/2multi-arch/debian-8.2.0-amd64-i386-NETINST-1.iso 
\
-jigdo-jigdo 
/org/cdbuilder.debian.org/dst/deb-cd/out/2multi-arch/debian-8.2.0-amd64-i386-NETINST-1.jigdo 
\
-jigdo-template 
/org/cdbuilder.debian.org/dst/deb-cd/out/2multi-arch/debian-8.2.0-amd64-i386-NETINST-1.template 
\
-jigdo-map Debian=/org/cdbuilder.debian.org/src/ftp/debian/ \
-jigdo-exclude boot1 \
-md5-list 
/org/cdbuilder.debian.org/src/deb-cd/tmp/2multi-arch/jessie/md5-check \
-jigdo-min-file-size 1024 \
-jigdo-exclude 'README*' \
-jigdo-exclude /doc/ \
-jigdo-exclude /md5sum.txt \
-jigdo-exclude /.disk/ \
-jigdo-exclude /pics/ \
-jigdo-exclude 'Release*' \
-jigdo-exclude 'Packages*' \
-jigdo-exclude 'Sources*' \
-J -J \
-joliet-long \
-cache-inodes \
-isohybrid-mbr syslinux/usr/lib/ISOLINUX/isohdpfx.bin \
-b isolinux/isolinux.bin \
-c isolinux/boot.cat \
-boot-load-size 4 \
-boot-info-table \
-no-emul-boot \
-eltorito-alt-boot \
-e boot/grub/efi.img
-no-emul-boot \
-isohybrid-gpt-basdat \
-isohybrid-apm-hfsplus \
boot1 CD1

where you can see they use:

-isohybrid-apm-hfsplus

So... this is not useful for creating an HFS+ image file?
What does this option do instead then?

Or maybe your debian-cd information was outdated?

> Image content and production is out of my scope.
>
> xorriso would only bond it to El Torito, MBR, GPT, and APM. I understand
> that APM leads some Macs to that HFS+ filesystem. Whether there are
> customers for GPT is unclear.
I know that some Mac Book Pro s from 2010,2011 and so on use and 
understand GPT by default. Actually if you want to produce, e.g. a 
working Mac OS X installation disk I think it's compulsory to do it in a 
GPT disk.

And, well, the Grub2 in git happens to generate an additional GPT disk 
somehow in the same disk image for that matter. Maybe I'm just repeating 
what you are going to saying later in this email about how Grub2 handles 
boot in Mac systems.

> The lures in El Torito and MBR are
> probably unused.
Yeah, they are probably unused.
>
> The essential xorriso -as mkisofs options are a superset of those
> of debian-cd for amd64:
>
>    -isohybrid-mbr /path/to/isohdpfx.bin
>    -apm-block-size 2048
>    -c '/isolinux/boot.cat'
>    -b '/isolinux/isolinux.bin'
>      -no-emul-boot
>      -boot-load-size 4
>      -boot-info-table
>    -eltorito-alt-boot
>    -e '/isolinux/efiboot.img'
>      -no-emul-boot
>      -isohybrid-gpt-basdat
>      -isohybrid-apm-hfsplus
>    -eltorito-alt-boot
>    -e '/isolinux/macboot.img'
>      -no-emul-boot
>      -isohybrid-gpt-hfsplus
>      -isohybrid-apm-hfsplus
>
> (Options picked out of proposal of
>     xorriso -hfsplus on \
>             -indev Fedora-Live-Xfce-x86_64-rawhide-20150704.iso \
>             -report_el_torito as_mkisofs
> )
Interesting. I did not know that you could request what an ISO 
'layout/configuration' was.
>
> No UEFI compliant firmware should use the GPT in there, because
> the MBR partition table contains a partition of type other than
> 0x00 and 0xee. EFI firmware should rather follow the MBR partition
> of type 0xef if the ISO is presented on USB stick.

Sorry but I'm not following you.

A) Are you complaining about syslinux-efi on:

-append_partition 2 0x01

that should be:

-append_partition 2 0xef

instead?

B) You are saying good things about -isohybrid-apm-hfsplus because it 
avoids normal EFI firmware to read it? So that only Mac systems can read it?


>
> ---------------------------------------------------------------
>
> If you install on Sid: grub-pc-bin, grub-efi-ia32-bin, grub-efi-amd64-bin
> and run
>
>    mkdir minimal_dir
>    echo dummy payload >minimal_dir/dummy_payload
>    grub-mkrescue -o output.iso minimal_dir
>
> then you get an image.iso with HFS+, GRUB2 style.
Yeah, I do a similar thing with Super Grub2 Disk 'hybrid' ( 
http://www.supergrubdisk.org/2015/05/03/super-grub2-disk-2-02s3-released/ ) 
version. Last time I checked it did not work ok in Debian because the 
commit the grub package was based was too old.

The exact problem is that it did not boot in EFI mode when booted from a 
USB device / hard disk.

I kind of complained here: 
https://lists.debian.org/debian-efi/2016/01/msg00013.html but did not 
manage to explain what the exact problem was.

> By incident i was spying on grub-mkrescue recently.
> The options used were
>
>    -graft-points
>    --modification-date=2016011614071900
>    -b boot/grub/i386-pc/eltorito.img
>      -no-emul-boot
>      -boot-load-size 4
>      -boot-info-table
>      --grub2-boot-info
>    --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
>    -hfsplus
>    -apm-block-size 2048
>    -hfsplus-file-creator-type chrp tbxj /System/Library/CoreServices/.disk_label
>    -hfs-bless-by i /System/Library/CoreServices/boot.efi
>    --efi-boot efi.img
>    -efi-boot-part --efi-boot-image
>    --protective-msdos-label
>    -o output.iso
>    -r
>    /tmp/grub.ylUf65
>    --sort-weight 0 /
>    --sort-weight 1 /boot
>    minimal_dir
>
> /tmp/grub.ylUf65 was the disk tree with the GRUB files.

Interesting. That /System/Library is from Mac OS X systems, probably 
from Mac OS X installation disks. And there's the bless part too. This 
is quite interesting. It might be even more compatible with more systems 
than debian-cd implementation. But, well, I'm not quite an expert myself 
for claiming that statement right now.

Do you know if that Serbinenko contribution needs a minimal xorriso 
version? (I just tried the -report_el_torito switch in Debian jessie and 
it's not there. I was wondering if it would happen the same thing with 
Serbinenko work. Debian Jessie version for xorriso is: 1.3.2 .)

>
> Here, the HFS+ filesystem gets created by xorriso (code contributed
> by Vladimir Serbinenko).
> Other than the Fedora layout, Vladimir's layout puts much emphasis
> on disjoint partitions and pointing EFI towards GPT.
I see.
>
> ---------------------------------------------------------------
>
> Have a nice day :)
Thank you for your valuable information.
>
> Thomas
>
>

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #213 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Thu, 21 Jan 2016 10:13:26 +0100

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


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


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


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

  
> 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... 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 [email protected] that the capability was missing
in SYSLINUX EFI to hop from the FAT filesystem into the ISO filesystem.


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


Have a nice day :)

Thomas

Message #218 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Thu, 21 Jan 2016 12:57:23 +0100

Hi,

i wrote:
> http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt

adrian15 wrote:
> I want to document the different ways of how BIOS boot, UEFI boot and
> Secure Boot work and that might be helpful.

Secure Boot is not covered. (I am not sure whether it belongs there.
Actually i don't know enough about it.)


adrian15 wrote:
> Do you mean if you have:
> xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2
> you could just re-arrange them as:
> xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1
> and it would be fine?

From the view of xorriso and El Torito specs this is ok.
You have to keep the modifier options (e.g. -boot-info-table) in
the same -eltorito-alt-boot department as their main options (e.g. -b).

The program isohybrid of SYSLINUX expects BIOS in El Torito catalog
entry 1, EFI in entry 2, and HFS+ in entry 3.
So with genisoimage + isohybrid, you'd have to keep the sequence.

One never knows what firmware does with such changes. Normally
it should accept any sequence. But tradition is: BIOS first, EFI second.


> > I wonder what EFI firmware would hop on an MBR partition of type 0x01.
> > An EFI System Partition in MBR should have type 0xef to be recognized.
> That needs to be asked to Hertzog. I just tried to use his original work.

Did you try whether it boots via EFI if no BIOS boot equipment
is in the ISO ?

Raphaël ? Can you shed light on this ?
Does the 0x01 partition stem from the "Firmware Partition" of mini.iso ?
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776317
reports about quite unintentional boot success via that partition.)


> > (Does "syslinux-efi" mean that you can boot from ISO via EFI
> > and SYSLINUX stuff to an operating system ? That would be new.)
> I don't know what you mean by 'SYLINUX stuff to an operating system.

Afaik, SYSLINUX begins to boot from an EFI System Partition inside
or after the ISO filesystem. It does not get to booting the operating
system files in the ISO filesystem, though.


> The EFI image needs to include the configuration file

Given the reports on [email protected] i'd expect that enough of
operating system has to reside in the FAT filesystem so it is able
to boot to the capability to find and read the ISO filesystem.

But in practice, all EFI bootable ISOs known to me use GRUB for the job.
(One may boot a kernel directly from EFI, without intermediate boot
loader. Examples are rare but seem to work.)


> If I'm not mistaken Hertzog removed that option because you suggested to
> remove it on:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#66
> Are you requesting to put this option back ?

Only if you augment the boot equipment by a third boot image that
contains a small HFS+ filesystem. (See Fedora Live CD.)
As long as there is no HFS+, the option -isohybrid-apm-hfsplus
is inappropriate but seems to do no harm. (See Debian amd64 netinst.)


> > There are two ways known to me how to get a boot path via HFS+:
> The debian-cd method is one of them? Or is it not?

debian-cd has no HFS+ boot image. This makes it different from
Fedora Live CD.

The xorriso run could be easily adapted to include a HFS+ image.
But i do not know how Matthew Garrett produced this image.
One would have to investigate its content and find some Mac
filesystem tool to produce such content.


> The current debian-cd ( debian-8.2.0-amd64-i386-netinst.iso ) xorriso
> options are: [well known from file /.disk/mkisofs in the ISO]
> where you can see they use:
> -isohybrid-apm-hfsplus
> So... this is not useful for creating an HFS+ image file?

No. It just announces the EFI boot image in an Apple Partition Map.
This might be of use for GRUB2 if no other partition table points
to that image. But 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.)


> What does this option do instead then?

It is surplus, currently.


> Maybe I'm just repeating
> what you are going to saying later in this email about how Grub2 handles
> boot in Mac systems.

Regreattably i can only forward the rumor that Some (TM) Macs
do not boot without HFS+ and its blessed files.

They are in the time window between Apple Inc. giving up PowerPC
and Apple Inc. adopting EFI.


> > (Options picked out of proposal of
> >     xorriso -hfsplus on \
> >             -indev Fedora-Live-Xfce-x86_64-rawhide-20150704.iso \
> >             -report_el_torito as_mkisofs

> Interesting. I did not know that you could request what an ISO
> 'layout/configuration' was.

This is a xorriso feature which is present in the Sid package
xorriso-1.4.2 but not in xorriso-1.3.2 as of Debian 8.

You can request a listing of the boot equipment

  xorriso -hfsplus on -indev ...iso \
          -report_el_torito plain -report_system_area plain

and you can request option proposals by above
          -report_el_torito as_mkisofs


> A) Are you complaining about syslinux-efi on:
> -append_partition 2 0x01
> that should be:
> -append_partition 2 0xef
> instead?

Yes. UEFI 2.4 5.2.2 says about booting from MBR partitions:
"* 0xEF (i.e., UEFI System Partition) defines a UEFI system partition."

The presence of GPT would have to be announced by a "protective MBR"
partition of type 0xee with start at LBA 1. Any MBR partition type other
than 0x00 and 0xee prevents the recognition of GPT.


> B) You are saying good things about -isohybrid-apm-hfsplus because it avoids
normal EFI firmware to read it? So that only Mac systems can read it?

This option makes sense mainly/only if a HFS+ boot image is present.


> >    grub-mkrescue -o output.iso minimal_dir
> Last time I checked it did not work ok in Debian because the commit
> the grub package was based was too old.

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


> https://lists.debian.org/debian-efi/2016/01/msg00013.html
> 4.1. Debian packages do not provide a way of building an hybrid
> (both valid in i386-pc and efi machines) iso. 

This should work with the Sid packages of GRUB2.


> 4.2. Debian GNU/GRUB Version 2 package version commit was behind
> what Super Grub2 Disk needed for it to work on a Mac-Intel system
> (The three partition types in a single iso hack if you know what I mean).

grub-mkrescue produces a different layout than debian-cd or
Fedora Live CD.
It is less convenient for mounting the ISO because none of
the partitions points to its start.
It is more UEFI compliant than debian-cd, because it avoids
overlapping of partitions.


> Do you know if that Serbinenko contribution needs a minimal xorriso version?

It is in xorriso since version 1.2.4.
I.e. Debian 8 Jessie should suffice. Else get a GNU xorriso tarball.
Current release is
  http://ftpmirror.gnu.org/xorriso/xorriso-1.4.2.tar.gz


Have a nice day :)

Thomas

Message #223 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Thomas Schmitt <[email protected]>, [email protected]

Cc: [email protected], [email protected], [email protected], [email protected], [email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Fri, 22 Jan 2016 23:57:04 +0100

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 [email protected] 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/

Message #228 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Thomas Schmitt <[email protected]>, [email protected]

Cc: [email protected], [email protected], [email protected], [email protected], [email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Sat, 23 Jan 2016 00:25:05 +0100

El 21/01/16 a las 12:57, Thomas Schmitt escribió:
>
>
> adrian15 wrote:
>> Do you mean if you have:
>> xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2
>> you could just re-arrange them as:
>> xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1
>> and it would be fine?
>
>>From the view of xorriso and El Torito specs this is ok.
> You have to keep the modifier options (e.g. -boot-info-table) in
> the same -eltorito-alt-boot department as their main options (e.g. -b).
>
> The program isohybrid of SYSLINUX expects BIOS in El Torito catalog
> entry 1, EFI in entry 2, and HFS+ in entry 3.
> So with genisoimage + isohybrid, you'd have to keep the sequence.
>
> One never knows what firmware does with such changes. Normally
> it should accept any sequence. But tradition is: BIOS first, EFI second.

I see. So when using syslinux it's better for it to be the primary 
bootloader. Ok.

And, if I'm not mistaken doing a:

--bootloaders="grub-efi" should be quite easy.

That way people that want EFI only images would be able to make them. In 
order to do that I would just need to implement the primary bootloader 
behaviour of grub-efi and, well, remove the current grub-efi as a 
secondary bootloader role enforcement.

I might finally do that.

>>> I wonder what EFI firmware would hop on an MBR partition of type 0x01.
>>> An EFI System Partition in MBR should have type 0xef to be recognized.
>> That needs to be asked to Hertzog. I just tried to use his original work.
>
> 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 .

I probably need to do more tests later.

>> If I'm not mistaken Hertzog removed that option because you suggested to
>> remove it on:
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#66
>> Are you requesting to put this option back ?
>
> Only if you augment the boot equipment by a third boot image that
> contains a small HFS+ filesystem. (See Fedora Live CD.)
> As long as there is no HFS+, the option -isohybrid-apm-hfsplus
> is inappropriate but seems to do no harm. (See Debian amd64 netinst.)

I see. So the Fedora Live CD would seem even better. I wonder why the 
debian-cd team did not consider adding this third boot image with a 
small HFS+ filesystem. I'll probably ask them in the irc.

>>> There are two ways known to me how to get a boot path via HFS+:
>> The debian-cd method is one of them? Or is it not?
>
> debian-cd has no HFS+ boot image. This makes it different from
> Fedora Live CD.
Understood.
>
> The xorriso run could be easily adapted to include a HFS+ image.
> But i do not know how Matthew Garrett produced this image.
I was doing some research on SElinux support and I found these set of 
tools for creating the Fedora Live CDs:

https://github.com/rhinstaller/livecd-tools

It's quite nice learning how other build their own live cd systems. 
Anyways, back to the main subject, I have no idea if Matthew Garrett 
used this tool or not.

> One would have to investigate its content and find some Mac
> filesystem tool to produce such content.
Probably.

>> The current debian-cd ( debian-8.2.0-amd64-i386-netinst.iso ) xorriso
>> options are: [well known from file /.disk/mkisofs in the ISO]
>> where you can see they use:
>> -isohybrid-apm-hfsplus
>> So... this is not useful for creating an HFS+ image file?
>
> No. It just announces the EFI boot image in an Apple Partition Map.
> This might be of use for GRUB2 if no other partition table points
> to that image. But 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"?
>
>
>> What does this option do instead then?
>
> It is surplus, currently.
>
>
>> Maybe I'm just repeating
>> what you are going to saying later in this email about how Grub2 handles
>> boot in Mac systems.
>
> Regreattably i can only forward the rumor that Some (TM) Macs
> do not boot without HFS+ and its blessed files.
>
> They are in the time window between Apple Inc. giving up PowerPC
> and Apple Inc. adopting EFI.
I have one of them in that window. I'm not sure about the blessing being 
needed though. Maybe I have disabled it. Not sure.
>
>
>> A) Are you complaining about syslinux-efi on:
>> -append_partition 2 0x01
>> that should be:
>> -append_partition 2 0xef
>> instead?
>
> Yes. UEFI 2.4 5.2.2 says about booting from MBR partitions:
> "* 0xEF (i.e., UEFI System Partition) defines a UEFI system partition."
>
> The presence of GPT would have to be announced by a "protective MBR"
> partition of type 0xee with start at LBA 1. Any MBR partition type other
> than 0x00 and 0xee prevents the recognition of GPT.
Maybe that's why the syslinux-efi does not boot. I could give it a try 
changing the partition type and see what happens.
>
>>>     grub-mkrescue -o output.iso minimal_dir
>> Last time I checked it did not work ok in Debian because the commit
>> the grub package was based was too old.
>
> 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. Anyways it's high 
probable that the Sid package has been updated and, if I tried right 
know, it would work for me.
>> 4.2. Debian GNU/GRUB Version 2 package version commit was behind
>> what Super Grub2 Disk needed for it to work on a Mac-Intel system
>> (The three partition types in a single iso hack if you know what I mean).
>
> grub-mkrescue produces a different layout than debian-cd or
> Fedora Live CD.
> It is less convenient for mounting the ISO because none of
> the partitions points to its start.
Yeah, I received some complaints about people not being able to reuse 
their usb sticks after dd'ing Super Grub2 Disk (based on grub-mkrescue 
you describe) into their usb sticks.
> It is more UEFI compliant than debian-cd, because it avoids
> overlapping of partitions.
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.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #233 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Thomas Schmitt <[email protected]>, [email protected]

Cc: [email protected], [email protected], [email protected], [email protected], [email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Sat, 23 Jan 2016 01:58:46 +0100

[Message part 1 (text/plain, inline)]

Despite of being discussing how to implement all of these properly. I 
feel it's right to show you my current work so that you can comment on it.

I attach my updated patches.

1) The main differences from my original patches are:

* I use more additional bootloader functions
* The code ensures that each bootloader can be used in its role, being 
it a primary bootloader o a secondary bootloader. That way we avoid the 
user being able to generate non bootable isos.

2) For the time being I am not maintaining the syslinux-efi branch till 
we manage to get a consensus on this one. Then I will rebase it, change 
the partition type and re-test it.

3) As I have mentioned in another message I plan to work on giving the 
user the ability of creating isos using:
--bootloaders="grub-efi" thus using grub-efi as a primary bootloader.

4) The patches can be found as a git branch (based on live-build master 
branch) here:

https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased_4


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

[001_define_lb_primary_bootloader_correctly.diff (text/plain, attachment)]

[002_remove_duplicated_lb_primary_bootloader.diff (text/plain, attachment)]

[003_add_bootloader_functions.diff (text/plain, attachment)]

[004_loopback_cfg_grub_cfg.diff (text/plain, attachment)]

[005_efi-image_and_grub-cpmodules.diff (text/plain, attachment)]

[006_efi-support-based-on-grub-efi.diff (text/plain, attachment)]

[007_bootloaders-use-new-bootloaders-functions.diff (text/plain, attachment)]

[008_syslinux_grub-efi_default_bootloaders.diff (text/plain, attachment)]

Message #238 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Thomas Schmitt <[email protected]>, [email protected]

Cc: [email protected], [email protected], [email protected], [email protected], [email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Sat, 23 Jan 2016 02:18:15 +0100

El 21/01/16 a las 10:13, Thomas Schmitt escribió:

>> 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 was thinking on this. So... what if there is a fourth dimension for 
choosing if the job description goes first or second in the mkisofs command?

E.g.:
xorriso bunch-of-options-1 -eltorito-alt-boot bunch-of-options-2
versus
xorriso bunch-of-options-2 -eltorito-alt-boot bunch-of-options-1

So you don't like the primary or secondary terms.

How does xorriso name them?

Given that man xorrisofs talks about:

-eltorito-alt-boot

maybe we can just name them as:

"Main bootloader"
and
"Alternate bootloader".

Or maybe even better:

"Main eltorito entry"
and
"Alternate eltorito entry"
?

So that we can force a given bootloader to be used only as a "Main 
eltorito entry" ?


What do you think about this idea?


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #243 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Sat, 23 Jan 2016 09:21:52 +0100

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

Message #248 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Sat, 23 Jan 2016 12:58:49 +0100

Hi,

after checking El Torito specs, i have to correct my statements
about ranking of El Torito boot images.

The first entry in the boot catalog not only has the title
"Initial" but "Initial/Default".

"4.4 Boot Entry Selection
If the CD has several boot entries, a default entry which boots a 
election program may be provided as the Default/Initial catalog entry.
This image will usually be a floppy image which loads a program that
selects the proper boot image by examining the system configuration or
questioning the user."

Insofar, the first boot image in the catalog is something special.
It is to be preferred over the other boot images with the same
Platform Id. (Nevertheless, it is not obliged to really offer
booting of the others of the same Platform Id.)

I would plan for only one El Torito boot image per platform:
0 = 80x86 BIOS , 0xef = EFI.
But if there is a use case for offering BIOS boot images from GRUB2
and ISOLINUX in the same El Torito catalog, then the sequence matters
if one of them occupies the first entry in the catalog.
If you put the EFI boot image first, then both BIOS boot images get
equal rank.


In the light of this, it seems wise to stay with the sequence that is
tested since a few years:
First the BIOS boot image, then the EFI boot image, no further BIOS
boot images.

This makes it clear to the firmware:
BIOS will hop on the first entry, because it has the right Platform Id
and is Default. BIOS will most probably not enforce that the first
boot image is a floppy image, because there is no other BIOS boot image.
(You always have to expect that the BIOS programmers read the specs
with tired eyes.)
EFI will not hop on the Default entry, because the Platform Id
does not match.

The MBR x86 BIOS code, too, would have to decide on which BIOS boot
image binary to hop. If there is only one, the decision is easy.


Have a nice day :)

Thomas

Message #253 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Thomas Schmitt <[email protected]>, [email protected]

Cc: [email protected], [email protected], [email protected], [email protected], [email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Sun, 24 Jan 2016 00:41:46 +0100

El 23/01/16 a las 09:21, Thomas Schmitt escribió:
> 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.)

I propose you to send these concerns to live-wrapper project which has 
just begun and it's advertised as highly modular by Iain. It would be 
quite nice if all these concerns were properly addressed by Iain's tool.

  I am not saying that they are not welcomed to live-build but, right 
now, I think we should focus on making UEFI to boot and not re-thinking 
all the bootloader handling.

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

I once asked in a Debconf why the people were so stubborn to use 
syslinux instead of using grub2 (which seems technically superior to 
me). It would seem that the same people that maintain syslinux happen to 
maintain the kernel boot stack (or whatever it is called, I mean what 
happens just after the bootloader handling the execution to the kernel). 
So, that means, it's far easier to them to debug why the kernel is 
refusing to boot.

I am personally in a favour of GRUB2-only Live CDs so that it's much 
easier to have native Super Grub2 Disk in them :) .

>> 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... what about using:

FIRST_BOOTLOADER
and
SECOND_BOOTLOADER

instead of my current:

PRIMARY_BOOTLOADER
and
SECONDARY_BOOTLOADER

?

I could even add a third bootloader if needed. And, well, I have some 
ideas on how to add some special functions to binary_bootloader files so 
that we have some sort of Object-Oriented / Hook programming when 
defining what goes into the mkisofs options.

If you check current: binary_iso file it just relies on existing 
binary_bootloaders without having an agnostic bootloader approach.

Here it's what I'm talking about:

https://github.com/adrian15/live-build/blob/5eba3dff5a16a34c3c1eb5d54e3767339654e2d0/scripts/build/binary_iso#L111-L145

case "${LB_PRIMARY_BOOTLOADER}" in
	grub)
(...)
        grub-pc)
(...)

esac


We could just invent the:

grub-pc-xorriso-options()
or
syslinux-xorriso-options()

functions which would be defined in:

binary_grub-pc
or
binary_syslinux
files

and handle all of these with only 3 or 4 lines of code.

E.g. binary_iso would add '-eltorito-alt-boot' just before a second 
bootloader so that the bootloader only needs to take care of their own 
boot options.


Is there anyone opposed to such a big change on live-build handling of 
bootloaders?


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #258 received at [email protected] (full text, mbox, reply):

From: Michal Suchanek <[email protected]>

To: adrian15 <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Sun, 24 Jan 2016 16:51:46 +0100

On 24 January 2016 at 00:41, adrian15 <[email protected]> wrote:
> El 23/01/16 a las 09:21, Thomas Schmitt escribió:
>>
>> 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.)
>
>
> I propose you to send these concerns to live-wrapper project which has just
> begun and it's advertised as highly modular by Iain. It would be quite nice
> if all these concerns were properly addressed by Iain's tool.
>
>   I am not saying that they are not welcomed to live-build but, right now, I
> think we should focus on making UEFI to boot and not re-thinking all the
> bootloader handling.
>
>> 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.
>
>
> I once asked in a Debconf why the people were so stubborn to use syslinux
> instead of using grub2 (which seems technically superior to me). It would
> seem that the same people that maintain syslinux happen to maintain the
> kernel boot stack (or whatever it is called, I mean what happens just after
> the bootloader handling the execution to the kernel). So, that means, it's
> far easier to them to debug why the kernel is refusing to boot.
>

I was wondering that also. The GRUB is so cool and can do everything, right?

It also means it can crumble and fall apart in so many interesting ways.

I mean if you install grub on a LVM soft-RAID array and it then does
not boot you are wondering why it happened when it has all those RAID
modules. And you find that it has RAID modules only for the *previous*
revision of the LVM format.

So you do what you would plan for from the start with Syslinux - plug
in an USB stick and put a boot partition on it, yay.

Could have saved hours of debugging by going with the stupid limited
Syslinux from the start, right?

>>> 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... what about using:
>
> FIRST_BOOTLOADER
> and
> SECOND_BOOTLOADER
>
> instead of my current:
>
> PRIMARY_BOOTLOADER
> and
> SECONDARY_BOOTLOADER
>


why not BOOTLOADERS?

The concept of being primary or secondary is just broken.

You can store 64 el-torito catalog entries on a CD. The different
entries are separated by -eltorito-alt-boot option. When you put the
CD with a BIOS and EFI entry in a machine that prefers UEFI the efi
entry is primary even when there is a CSM. When you put the CD into a
machine with legacy BIOS the BIOS entry is primary in the EFI one
useless.

There are some technical details like it is desirable to put the BIOS
entry before the EFI entry. This may be either enforced by reordering
the bootloader list automagically or just by setting the default to
syslinux,grub-efi and explaining in the docs that this is the usual
order and changing the order may potentially cause issues.

There are more technical details like the bootloader for i386 and
amd64 BIOS is the same one and on EFI it's two different binaries. Or
that when there is an EFI bootloader it's desirable to create another
e-torito entry for it as APM to boot on Macs. The technical details of
creating multiple partitions, boot entries, and whatnot are
implementation details. It's nice to document these details somewhere
for people who want to further butcher the created medium, add support
for more bootloaders, etc.

So basically what we have is support for two PC firmware types:

BIOS
EFI

and two bootloader alternatives for each firmware type

syslinux
grub

and for simlicity only one bootloader for one firmware type is
supported on single medium. Since booting on BIOS platform is well
supported with syslinux and booting on EFI platform is well-supported
with grub it is desirable to have the option to specify different
bootloader type for each supported platform and make it the default.
So rather than

BOOTLOADER=syslinux
BOOT_FIRMWARE=bios,efi

we have

BOOTLOADERS=syslinux,grub-efi

That is the bootloader name encodes the whole bootloader-firmware
pair. There is no need to specify more. It is well possible to specify
to not include 32bit efi binaries when building a 64bit CD build but
that's *-efi installation option and not a separate bootloader type.

This means the user can have 1-2 bootloaders on a single medium. And
if coreboot or whatnot support is added in the future there is
potential to have more.


Thanks

Michal

Message #263 received at [email protected] (full text, mbox, reply):

From: "Thomas Schmitt" <[email protected]>

To: [email protected]

Cc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected]

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Sun, 24 Jan 2016 18:02:22 +0100

Hi,

adrian15 wrote:
> I propose you to send these concerns to live-wrapper project which has just
> begun and it's advertised as highly modular by Iain.

New customers ? Welcome !


> I think we should focus on making UEFI to boot and not re-thinking all the
> bootloader handling.

I well understand that each project has its own goals and priorities.
My remarks shall serve as background info.


> I once asked in a Debconf why the people were so stubborn to use syslinux
> instead of using grub2 [...] It would
> seem that the same people that maintain syslinux happen to maintain the
> kernel boot stack

The kernels on an Installation-ISO or Live-ISO should not be
adventurous enough to make this important. The devices on which
the ISO gets presented are supposed to be oldfashioned.
(A 4K disk might cause failure. But who puts an ISO on such a disk ?)

As provider of xorriso i stay neutral towards the boot loaders.


Michal Suchanek wrote:
> I was wondering that also. The GRUB is so cool and can do everything, right?

It seems to be more apt with EFI and ISO 9660.
debian-cd needs a few hundred KB to hop out of FAT into ISO.
SYSLINUX needs another operating system to finally get out of FAT.


> I mean if you install grub on a LVM soft-RAID array

Another unlikely device type for presenting ISO 9660, too our luck.


> Could have saved hours of debugging by going with the stupid limited
> Syslinux from the start, right?

Never change a working system.
I assume that this is the true reason why nearly everybody else
still uses ISOLINUX for BIOS booting from ISO 9660.

A well maintained iLive CD system based entirely on GRUB2 would
help to find out whether this is supersticion or deep wisdom.


Have a nice day :)

Thomas

Message #268 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Michal Suchanek <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 25 Jan 2016 03:05:35 +0100

El 24/01/16 a las 16:51, Michal Suchanek escribió:
>>> 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... what about using:
>>
>> FIRST_BOOTLOADER
>> and
>> SECOND_BOOTLOADER
>>
>> instead of my current:
>>
>> PRIMARY_BOOTLOADER
>> and
>> SECONDARY_BOOTLOADER
>>
>
>
> why not BOOTLOADERS?
>
> The concept of being primary or secondary is just broken.
>
> You can store 64 el-torito catalog entries on a CD. The different
> entries are separated by -eltorito-alt-boot option. When you put the
> CD with a BIOS and EFI entry in a machine that prefers UEFI the efi
> entry is primary even when there is a CSM. When you put the CD into a
> machine with legacy BIOS the BIOS entry is primary in the EFI one
> useless.
>
> There are some technical details like it is desirable to put the BIOS
> entry before the EFI entry. This may be either enforced by reordering
> the bootloader list automagically or just by setting the default to
> syslinux,grub-efi and explaining in the docs that this is the usual
> order and changing the order may potentially cause issues.
>
> There are more technical details like the bootloader for i386 and
> amd64 BIOS is the same one and on EFI it's two different binaries. Or
> that when there is an EFI bootloader it's desirable to create another
> e-torito entry for it as APM to boot on Macs. The technical details of
> creating multiple partitions, boot entries, and whatnot are
> implementation details. It's nice to document these details somewhere
> for people who want to further butcher the created medium, add support
> for more bootloaders, etc.
>
> So basically what we have is support for two PC firmware types:
>
> BIOS
> EFI
>
> and two bootloader alternatives for each firmware type
>
> syslinux
> grub
>
> and for simlicity only one bootloader for one firmware type is
> supported on single medium. Since booting on BIOS platform is well
> supported with syslinux and booting on EFI platform is well-supported
> with grub it is desirable to have the option to specify different
> bootloader type for each supported platform and make it the default.
> So rather than
>
> BOOTLOADER=syslinux
> BOOT_FIRMWARE=bios,efi
>
> we have
>
> BOOTLOADERS=syslinux,grub-efi
>
> That is the bootloader name encodes the whole bootloader-firmware
> pair. There is no need to specify more. It is well possible to specify
> to not include 32bit efi binaries when building a 64bit CD build but
> that's *-efi installation option and not a separate bootloader type.
>
> This means the user can have 1-2 bootloaders on a single medium. And
> if coreboot or whatnot support is added in the future there is
> potential to have more.
>
>
> Thanks
>
> Michal
>

What you are describing here is what it's actually implemented in my 
patch (Well, actually the first patch version because the current one 
enforces bootloader roles). So what about primary and secondary terms? 
Or first or second terms?

These terms are used in two places:
* Internal variables and functions to handle bootloaders
* Information shown to the final user

I'm most convinced to use the first and non-first notation. So that the 
old code that referred to LB_BOOTLOADER can just refer to: 
LB_FIRST_BOOTLOADER.

Later on, if we want to improve this old code we can modify it so that 
it handles LB_BOOTLOADERS thanks to the bootloader functions directly.

I agree with you that a good approach would be to document the different 
supported or suggested bootloader combinations rather than trying to 
enforce it by code.

That would match my last thoughts which I quote here:

> And, well, I have some ideas on how to add some special functions to binary_bootloader files so that we have some sort of Object-Oriented / Hook programming when defining what goes into the mkisofs options.
>
> If you check current: binary_iso file it just relies on existing binary_bootloaders without having an agnostic bootloader approach.
>
> Here it's what I'm talking about:
>
> https://github.com/adrian15/live-build/blob/5eba3dff5a16a34c3c1eb5d54e3767339654e2d0/scripts/build/binary_iso#L111-L145
>
> case "${LB_PRIMARY_BOOTLOADER}" in
>     grub)
> (...)
>         grub-pc)
> (...)
>
> esac
>
>
> We could just invent the:
>
> grub-pc-xorriso-options()
> or
> syslinux-xorriso-options()
>
> functions which would be defined in:
>
> binary_grub-pc
> or
> binary_syslinux
> files
>
> and handle all of these with only 3 or 4 lines of code.
>
> E.g. binary_iso would add '-eltorito-alt-boot' just before a second bootloader so that the bootloader only needs to take care of their own boot options.
>
>
> Is there anyone opposed to such a big change on live-build handling of bootloaders?


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #273 received at [email protected] (full text, mbox, reply):

From: Michal Suchanek <[email protected]>

To: adrian15 <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 25 Jan 2016 16:12:11 +0100

On 25 January 2016 at 03:05, adrian15 <[email protected]> wrote:
> El 24/01/16 a las 16:51, Michal Suchanek escribió:

> What you are describing here is what it's actually implemented in my patch
> (Well, actually the first patch version because the current one enforces
> bootloader roles).

Actually, no.

Nowhere in the description is any bootloader designated primary or
secondary or first or second. On purpose.

> So what about primary and secondary terms? Or first or
> second terms?

Both are broken and confusing.

>
> These terms are used in two places:
> * Internal variables and functions to handle bootloaders
> * Information shown to the final user
>
> I'm most convinced to use the first and non-first notation. So that the old
> code that referred to LB_BOOTLOADER can just refer to: LB_FIRST_BOOTLOADER.

For what piece of code we have does it make sense to reference
LB_FIRST_BOOTLOADER when not also referencing LB_SECOND_BOOTLOADER?
Will that be extended to LB_THIRD_BOOTLOADER once x86 grows support
for coreboot or l-b grows support for some other platform with many
firmware variants?

If you set bootloaders like

LB_BOOTLOADERS="syslinux grub-efi"

then you can just do

for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo

after you check that you have at most two bootloaders and if you have
more than one then only the latter one ends with -efi.

Thanks

Michal

Message #278 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Michal Suchanek <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 25 Jan 2016 21:33:31 +0100

El 25/01/16 a las 16:12, Michal Suchanek escribió:
> On 25 January 2016 at 03:05, adrian15 <[email protected]> wrote:
>> El 24/01/16 a las 16:51, Michal Suchanek escribió:
>
>> What you are describing here is what it's actually implemented in my patch
>> (Well, actually the first patch version because the current one enforces
>> bootloader roles).
>
> Actually, no.
>
> Nowhere in the description is any bootloader designated primary or
> secondary or first or second. On purpose.
Neither it is on my patch (initial implementation). Yes, the term 
PRIMARY_BOOTLOADER is used there for reusing old code. But using:

--bootloaders=syslinux,grub-efi

did not enforce syslinux to be in the first place or grub-efi to be in 
the second place.

That's the specific part I meant.

>
>> So what about primary and secondary terms? Or first or
>> second terms?
>
> Both are broken and confusing.
Ok...
>>
>> These terms are used in two places:
>> * Internal variables and functions to handle bootloaders
>> * Information shown to the final user
>>
>> I'm most convinced to use the first and non-first notation. So that the old
>> code that referred to LB_BOOTLOADER can just refer to: LB_FIRST_BOOTLOADER.
>
> For what piece of code we have does it make sense to reference
> LB_FIRST_BOOTLOADER when not also referencing LB_SECOND_BOOTLOADER?
> Will that be extended to LB_THIRD_BOOTLOADER once x86 grows support
> for coreboot or l-b grows support for some other platform with many
> firmware variants?
>
> If you set bootloaders like
>
> LB_BOOTLOADERS="syslinux grub-efi"
>
> then you can just do
>
> for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo
Mostly what current path does but with commas instead.
>
> after you check that you have at most two bootloaders and if you have
> more than one then only the latter one ends with -efi.

This is not a good approach. You are requesting the bootloaders to end 
in "-efi". The current approach is to name them based on the Debian 
package name. These packages do not need to end in "-efi".

My use case is the following one. The final user requests:

--bootloaders=grub-efi,syslinux

so I show him:

"Warning. You are using: syslinux as a non first bootloader. This might 
work but it is not advised."

How do I know that I have to output this message?

Because I compare the internal variable:

LB_FIRST_BOOTLOADER="grub-efi"

with the bootloader name "syslinux" and I see they are not the same one.

So, as you see I need to use:

"non first bootloader" term
and
LB_FIRST_BOOTLOADER variable.

So...

1) I don't mind renaming "non first bootloader" or LB_FIRST_BOOTLOADER 
to another terminology which makes more technical sense.
2) I prefer this approach over yours (Michal) because it's the own 
bootloader which decides if it is more suited for "first bootloader" or 
not. Let's not repeat the current binary_iso design which has many 
references to the different available binary_bootloaders available.

>
> Thanks
>
> Michal
>
adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #283 received at [email protected] (full text, mbox, reply):

From: Michal Suchanek <[email protected]>

To: adrian15 <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Tue, 26 Jan 2016 10:18:25 +0100

On 25 January 2016 at 21:33, adrian15 <[email protected]> wrote:
>
>
> El 25/01/16 a las 16:12, Michal Suchanek escribió:
>>
>> On 25 January 2016 at 03:05, adrian15 <[email protected]> wrote:
>>>
>>> El 24/01/16 a las 16:51, Michal Suchanek escribió:
>>
>>
>>> What you are describing here is what it's actually implemented in my
>>> patch
>>> (Well, actually the first patch version because the current one enforces
>>> bootloader roles).
>>
>>
>> Actually, no.
>>
>> Nowhere in the description is any bootloader designated primary or
>> secondary or first or second. On purpose.
>
> Neither it is on my patch (initial implementation). Yes, the term
> PRIMARY_BOOTLOADER is used there for reusing old code. But using:
>
> --bootloaders=syslinux,grub-efi
>
> did not enforce syslinux to be in the first place or grub-efi to be in the
> second place.
>
> That's the specific part I meant.
>
>>
>>> So what about primary and secondary terms? Or first or
>>> second terms?
>>
>>
>> Both are broken and confusing.
>
> Ok...
>>>
>>>
>>> These terms are used in two places:
>>> * Internal variables and functions to handle bootloaders
>>> * Information shown to the final user
>>>
>>> I'm most convinced to use the first and non-first notation. So that the
>>> old
>>> code that referred to LB_BOOTLOADER can just refer to:
>>> LB_FIRST_BOOTLOADER.
>>
>>
>> For what piece of code we have does it make sense to reference
>> LB_FIRST_BOOTLOADER when not also referencing LB_SECOND_BOOTLOADER?
>> Will that be extended to LB_THIRD_BOOTLOADER once x86 grows support
>> for coreboot or l-b grows support for some other platform with many
>> firmware variants?
>>
>> If you set bootloaders like
>>
>> LB_BOOTLOADERS="syslinux grub-efi"
>>
>> then you can just do
>>
>> for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo
>
> Mostly what current path does but with commas instead.

IIRC multivalue options use mostly spaces for separator in l-b so far.

>>
>>
>> after you check that you have at most two bootloaders and if you have
>> more than one then only the latter one ends with -efi.
>
>
> This is not a good approach. You are requesting the bootloaders to end in
> "-efi". The current approach is to name them based on the Debian package
> name. These packages do not need to end in "-efi".

It so happens that bootloaders that support efi are packaged as
packages with -efi suffix (well, except elilo). Maybe there is some
intent there?

However, grub-pc is now split in grub-pc scripts that are meant to
install the bootloader in the system which you probably don't want and
grub-pc-bin which just includes the binaries. The situation is even
more complicated with the 32bit and 64bit efi packages. Also expect
that at some point the maintainers figure out some new completely
awesome way to split the bootloader into packages and then the package
sets will be different in stable/testing/oldstable.

So naming the l-b option *exactly* like the package is not that good idea.

>
> My use case is the following one. The final user requests:
>
> --bootloaders=grub-efi,syslinux
>
> so I show him:
>
> "Warning. You are using: syslinux as a non first bootloader. This might work
> but it is not advised."
>
> How do I know that I have to output this message?

for bootloader in $BOOTLOADERS ; do

    # some bootloader foo

    if echo $BIOS_BOOTLOADERS | grep "${bootloader}" >/dev/null; then
# a fixed list of bootloaders that load through legacy BIOS -
currently should be "syslinux grub-pc" although grub is not well
supported
        case $MEDIA_TYPE in # or whatever the variable
            iso*)
                case "${BOOTLOADERS}" in
                    "${bootloader}"*);;
                    *) echo "Warning: it is recommended to specify
$bootloader first in bootloader list so it gets installed as first
el-torito boot entry."
                        ;;
                esac ;;
        esac
    fi
done


>
> Because I compare the internal variable:
>
> LB_FIRST_BOOTLOADER="grub-efi"
>
> with the bootloader name "syslinux" and I see they are not the same one.
>
> So, as you see I need to use:
>
> "non first bootloader" term

Why that has to be a term? Just say it should come first in the list
of bootloaders if specified at all.

> and
> LB_FIRST_BOOTLOADER variable.

what for?

>
> So...
>
> 1) I don't mind renaming "non first bootloader" or LB_FIRST_BOOTLOADER to
> another terminology which makes more technical sense.
> 2) I prefer this approach over yours (Michal) because it's the own
> bootloader which decides if it is more suited for "first bootloader" or not.

How does it decide that? It can install equally well in 1st, 2nd or
10th el-torito record. The only reason we want BIOS record first is


1) some tools for butchering bootable CDs expect it to be first.

2) it's the traditional place for it (since it was the only record for
a long time) and some ancient BIOSes might potentially break if it's
not first because somebody missed there *can* be multiple entries when
coding them.


So it only has to do with the fact that syslinux is our only well
supported BIOS loader that syslinux should go first. If grub-pc was
installed as BIOS loader it should go first instead. And then you
would have to duplicate that check in grub-pc.

> Let's not repeat the current binary_iso design which has many references to
> the different available binary_bootloaders available.

What's wrong with referencing variables we have so that we  know
what's going on in l-b?

Thanks

Michal

Message #288 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Michal Suchanek <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Tue, 26 Jan 2016 23:20:16 +0100

El 26/01/16 a las 10:18, Michal Suchanek escribió:
>>> If you set bootloaders like
>>>
>>> LB_BOOTLOADERS="syslinux grub-efi"
>>>
>>> then you can just do
>>>
>>> for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo
>>
>> Mostly what current path does but with commas instead.
>
> IIRC multivalue options use mostly spaces for separator in l-b so far.

dba requested it like this. I agree on that criteria for doing so. You 
are not obliged to use quotes when defining bootloaders on the command 
line or scripts.

What are these multivalue options so that I take a look at them? Having 
to deal with IFS it's not ideal but I think using commas it's the way to 
go... although I'm not 100% convinced.

>>> after you check that you have at most two bootloaders and if you have
>>> more than one then only the latter one ends with -efi.
>>
>>
>> This is not a good approach. You are requesting the bootloaders to end in
>> "-efi". The current approach is to name them based on the Debian package
>> name. These packages do not need to end in "-efi".
>
> It so happens that bootloaders that support efi are packaged as
> packages with -efi suffix (well, except elilo). Maybe there is some
> intent there?
>
> However, grub-pc is now split in grub-pc scripts that are meant to
> install the bootloader in the system which you probably don't want and
> grub-pc-bin which just includes the binaries. The situation is even
> more complicated with the 32bit and 64bit efi packages. Also expect
> that at some point the maintainers figure out some new completely
> awesome way to split the bootloader into packages and then the package
> sets will be different in stable/testing/oldstable.
>
> So naming the l-b option *exactly* like the package is not that good idea.
dba commited a change ( 
https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/?id=f93fa286d5e7348150aab4874794f7d96dac0894 
) for that behaviour. I think the reasoning of that was avoid file 
naming collisions in the future because package names are not repeated.

>
>>
>> My use case is the following one. The final user requests:
>>
>> --bootloaders=grub-efi,syslinux
>>
>> so I show him:
>>
>> "Warning. You are using: syslinux as a non first bootloader. This might work
>> but it is not advised."
>>
>> How do I know that I have to output this message?
>
> for bootloader in $BOOTLOADERS ; do
>
>      # some bootloader foo
>
>      if echo $BIOS_BOOTLOADERS | grep "${bootloader}" >/dev/null; then
> # a fixed list of bootloaders that load through legacy BIOS -
> currently should be "syslinux grub-pc" although grub is not well
> supported
>          case $MEDIA_TYPE in # or whatever the variable
>              iso*)
>                  case "${BOOTLOADERS}" in
>                      "${bootloader}"*);;
>                      *) echo "Warning: it is recommended to specify
> $bootloader first in bootloader list so it gets installed as first
> el-torito boot entry."
>                          ;;
>                  esac ;;
>          esac
>      fi
> done
Here you are creating a new variable: $BIOS_BOOTLOADERS which will have 
to be updated manually each time a new bios bootloader binary_ file is 
added.

The grep part should be improved to avoid problems (e.g. syslinux is 
inside syslinux-efi).

>> Because I compare the internal variable:
>>
>> LB_FIRST_BOOTLOADER="grub-efi"
>>
>> with the bootloader name "syslinux" and I see they are not the same one.
>>
>> So, as you see I need to use:
>>
>> "non first bootloader" term
>
> Why that has to be a term? Just say it should come first in the list
> of bootloaders if specified at all.

"It should come first". "It should not come first". Ok. I can do that 
and ditch the "non first bootloader" or "first bootloader" from my messages.

>
>> and
>> LB_FIRST_BOOTLOADER variable.
>
> what for?

For two reasons:

1) Being able to use current live-build code which used LB_BOOTLOADER in 
the past.

Check what it's in current alioth git (Seach for LB_PRIMARY_BOOTLOADER 
on there):

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_hdd?id=1ccb41623046f2a8f823d62a5f417cdae724c22b

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_iso?id=1ccb41623046f2a8f823d62a5f417cdae724c22b

https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/functions/defaults.sh?id=1ccb41623046f2a8f823d62a5f417cdae724c22b

2) Not having to use awk each time I need to compare a first / default 
bootloader... when I can just use a variable with previous (once only) 
calculated value.


>> So...
>>
>> 1) I don't mind renaming "non first bootloader" or LB_FIRST_BOOTLOADER to
>> another terminology which makes more technical sense.
>> 2) I prefer this approach over yours (Michal) because it's the own
>> bootloader which decides if it is more suited for "first bootloader" or not.
>
> How does it decide that? It can install equally well in 1st, 2nd or
> 10th el-torito record. The only reason we want BIOS record first is

Inside the binary_bootloader file by running a function that shows that 
warning. The author of the binary_bootloader it's who decides where it's 
advised to go.

The final place where it goes depends on the order here:

--bootloaders="syslinux,grub-efi"

I mean, the final user can decide the order but if it's not optimal he 
gets a warning.

> 1) some tools for butchering bootable CDs expect it to be first.
>
> 2) it's the traditional place for it (since it was the only record for
> a long time) and some ancient BIOSes might potentially break if it's
> not first because somebody missed there *can* be multiple entries when
> coding them.
>
>
> So it only has to do with the fact that syslinux is our only well
> supported BIOS loader that syslinux should go first. If grub-pc was
> installed as BIOS loader it should go first instead. And then you
> would have to duplicate that check in grub-pc.
I don't see a problem here. I can do that thanks to the magic of 
functions that let me repeat code with only one line. I already did that 
in the last version of the patch.

( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#233 - In that 
version I thought I had to enforce boot order because not doing so it 
was going to produce non bootable isos. Now I'm convinced that using non 
standard boot order do not produce non bootable isos thus a warning 
instead of stopping live build is ok. )

>> Let's not repeat the current binary_iso design which has many references to
>> the different available binary_bootloaders available.
>
> What's wrong with referencing variables we have so that we  know
> what's going on in l-b?
>
> Thanks
>
> Michal

Well, basically, my design rationale behind this is that with the 
current way of doing things you need to update binary_iso file each time 
a new bootloader is added.

With what I'm proposing you you wouldn't have to update it. And if a new 
bootloader might ever need binary_iso to be modified then every 
bootloader might benefit from that architecture enhancement.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #293 received at [email protected] (full text, mbox, reply):

From: Michal Suchanek <[email protected]>

To: adrian15 <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Wed, 27 Jan 2016 19:00:14 +0100

On 26 January 2016 at 23:20, adrian15 <[email protected]> wrote:
> El 26/01/16 a las 10:18, Michal Suchanek escribió:

>>
>>>
>>> My use case is the following one. The final user requests:
>>>
>>> --bootloaders=grub-efi,syslinux
>>>
>>> so I show him:
>>>
>>> "Warning. You are using: syslinux as a non first bootloader. This might
>>> work
>>> but it is not advised."
>>>
>>> How do I know that I have to output this message?
>>
>>
>> for bootloader in $BOOTLOADERS ; do
>>
>>      # some bootloader foo
>>
>>      if echo $BIOS_BOOTLOADERS | grep "${bootloader}" >/dev/null; then
>> # a fixed list of bootloaders that load through legacy BIOS -
>> currently should be "syslinux grub-pc" although grub is not well
>> supported
>>          case $MEDIA_TYPE in # or whatever the variable
>>              iso*)
>>                  case "${BOOTLOADERS}" in
>>                      "${bootloader}"*);;
>>                      *) echo "Warning: it is recommended to specify
>> $bootloader first in bootloader list so it gets installed as first
>> el-torito boot entry."
>>                          ;;
>>                  esac ;;
>>          esac
>>      fi
>> done
>
> Here you are creating a new variable: $BIOS_BOOTLOADERS which will have to
> be updated manually each time a new bios bootloader binary_ file is added.

So what? Any other way to recognize a BIOS bootloader as such?

>
> The grep part should be improved to avoid problems (e.g. syslinux is inside
> syslinux-efi).

Except $BIOS_BOOTLOADERS does not include syslinux-efi so it does not happen ;-)

>
>>> Because I compare the internal variable:
>>>
>>> LB_FIRST_BOOTLOADER="grub-efi"
>>>
>>> with the bootloader name "syslinux" and I see they are not the same one.
>>>
>>> So, as you see I need to use:
>>>
>>> "non first bootloader" term
>>
>>
>> Why that has to be a term? Just say it should come first in the list
>> of bootloaders if specified at all.
>
>
> "It should come first". "It should not come first". Ok. I can do that and
> ditch the "non first bootloader" or "first bootloader" from my messages.
>
>>
>>> and
>>> LB_FIRST_BOOTLOADER variable.
>>
>>
>> what for?
>
>
> For two reasons:
>
> 1) Being able to use current live-build code which used LB_BOOTLOADER in the
> past.
>
> Check what it's in current alioth git (Seach for LB_PRIMARY_BOOTLOADER on
> there):
>
> https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_hdd?id=1ccb41623046f2a8f823d62a5f417cdae724c22b
>
> https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_iso?id=1ccb41623046f2a8f823d62a5f417cdae724c22b
>
> https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/functions/defaults.sh?id=1ccb41623046f2a8f823d62a5f417cdae724c22b

Skimming through that code in every place LB_PRIMARY_BOOTLOADER is
used the code is broken.

If a bootloader is requested then you should install its files/check
that the filesystem is compatible/... regardless of the el-torito
record number it is installed in.

>
> 2) Not having to use awk each time I need to compare a first / default
> bootloader... when I can just use a variable with previous (once only)
> calculated value.

Which if used correctly would be used once or twice if at all.

Thanks

Michal

Message #298 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Michal Suchanek <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 21 Mar 2016 21:09:40 +0100

[Message part 1 (text/plain, inline)]

This is my updated set of patches.

Changes since last set of patches:

* Renamed primary and secondary to first and extra terms.
* Forced insmod all_video command in grub.cfg to avoid problems in UEFI 
mode.
* Minor changes

Rescatux 0.40b6 which I will release soon will feature this branch which 
include these changes:

https://github.com/rescatux/live-build/tree/rescatux-0.40b6

.

The branch which include specifically the commits I attach here as 
patches is:

https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5

.

About the variable names issue: I think the new terms: first and extra 
are ok because they are not implying some sort of rank while explaining 
what's the difference between them. Also, notice, that these are 
internal variables which final user of live-build does not see. I think 
we should focus on other aspects of my patch if there are more problems 
for it.

If you think that the way bootloaders is currently managed by live-build 
is wrong please file up a new bug and send there your patch with your 
improvements so that it's get discussed.

Then, if it gets approved I can improve my patch over yours.

My patch tries to make the minimum improvements so that other live-build 
functionality does not get affected by it.

Let's please focus on getting this set of patches accepted. Don't get me 
wrong I'm not asking for a carte blanche but, let's focus on other 
aspects from the patch. (E.g. please test it on actual hardware, in your 
distro builds, even if you don't use UEFI does the ISO boot as always in 
BIOS mode?) And give us feedback on it.

Thank you.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

[0001-functions-default.sh-Define-LB_PRIMARY_BOOTLOADER-at.patch (text/x-patch, attachment)]

[0002-Remove-repeated-LB_PRIMARY_BOOTLOADER-definition.patch (text/x-patch, attachment)]

[0003-Added-functions-bootloaders.sh-.-It-has-new-bootload.patch (text/x-patch, attachment)]

[0004-binary_loopback_cfg-now-renders-grub.cfg-by-default.patch (text/x-patch, attachment)]

[0005-Stolen-efi-image-and-grub-cpmodules-from-src-live-in.patch (text/x-patch, attachment)]

[0006-Support-for-EFI-support-by-the-means-of-grub-efi.patch (text/x-patch, attachment)]

[0007-defaults.sh-LB_BOOTLOADER-updated-to-be-LB_BOOTOADER.patch (text/x-patch, attachment)]

[0008-Many-binary-bootloaders-were-rewritten-to-make-use-o.patch (text/x-patch, attachment)]

[0009-Make-syslinux-grub-efi-the-default-bootloaders-becau.patch (text/x-patch, attachment)]

[0010-Force-the-use-of-insmod-all_video-in-grub.cfg-so-tha.patch (text/x-patch, attachment)]

Message #303 received at [email protected] (full text, mbox, reply):

From: Michal Suchanek <[email protected]>

To: adrian15 <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 21 Mar 2016 22:19:19 +0100

Hello,

On 21 March 2016 at 21:09, adrian15 <[email protected]> wrote:

>
> The branch which include specifically the commits I attach here as patches
> is:
>
> https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5
>
> .
>
> About the variable names issue: I think the new terms: first and extra are
> ok because they are not implying some sort of rank while explaining what's
> the difference between them. Also, notice, that these are internal variables
> which final user of live-build does not see. I think we should focus on
> other aspects of my patch if there are more problems for it.

The problem is not with the name of the variable.

The problem is that you use it at all. In most places when you check
for primary or secondary bootloader you should just loop all
bootloaders and check each. In fact, in the previous batch of patches
I found no place where checking for primary or secondary bootloader
made any sense.

>
> If you think that the way bootloaders is currently managed by live-build is
> wrong please file up a new bug and send there your patch with your
> improvements so that it's get discussed.

The bootloader support in live-build is limited. With your patches it
becomes wrong. eg. compatibility of bootloader with selected
filesystem and image type is only checked for first bootloader and EFI
support is added only when grub-efi extra bootloader but not when it
is the first bootloader.

This is not fixed by renaming the variables.

Thanks

Michal

Message #308 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Michal Suchanek <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Mon, 21 Mar 2016 23:06:37 +0100

El 21/03/16 a las 22:19, Michal Suchanek escribió:
> Hello,
>
> On 21 March 2016 at 21:09, adrian15 <[email protected]> wrote:
>
>>
>> The branch which include specifically the commits I attach here as patches
>> is:
>>
>> https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5
>>
>> .
>>
>> About the variable names issue: I think the new terms: first and extra are
>> ok because they are not implying some sort of rank while explaining what's
>> the difference between them. Also, notice, that these are internal variables
>> which final user of live-build does not see. I think we should focus on
>> other aspects of my patch if there are more problems for it.
>
> The problem is not with the name of the variable.
>
> The problem is that you use it at all. In most places when you check
> for primary or secondary bootloader you should just loop all
> bootloaders and check each. In fact, in the previous batch of patches
> I found no place where checking for primary or secondary bootloader
> made any sense.
>
>>
>> If you think that the way bootloaders is currently managed by live-build is
>> wrong please file up a new bug and send there your patch with your
>> improvements so that it's get discussed.
>
> The bootloader support in live-build is limited. With your patches it
> becomes wrong. eg. compatibility of bootloader with selected
> filesystem and image type is only checked for first bootloader and EFI
> support is added only when grub-efi extra bootloader but not when it
> is the first bootloader.
>
> This is not fixed by renaming the variables.

Ok. So I recognise that my patch:

* Adds a limited support of UEFI only available when it's used as an 
extra bootloader
* Does not check compatibility with selected filesystem in the extra 
bootloader because it blindly relies on selected filesystem selected in 
first bootloader being compatible with the extra bootloader too.
* It does not work for hdd binaries (only iso binaries)

and it does in addition to what live-build already did.

I also think that my patch does not remove the current live-build 
functionality and if that happens I want to know about it.

Yes, my patch does not bring UEFI complete support, but a minimal one. 
So according to you the many changes I make on the bootloader functions 
do not compensate the minimal UEFI support I add to live-build?

Thank you.

adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Message #313 received at [email protected] (full text, mbox, reply):

From: adrian15 <[email protected]>

To: Michal Suchanek <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Tue, 22 Mar 2016 02:54:46 +0100

[Message part 1 (text/plain, inline)]

El 21/03/16 a las 22:19, Michal Suchanek escribió:
> Hello,
>
> On 21 March 2016 at 21:09, adrian15 <[email protected]> wrote:
>
>>
>> The branch which include specifically the commits I attach here as patches
>> is:
>>
>> https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_5
>>
>> .
>>
>> About the variable names issue: I think the new terms: first and extra are
>> ok because they are not implying some sort of rank while explaining what's
>> the difference between them. Also, notice, that these are internal variables
>> which final user of live-build does not see. I think we should focus on
>> other aspects of my patch if there are more problems for it.
>
> The problem is not with the name of the variable.
>
> The problem is that you use it at all. In most places when you check
> for primary or secondary bootloader you should just loop all
> bootloaders and check each. In fact, in the previous batch of patches
> I found no place where checking for primary or secondary bootloader
> made any sense.
>
>>
>> If you think that the way bootloaders is currently managed by live-build is
>> wrong please file up a new bug and send there your patch with your
>> improvements so that it's get discussed.
>
> The bootloader support in live-build is limited. With your patches it
> becomes wrong. eg. compatibility of bootloader with selected
> filesystem and image type is only checked for first bootloader and EFI
> support is added only when grub-efi extra bootloader but not when it
> is the first bootloader.
>
> This is not fixed by renaming the variables.
>
> Thanks
>
> Michal

Ok, what about now? Actually from my former email I only added one 
additional patch (0011) with some sort of modular support for bootloaders.

There probably needs some work to be done on binary_hdd but I first 
wanted to gather information on what to improve on this last patch.


https://github.com/rescatux/live-build/tree/efi_support_based_on_debian_cd_rebased_6


adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

[0001-functions-default.sh-Define-LB_PRIMARY_BOOTLOADER-at.patch (text/x-patch, attachment)]

[0002-Remove-repeated-LB_PRIMARY_BOOTLOADER-definition.patch (text/x-patch, attachment)]

[0003-Added-functions-bootloaders.sh-.-It-has-new-bootload.patch (text/x-patch, attachment)]

[0004-binary_loopback_cfg-now-renders-grub.cfg-by-default.patch (text/x-patch, attachment)]

[0005-Stolen-efi-image-and-grub-cpmodules-from-src-live-in.patch (text/x-patch, attachment)]

[0006-Support-for-EFI-support-by-the-means-of-grub-efi.patch (text/x-patch, attachment)]

[0007-defaults.sh-LB_BOOTLOADER-updated-to-be-LB_BOOTOADER.patch (text/x-patch, attachment)]

[0008-Many-binary-bootloaders-were-rewritten-to-make-use-o.patch (text/x-patch, attachment)]

[0009-Make-syslinux-grub-efi-the-default-bootloaders-becau.patch (text/x-patch, attachment)]

[0010-Force-the-use-of-insmod-all_video-in-grub.cfg-so-tha.patch (text/x-patch, attachment)]

[0011-binary_grub-efi-works-as-a-first-bootloader-and-as-a.patch (text/x-patch, attachment)]

Message #318 received at [email protected] (full text, mbox, reply):

From: Michal Suchanek <[email protected]>

To: adrian15 <[email protected]>

Cc: Thomas Schmitt <[email protected]>, [email protected], Raphaël Hertzog <[email protected]>, jnq nfe <[email protected]>, Gaudenz Steinlin <[email protected]>, hhh orb <[email protected]>

Subject: Re: Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

Date: Tue, 22 Mar 2016 07:18:30 +0100

On 21 March 2016 at 23:06, adrian15 <[email protected]> wrote:
> El 21/03/16 a las 22:19, Michal Suchanek escribió:
>

>> The bootloader support in live-build is limited. With your patches it
>> becomes wrong. eg. compatibility of bootloader with selected
>> filesystem and image type is only checked for first bootloader and EFI
>> support is added only when grub-efi extra bootloader but not when it
>> is the first bootloader.
>>
>> This is not fixed by renaming the variables.
>
>
> Ok. So I recognise that my patch:
>
> * Adds a limited support of UEFI only available when it's used as an extra
> bootloader
> * Does not check compatibility with selected filesystem in the extra
> bootloader because it blindly relies on selected filesystem selected in
> first bootloader being compatible with the extra bootloader too.
> * It does not work for hdd binaries (only iso binaries)
>
> and it does in addition to what live-build already did.

No, it does not.

live-build only installed bootloader which was compatible with
selected filesystem and image type which is no longer true with your
patch. In fact, if I choose grub-efi as first bootloader the efi
support is not added and compatibility of any extra bootloaders with
the filesystem chosen is not checked so the image may be completely
unbootable.

So please consider either

1) fixing your current patch so there is no primary or first
bootloader and all installed bootloaders are equal

2) don't pretend you add support for multiple bootloaders when you are
not wiling to do so and just and some option like --bolt-on-grub-efi
which installs grub-efi if image type and filesystem is compatible
with grub-efi and fails the build otherwise

BTW it has been pointed out already that -eltorito-alt-boot is just
separator that starts new boot entry so there are no special
secondary/extra bootloader options. Any bootloader can be
first/second/third/whatever.

Thanks

Michal

Send a report that this bug log contains spam.