Re: grub-mkrescue hfsplus GPT partition is not mountable on Linux

[Thomas Schmitt]

Hi,

sorry, i misposted this answer to bug-grub, rather than grub-devel.
With the wrong subject, too. Internal thread error.

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

Andrei Borzenkov wrote:
> Attempt to mount third GPR partition as HFS+ results in failure.
> Additionally it tries to interpret the first (dummy) partition, which is
> not fatal but annoying.
> [24623.487605] hfsplus: invalid secondary volume header
> [24623.487608] hfsplus: unable to find HFS+ superblock

The HFS+ failure is due to APM block size 2048.
Linux has 512 hardcoded.

We need to record APM in 2048 blocks in order to have room for the
GPT header block at byte 512. The first APM entry is at byte 2048.
The GPT entry array is after the last APM entry.

I discussed this with Vladimir Serbinenko and George Danchev (my DD)
in June 2012 when we introduced HFS+. George had the same complaint
as you.
Vladimir checked mountability with his Mac reference machine.

My assessment back then with a Linux kernel 2.6i.32 was that the
APM Block0 is not interpreted at all. Its bytes 2 and 3 tell the
block size.
The problem was with the partition map only. As soon as the filesystem
is found, the block size was no issue. (Maybe it's 512 in the filesystem.
I'd have to dig in Vladimir's contributed code.)

I even patched fs/hfsplus/part_tbl.c to make it mount on my test
machine. The patch does not match what i see in linux-4.1.6, i fear.

In linux-4.1.6/fs/hfsplus/part_tbl.c i see an iteration over
the list of partition table entries:

        do {
                ...
                pm = (struct new_pmap *)((u8 *)pm + HFSPLUS_SECTOR_SIZE);
                ...
        } while (pm->pmSig == cpu_to_be16(HFS_NEW_PMAP_MAGIC));

In fs/hfsplus/hfsplus_raw.h i see:

  #define HFSPLUS_SECTOR_SIZE        512
  #define HFSPLUS_SECTOR_SHIFT         9

The magic number of Block0 is defined in fs/hfsplus/part_tbl.c
and in fs/hfs/hfs.h
  #define HFS_DRVR_DESC_MAGIC       0x4552 /* "ER": driver descriptor map */
but not used anywhere underneath linux-4.1.6/fd.
So still not interpreted.

(The GRUB2 MBR starts by "ER\200\000". x86 CPUs take no offense.)


> apple2 is actually smaller than gpt3, and Linux kernel checks secondary
> header which is expected to be at the end of partition.

gpt3 + gpt-backup should cover the same range as apple2 + apple3.

The layout as decided by Vladimir is documented in sectiom
  GRUB2 grub-mkrescue MBR
of
  xorriso-*/doc/boot_sectors.txt
  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt

Currently around line 1540.
Ignore any mentioning of FAT. This is not implemented.
We obviously had no compelling use case.


> I am not sure what is intended here, but apparently Linux does not
> support APM

It supports APM with block size 512. If you avoid any GPT production
and use xorriso -as mkisofs option
  -apm-block-size 512 -hfsplus ...blessings.or.not...
then the result should be mountable (read-only iirc).


> so being able to access HFS+ partition via GPT is a bonus.
> In which case name "Gap1" is misleading :)

GPT "Gap1" is only the final filler up to the backup GPT.
This mountability is a quite inadverted but reliable consequence of
the layout which Vladimir and i negociated in 2012.
In absence of PreP, the HFS+ partition directly follows after
the EFI boot partition.

Actually the layout plan says that there should be a GPT partition
dedicated to HFS+.

GPT Partitions:
   The primary GPT itself covers the System Area.
   Basic Data  from   16 to  EFI-1, protects first part of ISO image
   EFI System  from  EFI to PREP-1, offers EFI image for booting
   Basic Data  from PREP to HFAT-1, protects PreP partition
   HFS+        from HFAT to TAIL-1, offers HFS+ for mounting
   Basic Data  from TAIL to GPTB-1, protects rest of ISO image (if there is)

The middle "Basic Data" would be missing because empty.
But there should be 4 GPT partitions, not 3 as in your ISO.

Might be that this was never correctly implemented.
At least libisofs/hfsplus.c only registers an APM slot named
"HFSPLUS_Hybrid" but no GPT slot.

Hrmpf. This might be the reason why HFS+ was supposed to imply
the production of GPT.
I will investigate where and how i can add a GPT partition for
HFS+ if GPT gets produced.


> And is the very first partition really needed? It is not used by GRUB
> anyway, and there is no requirement that each bit of media is covered.

Vladimir wanted it. It protects against inadverted partition editing.


Thanks for testing, guys !
It is always astounding how many roaches hide under the carpet.


Have a nice day :)

Thomas