Re: using isohybrid for usb bootable isos

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

Hi,

i'm the developer of xorriso. (Cc me, please)

Joey Hess wrote:
> Assuming debian-cd does
> switch to xorriso, so after it supports jidgo

We should begin to write down an exact specification of the jigdo
files which xorriso shall produce during the run by which it
generates an ISO image. (Shall it generate a ready-to-mount image
at all ?)

I did read 
  http://atterer.org/jigdo/debian-jigdo-mini-howto#HOWJIGDOWORKS
and believe to understand the principles.
I assume that xorriso shall act like jigdo-file and produce
at least the .template file. Is there a byte-by-byte specification
of its format ?

What about the .jigdo file ? Is it prepared by a different tool ?
Shall xorriso produce parts of it ?
Or shall xorriso read it in order to learn which files are known ?


> I would caution that my idea of adding a partition for firmware is
> potentially half-baked.

It matches well the idea behind the partition table entries of
isohybrid and grub-mkrescue.
Both have their partition table to reserve the space of the ISO
image and to give partition editors a hint about the unused space
on the device.

So to populate the image with more partitions seems straightforward.


> The same problem could be
> solved more generally by eg, using multisession to append the firmware
> to the iso. But that would require the user run a script;

xorriso makes it quite easy to add sessions.
But it is not widely in use.

The size overhead of adding a session depends much on the number of
files in the resulting ISO image. Each session gets a new copy of
the whole directory tree. (E.g. 45000 files = 15 MB in my backup.)


> the firmware
> parition does allow even a user limited to Windows and no extra programs
> to add firmware to their USB stick

Yeah. People expect their USB sticks to have mountable partitions.
A flat stick with ISO image is sometimes frowned at.

Currently isohybrid and grub-mkrescue bear still quite unusual
partition layouts:
- isohybrid partition starts at block 0. I.e. there is no unclaimed
  space before the first partition.
- grub-mkrescue partition starts at block 1. This one is not mountable.

Your idea goes well with my current development work:
A partition with non-zero start block address but nevertheless
mountable. (Needs two superblocks and two directory trees.)

Put together i now imagine this partition layout:

 0 kB - 32 kB  Unclaimed space before partition. Playground for
               boot loaders.
32 kB -  X kB  First partition covering the rest of the ISO image
               up to the start of the appended FAT image
 X kB -  Z kB  Second partition covering the FAT image

The ISO image would believe to reach from 0 kB to Z kB.
So the FAT partition would be safe from partition editors and from
ISO multi-session.

The USB stick would appear on GNU/Linux as
  /dev/sdb   ISO filesystem. (This one is seen on CD, or when
             booting via isohybrid MBR or via GRUB MBR.)
  /dev/sdb1  ISO filesystem with same content
  /dev/sdb2  FAT filesystem

This brings some size overhead in comparison to simpler layouts.
But it should be quite self-explaining to any system and user.


Have a nice day :)

Thomas