Re: ISO installer image: GPT versus MBR partitions

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

Hi,

Danny Milosavljevic wrte:
> If someone is testing this with Guix, make sure to actually try to boot Guix
> with it (until the root is mounted). Back in the day I changed the root
> discovery of Guix to make it also consider using the entire disk (as opposed
> to a partition on it) as a viable root device (see guix master,
> commit 9833bcfc08ef009b9e8b4398baa481ef65c80ad7).
> That could maybe make it choke if there are multiple partitions/disks with
> equal labels (or whatever field it's searching for) on it (though probably
> not--
> as long as its immaterial which of the partitions/disks with the equal field
> values is mounted).

Volume Id and other superblock properties of the two possible ISO 9660 mount
candidates are supposed to be identical. So on USB stick there is indeed
an ambiguity, which superblock to choose (/dev/sdc versus /dev/sdc1).

But both candidates offer identical directory trees with identical file
properties and content. So it should make no difference which one gets
mounted.
The difference is in the block addresses by which superblock and directory
tree refer to file objects. They have to differ by 16. (Block size 2048.)

Unaware interpreters of hard disk partitioning will hardly consider
the base device for mounting but rather resort to the partitions.
Aware readers, like software in the ISO's initrd, will normally ignore
the partition table and act like on DVD.
But as said, in the end it does not matter which ISO gets mounted.


> FWIW, I'm all for having a MBR-only Guix installer disk as you suggest.

It should at least be tested.
Best with an option of the build process by which the user can choose
between "original", "mbr_hfs" + partition offset 16, "mbr_only" + offset,
and "gpt_appended".

Default should be "original" for now, but with the goal to switch to
"mbr_hfs" or "mbr_only" when enough courageous testers have reported
success.


> But I'd rather not do the hack the others are doing.

I am nagging against the Fedora-inspired layout since years. :))


> How should we mount the root when the right way (with two non-overlapping
> partitions) boots from DVD ?

On DVD there is no public offer of the partition's filesystem.
At least the Linux kernel is not supposed to look for partition tables
on optical media.
(Actually ioctl BLKRRPART is so CD-phobic that it does not even refresh
 the size perception of the medium but simply bails out.
 Else it would be a nice gesture after DVD burning to do
   hdparm -z /dev/sr0
 growisofs emulates this by putting out the tray and pulling it in again,
 if there is a tray motor. Watch your fingers.)


> I'm surprised that it needs so much manual intervention to make
> grub-mkrescue do the right thing.

It does the right thing for the main purpose of creating a widely bootable
ISO image. (The fact that Florian's Macbook takes offense from the EFI
partition image is independent of the partition layout.)

The complaints of Linux at partition assessment time are ugly but harmless.
The lack of a Linux-mountable ISO partition among the four GPT partitions
is ugly, too. But the user can at any time mount the base device of the
USB stick.

grub-mkrescue's partition layout becomes really suboptimal when the user
wants to use the remaining capacity of the USB stick for one or more
read-write data partitions.
Partition editors righteously complain about the misplaced GPT backup,
which cannot be avoided because the image does not get produced for a
storage device of a particular size.

Similarly suboptimal for partition editors is the Fedora-inspired layout
as produced by "isohybrid -u" or "xorrisofs ... -isohybrid-gpt-basdat".
Other than grub-mkrescue's GPT, this layout is barely legal.


Have a nice day :)

Thomas