xorriso and EFI boot images

xorriso and EFI boot images

[Thomas Schmitt]

Hi,

i took a look at grub-mkrescue.in with EFI and
implemented the EFI-only case in xorriso-0.5.5
timestamp 2010.04.20.103448:

  --efi-boot FILE        Set El Torito EFI boot image name and type

Currently -b and --efi-boot override each other.
Who comes last will win.
--efi-boot is not yet immune against subsequent
-boot-info-table. It disables eventual previous
-boot-info-table, though.

Due to an allergic reaction in libisofs, older
versions of xorriso are not be able to load
ISO images with boot catalog signature other than
0 ("80x86").

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


Next i will have to extend the libisofs model of
a single boot image to a model that can represent
an El Torito Multiple Boot-Image configuration.


But i have scruples about the semantics of
Platform ID which is global to the whole boot
catalog. Is platform 0xef meant to be a superset
of platform 0x00 ?

If not, then it might violate the El Torito model
if we mix PC BIOS and EFI boot images.

If yes: how do platforms 0x01 (Power PC) and
0x02 (Mac) fit in there ?

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


Development of grub-mkrescue and xorriso:

Since we develop and fulfill new demands of
grub-mkrescue towards xorriso, we will need a
way to detect whether the locally installed
xorriso is able to fulfill them.

I can offer two ways for that:

- xorriso -version
  reports lines
    xorriso version   :  0.5.4
    Version timestamp :  2010.04.19.080001
  by which one can determine the development
  state.

- xorriso -as mkisofs -help 2>&1
  reports available commands.
  My own test version of grub-mkrescue 1.98 uses
  this to handle genisoimage, grub-mkisofs and
  xorriso.
  This method is also used by my tool scdbackup
  for using a mkisofs range of 10 years, and a
  xorriso range of 2 years.


Have a nice day :)

Thomas

Re: xorriso and EFI boot images

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2558 bytes --]

Thomas Schmitt wrote:
> Hi,
>
> i took a look at grub-mkrescue.in with EFI and
> implemented the EFI-only case in xorriso-0.5.5
> timestamp 2010.04.20.103448:
>
>   
Thanks, will test it later today.
>   --efi-boot FILE        Set El Torito EFI boot image name and type
>
> Currently -b and --efi-boot override each other.
> Who comes last will win.
> --efi-boot is not yet immune against subsequent
> -boot-info-table. It disables eventual previous
> -boot-info-table, though.
>
> Due to an allergic reaction in libisofs, older
> versions of xorriso are not be able to load
> ISO images with boot catalog signature other than
> 0 ("80x86").
>
> ------------------------------------------------
>
>
> Next i will have to extend the libisofs model of
> a single boot image to a model that can represent
> an El Torito Multiple Boot-Image configuration.
>
>
> But i have scruples about the semantics of
> Platform ID which is global to the whole boot
> catalog. 
It's not. The value in validation entry applies only to default image.
Section header specifies the platform id of section entry (byte 1 of
section header entry)
> If yes: how do platforms 0x01 (Power PC) and
> 0x02 (Mac) fit in there ?
>
>   
I wonder how these platform fit in spec at all. AFAIR PowerPC Macs use
HFS(+). Idr seeing any eltorito PPC Mac bootable CDs.
> -------------------------------------------------
>
>
> Development of grub-mkrescue and xorriso:
>
> Since we develop and fulfill new demands of
> grub-mkrescue towards xorriso, we will need a
> way to detect whether the locally installed
> xorriso is able to fulfill them.
>
>   

> I can offer two ways for that:
>
> - xorriso -version
>   reports lines
>     xorriso version   :  0.5.4
>     Version timestamp :  2010.04.19.080001
>   by which one can determine the development
>   state.
>
> - xorriso -as mkisofs -help 2>&1
>   reports available commands.
>   My own test version of grub-mkrescue 1.98 uses
>   this to handle genisoimage, grub-mkisofs and
>   xorriso.
>   This method is also used by my tool scdbackup
>   for using a mkisofs range of 10 years, and a
>   xorriso range of 2 years.
>
>   
What about checking error status of xorrisofs --foo -o dummy.iso dummy/ ?
> Have a nice day :)
>
> Thomas
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: xorriso and EFI boot images

[Thomas Schmitt]

Hi,

> > i have scruples about the semantics of
> > Platform ID which is global to the whole boot
> > catalog.
> Section header specifies the platform id of section entry 

Oh. Somehow i oversaw that.


> > [detection of capabilities of xorriso version]
> What about checking error status of xorrisofs --foo -o dummy.iso dummy/ ?

That should work too, of course.

xorriso allows to define severity threshholds
for abort, for exit values with problematic
runs which did not get aborted, and for
verbosity. E.g.:

  xorriso -abort_on FAILURE \
          -return_with WARNING 32 \
          -report_about HINT \
          -as mkisofs ...

If we let the user interpret the complaints of
xorriso then we should make it rather unverbous.
Severity HINT is one notch lower than severity
WARNING. No NOTE or UPDATE messages will appear.


Using
  xorriso ... -as mkisofs ...
rather than
  xorrisofs ...
has several advantages.
One can use its own richer option set before
switching to mkisofs emulation, and one can
easily use not-installed xorriso binaries, like
  /home/me/xorriso-0.x.y/xorriso/xorriso


Have a nice day :)

Thomas

Re: xorriso and EFI boot images

[Thomas Schmitt]

Hi,

the fresh development upload of xorriso-0.5.5
with timestamp 2010.04.22.160615 implements the
wish about --efi-boot :

Vladimir Serbinenko wrote 17 Apr 2010:
> I would like to have efi+bios cd with 2 eltorito
> entries: one with platformid=0 and another one with platformid=0xef.
> [...]
> I would like that on hybrid BIOS always come in
> default entry to avoid hitting BIOS bugs
> In case of just EFI the Section header entry and Section entry become
> Validation entry and default entry.

So now xorriso -as mkisofs has this provisory
behavior:

-b is for 80x86 BIOS images, platform ID 0.
Options -boot-load-size, -no-emul-boot,
-boot-info-table affect this -b boot image.

--efi-boot is for EFI images, platform id 0xef.
Hardcoded are: no emulation, no boot info table.
The load size is obtained from the size of the
EFI image file and rounded up to full 512 byte
blocks.

Prone to change is the current rule that the
EFI image always is second if a BIOS image is
present. I will probably make this depending on
the sequence of options in future.
Please take care in grub-mkrescue to express
your desired sorting by giving -b before
--efi-boot.

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


Quote from El Torito 1.0 paragraph 2.3
"The section header has an identification string.
 If the BIOS understands the ID, string it may
 choose to boot the system using one of these
 entries in place of the INITIAL/DEFAULT entry."

What does that mean: "the BIOS understands" ?
Do we have to write something particular in
there for EFI ?
Any idea what one would have to write in case of
a 80x86-BIOS image ?

The Validation Entry has an ID too.
But that is defined as quite meaningless:
"This is intended to identify the
 manufacturer/developer of the CD-ROM."

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


Currently libisofs is able to write and read up
to 32 boot images. It writes each image entry
into an own section, but i plan to allow sections
of more than one image entry and user provided
ID strings.

xorriso on the other hand got only a primitive
extension efi_path, which lives beneath bin_path.
This is not flexible. So i plan for improvements.
Nevertheless, the option sequence
  -b ... --efi-boot ...
is promised to always lead to Vladimir's intended
boot catalog structure.

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


I tested with dummy boot images.
The boot catalog entries seem to be ok.
Now i am curious whether i misunderstood the
specs somewhere or whether it really would boot.


Have a nice day :)

Thomas

Re: xorriso and EFI boot images

[Seth Goldberg]

Quoting Thomas Schmitt, who wrote the following on Thu, 22 Apr 2010:

> Hi,
>
> the fresh development upload of xorriso-0.5.5
> with timestamp 2010.04.22.160615 implements the
> wish about --efi-boot :

  BTW, See Fedora's genisoimage for a good example of how they do it. (And this 
page that references mkisofs as the command (which they clearly changed to 
genisoimage)): 
http://fedoraproject.org/wiki/User:Pjones/BootableCDsForBIOSAndUEFI

  --S

Re: xorriso and EFI boot images

[Seth Goldberg]

> Prone to change is the current rule that the EFI image always is second if a 
> BIOS image is present. I will probably make this depending on the sequence 
> of options in future. Please take care in grub-mkrescue to express your 
> desired sorting by giving -b before --efi-boot.

   For maximum compatibility, the BIOS entry (platform id 0) should be first. 
There are BIOSes out there do not traverse the entire catalog, so sorting 
with platform id 0 first should be the documented default.

  --S

Re: xorriso and EFI boot images

[Thomas Schmitt]

Hi,

Seth Goldberg wrote:
> BTW, See Fedora's genisoimage for a good example of how they do it.
> http://fedoraproject.org/wiki/User:Pjones/BootableCDsForBIOSAndUEFI

Thanks for the hint.
Ahum ...
  -eltorito-alt-boot -e images/efiboot.img -no-emul-boot

In man mkisofs of 2.01.01a64 and in
  http://svn.debian.org/wsvn/debburn/cdrkit/trunk/genisoimage/genisoimage.1
i see
  -eltorito-alt-boot
but not
  -e
So the latter is probably a Fedora extension to
mkisofs.

The description is very similar to what i
implemented as --efi-boot.
But -no-emul-boot is implied by --efi-boot and
we are not in sync with the size of sectors:
The web page talks of 2048 where i use 512.

As far as El Torito 1.0 is concerned, the case is
clear: Figure 5 - Section Entry talks of
"virtual/emulated sectors". Paragraph 1.5 defines
a Virtual Sector as [0x]200 bytes. A CD sector is
[0x]800.
But is EFI following this convention ?


Vladimir ? 512 or 2048 ?


Since -eltorito-alt-boot is part of original
mkisofs i will use the same option for my
emulation.
It will be implicit with --efi-boot.

I will have to ponder about implementing
option -e .
Anybody has a man page where it is described ?


> For maximum compatibility, the BIOS entry (platform id 0) should be first.

Well, it seems that option -eltorito-alt-boot
gives the user the freedom to do it different.
Since it is easy to do it right, i am in doubt
whether it is worth to force the user.


Have a nice day :)

Thomas
 

Re: xorriso and EFI boot images

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]


Thomas Schmitt wrote:
> Hi,
>
> the fresh development upload of xorriso-0.5.5
> with timestamp 2010.04.22.160615 implements the
> wish about --efi-boot :
>
>   
I've tested xorriso version   :  0.5.5 Version timestamp : 
2010.04.22.221241 and it worked fine.

> Vladimir Serbinenko wrote 17 Apr 2010:
>   
>> I would like to have efi+bios cd with 2 eltorito
>> entries: one with platformid=0 and another one with platformid=0xef.
>> [...]
>> I would like that on hybrid BIOS always come in
>> default entry to avoid hitting BIOS bugs
>> In case of just EFI the Section header entry and Section entry become
>> Validation entry and default entry.
>>     
>
> So now xorriso -as mkisofs has this provisory
> behavior:
>
> -b is for 80x86 BIOS images, platform ID 0.
> Options -boot-load-size, -no-emul-boot,
> -boot-info-table affect this -b boot image.
>
> --efi-boot is for EFI images, platform id 0xef.
> Hardcoded are: no emulation, no boot info table.
> The load size is obtained from the size of the
> EFI image file and rounded up to full 512 byte
> blocks.
>
> Prone to change is the current rule that the
> EFI image always is second if a BIOS image is
> present. I will probably make this depending on
> the sequence of options in future.
> Please take care in grub-mkrescue to express
> your desired sorting by giving -b before
> --efi-boot.
>
>   
It's already so.
> ------------------------------------------------
>
>
> Quote from El Torito 1.0 paragraph 2.3
> "The section header has an identification string.
>  If the BIOS understands the ID, string it may
>  choose to boot the system using one of these
>  entries in place of the INITIAL/DEFAULT entry."
>
>   
> What does that mean: "the BIOS understands" ?
> Do we have to write something particular in
> there for EFI ?
> Any idea what one would have to write in case of
> a 80x86-BIOS image ?
>   
It looks like ISOs I had under the hand with multiple boot images just
zero-fill this field.

> The Validation Entry has an ID too.
> But that is defined as quite meaningless:
> "This is intended to identify the
>  manufacturer/developer of the CD-ROM."
>
>   
Actualy it seems like it can be an arbitrary string and BIOS doesn't
care about it. Just setting it to all zeros is ok. Looking at few isos I
had under the hand:
FreeBSD ISOs: "The FreeBSD Project.  h"
NetBSD: ""
DEbian GNU/Hurd: ""


>   
> ------------------------------------------------
>
>
> Currently libisofs is able to write and read up
> to 32 boot images. It writes each image entry
> into an own section, but i plan to allow sections
> of more than one image entry and user provided
> ID strings.
>
> xorriso on the other hand got only a primitive
> extension efi_path, which lives beneath bin_path.
> This is not flexible. So i plan for improvements.
> Nevertheless, the option sequence
>   -b ... --efi-boot ...
> is promised to always lead to Vladimir's intended
> boot catalog structure.
>
> ------------------------------------------------
>
>
> I tested with dummy boot images.
> The boot catalog entries seem to be ok.
> Now i am curious whether i misunderstood the
> specs somewhere or whether it really would boot.
>
>
> Have a nice day :)
>
> Thomas
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: xorriso and EFI boot images

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

> The description is very similar to what i
> implemented as --efi-boot.
> But -no-emul-boot is implied by --efi-boot and
> we are not in sync with the size of sectors:
> The web page talks of 2048 where i use 512.
>
> As far as El Torito 1.0 is concerned, the case is
> clear: Figure 5 - Section Entry talks of
> "virtual/emulated sectors". Paragraph 1.5 defines
> a Virtual Sector as [0x]200 bytes. A CD sector is
> [0x]800.
> But is EFI following this convention ?
>
>
> Vladimir ? 512 or 2048 ?
>
>  =20
I suppose it's 512. At least how it is now it works.
> Since -eltorito-alt-boot is part of original
> mkisofs i will use the same option for my
> emulation.
> It will be implicit with --efi-boot.
>
> I will have to ponder about implementing
> option -e .
> Anybody has a man page where it is described ?
>
>
>  =20
which probably just is "set platform-id to 0xef"



--=20
Regards
Vladimir '=CF=86-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: xorriso and EFI boot images

[Thomas Schmitt]

Hi,

Vladimir Serbinenko:
> I've tested xorriso version   :  0.5.5 Version timestamp : 
> 2010.04.22.221241 and it worked fine.

So my Sector Count unit of 512 bytes is ok
until other info emerges. (The Fedora wiki
gave me doubts.)

I am busily refactoring the xorriso level of
boot options. This will finally impose another
round of regression tests.
I'll give you a note when i am done with mine.


> > Please take care in grub-mkrescue to express
> > your desired sorting by giving -b before
> > --efi-boot.
> It's already so.

So i can join the behavior of mkisofs and
genisoimage that the sequence of -b and
-eltorito-alt-boot defines the sequence of
boot image entries in the boot catalog.

--efi-boot FILE will be documented as being
virtually enclosed in -eltorito-alt-boot options.
I.e. 

  -b ... boot.options \
  --efi-boot FILE \
  ...

will be the same as

  -b ... boot.options \
  -eltorito-alt-boot \
  --efi-boot FILE \
  -eltorito-alt-boot \
  ...

No boot option like -boot-info-table will have a
chance to be attributed to --efi-boot.


> > "The section header has an identification string.
> It looks like ISOs I had under the hand with multiple boot images just
> zero-fill this field.

I have implemented setting of ID String and
Selection Criteria in libisofs and in the own
command interface of xorriso.
So if we ever need it ... :)


> > I will have to ponder about implementing
> > option -e .
> which probably just is "set platform-id to 0xef"

I wrote to the author of that wiki article.
No answer yet.
Googling brought no insight either.

Any Fedora users here ?
What does  mkisofs -help  say ?


Have a nice day :)

Thomas

Re: xorriso and EFI boot images

[Thomas Schmitt]

Hi,

i have uploaded
  http://www.gnu.org/software/xorriso/xorriso-0.5.5.tar.gz
with version timestamp 2010.04.29.133234.
It can now process up to 32 different boot
images, with all El Torito parameters
adjustable (if anybody finds a use for them).

This is a release candidate as far as boot images
are concerned.

So please make regression tests with your use
cases and operating systems, whether it compiles
and whether it produces bootable ISO 9660 images.

I made own GRUB 1.98 tests on GNU/Linux with
CD-RW, DVD+RW, and USB stick. Single-session and
multi-session. What i cannot test yet is EFI.
I only know that the EFI entries in the boot
catalog look theoretically ok and that EFI
boot images were not patched by a boot info
table.

Release of xorriso-0.5.6 is planned in about a
week, if no obstacles or urgent last-minute
wishes arise.


Have a nice day :)

Thomas