Re: ISO installer image: GPT versus MBR partitions

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

Hi,

Danny Milosavljevic wrote:
> you *are* upstream so
> it's really up to you whether we should patch xorriso or not.

Then do if you can make use of those two git commits.
They are the only ones to that file since release 1.5.0.


> I'm not sure about amending "guix system disk-image" by options that
> aren't really end user options, but I guess it can't be helped.

How about

  --file-system-type=iso9660[_$variation]

with $variation being "gpt_hfs" (= "original"), "mbr_hfs", "mbr_only",
and "gpt_appended", defaulting to "gpt_hfs" ?

This translates quite straightforward to the proposed variations of
grub-mkrescue-sed.sh in
  http://lists.gnu.org/archive/html/guix-devel/2019-04/msg00420.html

The partition offset 16 and MBR partition type 0x83 would be ordered
only with "mbr_*" variations.

The setting
  export MKRESCUE_SED_IN_EFI_NO_PT=yes
should be used unconditionally. It gets applied to the EFI partition
block 0, only if it is marked with an MBR signature 55 aa. Then we may
safely assume that bytes 446 to 509 are MBR partition table, which is
of no use and maybe harmfull. Only then they get zeroed.

The experimental setting
  export MKRESCUE_SED_IN_EFI_NO_PT=extra
is not yet sufficiently motivatable for production ISOs. It exists for
getting an impression whether mformat option -k would be safe in
grub-mkrescue. (I.e. it is research for general GRUB enlightenment.)


> Basically they would just be something that we'd tell users which
> have problems booting the Guix iso to use.

If the Guix download servers can afford two more ISOs, how about offering
"gpt_hfs" and "mbr_hfs" ISOs with the explanation that both should work
for booting and installing, but that "mbr_hfs" is more convenient when
the remaining capacity of a Guix ISO USB stick shall be used as partition
for a read-write filesystem.
(Moving the backup GPT is an expert option in fdisk. But without moving
 it there is no room for a new partition.)

On the long run and if no negative results arise, i propose to switch the
default to "mbr_hfs".


> But if no care is taken, shell scripts take stuff from the global
> environment and thus are very difficult to predict and isolate for
> modularity.

I tried hard to keep it conservative and am open for proposals to
make it more portable to older shells.


> But then grub-mkrescue will invoke
> grub-mkrescue-sed.sh at runtime, and who knows what the latter will pick up
> as the sed to use?

grub-mkrescue runs the mformat program and the mcopy program before
it runs xorriso.


> (For that matter, think of what happens when another xorriso is somewhere
> in $PATH and we use --xorriso=.../grub-mkrescue-sed.sh).

Should not matter much, as long as this xorriso is young enough.
grub-mkrescue will ask by running effectively
  ./grub-mkrescue-sed.sh -as mkisofs -help 2>&1
and inspecting the options list of the real xorriso involved.

The only difference will be two message lines (one empty)
  frontend/grub-mkrescue-sed.sh manipulating xorriso arguments

but then it will say
  xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project.

  Usage: xorriso -as mkisofs [options] file...
  ...

If you can tell the absolute path to a good xorriso, then set

  export MKRESCUE_SED_XORRISO=...path.to.real.xorriso.binary...


> For example in grub-mkrescue-sed.sh there's no "-e" in the shebang

Is it conservative enough to add it ?


> Guile, on the other hand, will just fail the script on error (usually).

That's why i brought a Guile re-write into consideration.
Firstly it would be the language of choice and secondly it would make
Guix independent of my ideas how it should be done. As said, the
script-in-the-middle gives substantial control over the stage of
grub-mkrescue when the prepared files are still not packed up in the ISO.

(Or maybe it's time to re-write the script in C ... as was done with
 grub-mkrescue when it became too complicated.)


Have a nice day :)

Thomas