Re: grub-mkrescue: Problem with MBR partition table at start of EFI partition

[Thomas Schmitt]

Hi,

i wrote:
> > So i propose the change as fine tuning of the original developer's
> > intention. (Vladimir will correct me if i'm wrong.)

Daniel Kiper wrote:
> After some thinking I have an itching to add the "-k" option to the
> mformat.

I am not courageous enough to go that far.


> So, I would suggest to make this as a known issue and fix
> it after the release. Does it make sense?

Sure. There is a workaround, after all.


> >   https://savannah.gnu.org/users/alainknaff
> > Maybe he still can remember why he added the partition entry.

> Could you ask him about that? Please keep grub-devel in the loop.

Will do.


> > I was not happy with Vladimir's decision to use GPT instead of MBR partition
> > table. (Because of non-mountable partitions and the GPT backup, which needs
> > to be relocated after copying the ISO onto USB stick.)

> I am not sure I understand. Which GPT do you refer to?

The GPT in the grub-mkrescue ISO, which xorriso creates according to
the options sent from grub-mkrescue.

An ISO made by grub-mkrescue on Debian with "i386-efi", "i386-pc", and
"x86_64-efi" in /usr/lib/grub gets this partition table

  $ /sbin/fdisk -l output.iso
  ...
  Disklabel type: gpt
  Disk identifier: 8E0B9F07-AB1F-4B0B-BA12-764F83FF76EC

  Device      Start   End Sectors  Size Type
  output.iso1    64   339     276  138K Microsoft basic data
  output.iso2   340  6099    5760  2.8M EFI System
  output.iso3  6100 34131   28032 13.7M Apple HFS/HFS+
  output.iso4 34132 34731     600  300K Microsoft basic data

Partitions 1 and 4 are fillers. Not mountable.
Whether partition 3 is mountable depends on the kernel's capability to
work with HFS+ block size 2048. It is supposed show a HFS+ version of the
ISO's file tree. But i am not sure whether this was ever challanged.
The ISO is only mountable via the base device (start 0).

The fillers are necessary because the EFI partition image is a file
inside the ISO filesystem. Number 1 protects vital parts of the ISO from
being claimed by user-made partitions. Number 4 protects cargo cult
padding to prevent the TAO CD Linux read-ahead bug caused by ambiguous
specs for SCSI command READ CAPACITY ... whew, without breathing.

I prefer this layout

  Disklabel type: dos
  Disk identifier: 0x00000000

  Device      Boot Start   End Sectors  Size Id Type
  output.iso1 *       64 28695   28632   14M 83 Linux
  output.iso2      28696 34455    5760  2.8M ef EFI (FAT-12/16/32)

It gets achieved by

  export MKRESCUE_SED_MODE=mbr_hfs
  grub-mkrescue --xorriso=./grub-mkrescue-sed.sh -o output.iso minimal \
                -partition_offset 16 -iso_mbr_part_type 0x83

where "minimal" is a dummy directory with a dummy file.

The pseudo-xorriso moves the EFI image out of the GRUB-prepared tree
(e.g. /tmp/grub.Q98DOe) and replaces the xorrisofs options for EFI-in-ISO
and GPT by options for EFI-appended and MBR partition table.
The options in the second line get forwarded by grub-mkrescue as xorrisofs
options.

Partition 1 is mountable as ISO 9660 filesystem.

This run produces HFS+ and Apple Partition Map. The HFS+ range is not
represented in the MBR partition table, because it is inside the ISO range.

----------------------------------------------------------------------
History and motivation:

Back in 2012, xorriso offered no way to put an El Torito image outside
the ISO filesystem's range. So the choice was to have two EFI images or
to have the EFI partition inside the ISO's data file range.
I am not aware how much Vladimir considered the duplication. His wishes
were for the EFI partition inside the ISO.

Since a while, xorriso can point by an El Torito catalog entry to an
appended partition. So the EFI image can be stored outside the ISO's
claimed range and a mountable ISO partition does not have to overlap
with the EFI partition.

There remains the problem that tools inquire the ISO's claimed size
to determine the size of the overall ISO+EFI image, but the partition's
filesystem must not claim more than the partition's size.
Other tools hate the start LBA 0 of the mountable ISO partition.

Both can be solved at the cost of a second ISO superblock and directory
tree which match a partition start at 64 * 512 bytes. That's the job of
  -partition_offset 16
It creates an ISO superblock for the whole device, which claims the whole
ISO+EFI image as its range. The second superblock claims only the ISO
partition as its range.

We had an example of an EFI implementation, which hated any MBR partition
table type except 0x00 and 0xef. So grub-mkrescue-sed.sh uses type 0x00
by default.
Nevertheless, for the purpose of grub-mkrescue plus data partition on
a USB stick, it is better to have a non-zero MBR partition type. So my
above example uses
  -iso_mbr_part_type 0x83

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

Have a nice day :)

Thomas