Re: [Bug-xorriso] Test Proposal for [bug #46716] Protective MBR partition is not marked as bootable

[Thomas Schmitt]

Hi,

Andrei Borzenkov wrote:
> [proposal how to define synthetic partition entries]
> Otherwise the most safe approach is probably based on design of mjg

... which does not comply to EFI specs.
Its trick is that any misunderstanding by the firmware shall
finally end up at the same address where the correct interpretation
would end up.


> MBR with single ESP
> GPT with single ESP
> APM with ESP, HFS+

I experimented with libisofs source and was able to produce this
layout by replacing option
  -efi-boot-part --efi-boot-image
by

  -append_partition 1 0xef ...disk.path.../efi.img

where efi.img is the El Torito EFI boot image and ESP.
(I will explain below why at least APM with HFS+ needs this copy
 for now.)

Further i had to add after "-e /efi.img" this option:

  -isohybrid-gpt-basdat

in order to trigger GPT production at all.

The experimental behavior is enabled by macro definition

  export CPPFLAGS="-DLibisofs_mjg_boot_for_grub2"

before the run of

  ./configure && make clean && make

The xorriso run shown below then yields:

  System area summary: MBR GPT APM
  ISO image size/512 : 32204
  Partition offset   : 0

  MBR heads per cyl  : 64
  MBR secs per head  : 32
  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x00  0xef        32204         5760

  GPT                :   N  Info
  GPT disk GUID      :      c21f87d201a3c947bc1900c6ccc80351
  GPT entry array    :      16  192  separated
  GPT lba range      :      64  37966  38015
  GPT partition name :   1  490053004f004800790062007200690064003100
  GPT partname local :   1  ISOHybrid1
  GPT partition GUID :   1  c21f87d201a3c947bc1b00c6ccc80351
  GPT type GUID      :   1  a2a0d0ebe5b9334487c068b6b72699c7
  GPT partition flags:   1  0x1000000000000001
  GPT start and size :   1  980  5760
  GPT partition path :   1  /efi.img

  APM                :   N  Info
  APM block size     :      2048
  APM gap fillers    :      0
  APM partition name :   1  HFSPLUS_Hybrid
  APM partition type :   1  Apple_HFS
  APM start and size :   1  84  7967
  APM partition name :   2  Appended1
  APM partition type :   2  Data
  APM start and size :   2  8051  1440

  El Torito catalog  : 229  1
  El Torito cat path : /boot.catalog
  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz         LBA
  El Torito boot img :   1  BIOS  y   none  0x0000  0x00      4         230
  El Torito boot img :   2  UEFI  y   none  0x0000  0x00   5760         245
  El Torito img path :   1  /boot/grub/i386-pc/eltorito.img
  El Torito img opts :   1  boot-info-table grub2-boot-info
  El Torito img path :   2  /efi.img


The experimental macros
  -DLibisofs_protective_msdos_plus_boot_dummY -DLibisofs_pmpbd_on_lba0
cause a dummy partition with boot flag to be added to MBR

  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x00  0xef        32204         5760
  MBR partition      :   2   0x80  0x00            0            1

Also available with classic GRUB2 MBR partition 1 and boot flag
(by -append_partition 2 ... rather than -append_partition 1 ...)
Boot flag in MBR needs no special macros, because this case runs on
the ticket of GRUB2 BIOS-only:

  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x80  0xcd            1        32203
  MBR partition      :   2   0x00  0xef        32204         5760

Fashionable this spring: Mountable partition 1 with boot flag
(by -append_partition 2 ... and by omitting --protective-msdos-label)

  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x80  0x83            0        32204
  MBR partition      :   2   0x00  0xef        32204         5760


Before i replace the macros by run-time options i would like to
get feedback whether this setup and some of its variations offer
any advantage over the normal grub-mkrescue output.

(Creepy code changes:
  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1299/libisofs/system_area.c
  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1299/libisofs/make_isohybrid_mbr.c
)

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

A new GNU xorriso development tarball is uploaded

  http://www.gnu.org/software/xorriso/xorriso-1.4.3.tar.gz
  MD5 eea74ebbf79a884a2943f4f63844d593

  Version timestamp :  2015.12.27.150821

Run tests by mounting an EFI+BIOS grub-mkrescue ISO as "/mnt/iso",
and copying the first 512 bytes of such an ISO to file "minimal-grub2.mbr".
Obtain the ISO modification date by

  ISO=minimal-grub2.iso
  MOD_DATE=$(xorriso -indev "$ISO" -pvd_info 2>/dev/null | \
             grep '^Modif\. Time  :' | sed -e 's/^Modif. Time  : //')

Then run with the experimental xorriso binary

  ...absolute.path.../xorriso/xorriso -as mkisofs \
     -o minimal-grub2-repacked.iso \
     -r -no-pad \
     --modification-date=$MOD_DATE \
     --grub2-mbr minimal-grub2.mbr \
     -c '/boot.catalog' \
     -b '/boot/grub/i386-pc/eltorito.img' \
        -no-emul-boot -boot-load-size 4 -boot-info-table \
        --grub2-boot-info \
     -eltorito-alt-boot \
     -e '/efi.img' \
       -no-emul-boot -isohybrid-gpt-basdat \
     -hfsplus \
       -apm-block-size 2048 \
       -hfsplus-file-creator-type chrp tbxj \
                                 /System/Library/CoreServices/.disk_label \
       -hfs-bless-by intel_bootfile /System/Library/CoreServices/boot.efi \
     \
     -append_partition 1 0xef /mnt/iso/efi.img \
     --protective-msdos-label \
     \
     /mnt/iso

Play with the hindmost options to achieve different MBR partition
tables.

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

Perky comments about this variation of the mjg layout:

> MBR with single ESP

This will suffer from the ambiguity of the storage device,
as i had to learn from you.
USB stick typically has 512 bytes per block, CD/DVD/BD bear 2048.
A 4 KB sector disk might be encountered, too.

(GRUB2 could recognize its own ISO 9660 pseudo APM Block0 MBR hybrid
 and then assume block size 512. In APM, the start bytes
  45 52 08 00 eb 02 ff ff ...
 mean:
  APM Block0 magic number,
  block size 2048,
  device size 3,942,842,367 blocks.
 Quite improbable that any real APM has these values.)


> GPT with single ESP

This should not be recognized by a standards compliant EFI.


> APM with ESP, HFS+

The Block0 of the GRUB2 MBR is quite a fake: Fantasy device size.
Fields
filled with x86 code for BIOS USB stick booting.

Further, the El Torito boot images are inside the HFS+ filesystem.
So for having ESP and HFS+ in APM and avoiding partition overlapping,
we need an extra ESP like in my MBR-only EFI favorite.

mjg's HFS+ in Fedora LiveCD is a rather small image file inside the ISO,
not an alternative superblock and file tree which leads to the same
files as the ISO.
Debian has no HFS+. (Only a remnant APM option with its xorriso run.)


This is totally contrary to Vladimir's ideas from 3.5 years ago.
mjg's layout has been used by several large Linux distros in the
last about 4 years, though.

Shall this become an alternative to the current layout of grub-mkrescue ?
(Can we then have my MBR-only favorite, too ?)

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

Have a nice day :)

Thomas