Re: ISO installer image: GPT versus MBR partitions

["Thomas Schmitt" <scdbackup@gmx.net>]

Hi,

here are instructions to repack a Guix ISO with EFI support (via GPT)
to an ISO with MBR-only partition table.

Tested with guixsd-install-0.15.0.i686-linux.iso, because my copy
of 0.16.0 is one of the victims of bug#33639.

It becomes 130 MiB larger than the original, probably because there
were hardlinks in the original disk tree, which share their content in
the original ISO but which the Linux isofs driver cannot expose as
hardlink siblings when the ISO gets mounted.
E.g.
  /gnu/store/0br6mgbnc8b0myvvgpihhry9lfb67pdv-gmp-6.1.2/share/info/gmp.info-1.gz
  /gnu/store/2078rjc6rlj5yran6sx9kd5k4281j0vm-gmp-6.1.2/share/info/gmp.info-1.gz  /gnu/store/v78qymi7sxywv8l6kk5iydvvpdpncrsv-gmp-6.1.2/share/info/gmp.info-1.gz
have all the same LBA in the original ISO. But Linux shows them with
three different inode numbers, which it derives from the byte addresses
of the files' directory records. Shwoops ... 190 KiB more.
A few hundred such duplications would cause 130 MiB of growth.

About 17 MiB of the size difference are due to the second directory
tree which is needed to make partition 1 mountable despite not
beginning at block address 0.
Guix has a generously sized directory tree in its ISO. More than 30,000
data files. But i think a nice partition table is worth even 17 MiB.

=========================================================================

# Some paths which one may choose differently
BASE_ISO=guixsd-install-0.15.0.i686-linux.iso
MOUNT_POINT=/mnt/iso
EXTRACTED_MBR_IMG=extracted_mbr.img
REPACKED_ISO=guix-0.15.0.i686-mbr-only.iso

# (I myself prefer to become real superuser for mounting. But sudo is modern.)
PRIV_CMD=sudo

# Now for the work:

# Extract the MBR x86 code part from the original ISO
dd if="$BASE_ISO" bs=1 count=446 of="$EXTRACTED_MBR_IMG"

# The mounted original ISO will donate all its files to the repacked one
$PRIV_CMD mount -o loop "$BASE_ISO" "$MOUNT_POINT"

# The follow xorriso run builds the repacked ISO by native xorriso commands.
# Other than the mkisofs emulation it would not truncate an existing
# ISO image but rather complain about an unsuitabe multi-session setup.
# So remove an older image, if it exists:
test -e "$REPACKED_ISO" && rm "$REPACKED_ISO"

# Map the ISO data files into the new ISO, but delete /efi.img, which is the
# FAT filesystem image of the EFI partition.
# Install the extracted MBR with GRUB specific adjustments and start of
# partition 1 at byte 32768.
# Append the EFI partition image after the ISO filesystem (that is why the file
# is not needed inside the filesystem and then makes a much nicer partition).
# Set up the first El Torito catalog entry for PC-BIOS.
# Set up the second  El Torito catalog entry for EFI, using the appended
# partition.
xorriso \
   -outdev "$REPACKED_ISO" \
   -volid 'GUIXSD_IMAGE' \
   \
   -map "$MOUNT_POINT" "/" \
   -rm /efi.img -- \
   \
   -boot_image grub grub2_mbr="$EXTRACTED_MBR_IMG" \
   -boot_image any mbr_force_bootable=on \
   -boot_image any partition_table=on \
   -boot_image any iso_mbr_part_type=0x83 \
   -boot_image any partition_offset=16 \
   \
   -append_partition 2 0xef "$MOUNT_POINT"/efi.img \
   \
   -boot_image any cat_path='/boot.catalog' \
   \
   -boot_image grub bin_path='/boot/grub/i386-pc/eltorito.img' \
   -boot_image grub grub2_boot_info=on \
   -boot_image any emul_type=no_emulation \
   -boot_image any load_size=2048 \
   -boot_image any boot_info_table=on \
   \
   -boot_image any next \
   \
   -boot_image any efi_path='--interval:appended_partition_2:all::' \
   -boot_image any emul_type=no_emulation

=========================================================================

The result may be inspected by

  xorriso \
     -indev "$REPACKED_ISO" \
     -report_system_area plain \
     -report_el_torito plain

which should say

  ...
  Volume id    : 'GUIXSD_IMAGE'
  System area options: 0x00004a00
  System area summary: MBR grub2-mbr cyl-align-off
  ISO image size/512 : 2071064
  Partition offset   : 16
  MBR heads per cyl  : 64
  MBR secs per head  : 32
  MBR partition table:   N Status  Type        Start       Blocks
  MBR partition      :   1   0x80  0x83           64      2065240
  MBR partition      :   2   0x00  0xef      2065304         5760
  El Torito catalog  : 17333  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       17334
  El Torito boot img :   2  UEFI  y   none  0x0000  0x00   5760      516326
  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 blks :   2  1440

=========================================================================

For eyes which are not accustomed to xorriso's native command set, here is
the same with mkisofs emulation options (without trying to exclude
/mnt/iso/efi.img from the filesystem):

xorriso -as mkisofs \
   -o "$REPACKED_ISO" \
   -V 'GUIXSD_IMAGE' \
   \
   --grub2-mbr "$EXTRACTED_MBR_IMG" \
   --mbr-force-bootable \
   -iso_mbr_part_type 0x83 \
   -partition_offset 16 \
   \
   -append_partition 2 0xef "$MOUNT_POINT"/efi.img \
   \
   -c '/boot.catalog' \
   \
   -b '/boot/grub/i386-pc/eltorito.img' \
   --grub2-boot-info \
   -boot-info-table \
   -no-emul-boot \
   -boot-load-size 4 \
   \
   -eltorito-alt-boot \
   \
   -e '--interval:appended_partition_2:all::' \
   -no-emul-boot \
   \
   "$MOUNT_POINT"

Most users, including grub-mkrescue, prefer the mkisofs emulation because
they can recycle old knowledge from El-Torito-BIOS-only times.
The appeal of the native command set mostly shows up when the ISO content
is not shaped in a tree on hard disk but collected and arranged from
various files and trees.

Main difference is that sequence does strictly matter with the native set.
E.g. i cannot set boot attributes to files which are not mapped in yet.
The mkisofs emulation sets up a production job and only then assesses
the input file objects. (Imagine a shell which takes a dozen commands
from you and re-arranges them before executing them. Ewww ...)


Have a nice day :)

Thomas