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

[Thomas Schmitt]

Hi,

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

Andrei Borzenkov wrote:
> No, it has not.

Seems to fixed meanwhile, indeed.

I patched away MBR partition table and GPT. After that, the partition
/dev/sdb3 does mount. (sdb1 is the APM partition table, sbd2 and sdb4
are "Gap0" and "Gap1".)

But there is a HFS+ problem regardless of partitioning.
See below.


> Do not confuse APM and HFS+.

I shall rather not confuse APM with GPT when reading.

> If I adjust gpt3 to be of the same size
> as apple2 it is happily mounted by Linux.

I would not have expected that the oversize spoils mountability.
Thus my misreading.


Whatever, the lack of a GPT partition for HFS+ is fixed by
  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1297/libisofs/system_area.c

It now yields when run by grub-mkrescue (Debian Sid, "2.02~beta2-33",
grub-efi-ia32-bin, grub-efi-amd64-bin, grub-pc-bin)

  GPT partition name :   3  48004600530050004c0055005300
  GPT partname local :   3  HFSPLUS
  GPT partition GUID :   3  54048af0155bb44aa145348d46e87e81
  GPT type GUID      :   3  005346480000aa11aa1100306543ecac
  GPT partition flags:   3  0x1000000000000001
  GPT start and size :   3  6096  24096

together with

  APM partition name :   2  HFSPLUS_Hybrid
  APM partition type :   2  Apple_HFS
  APM start and size :   2  1524  6024

I boot a Debian Jessie VM with that image as -hdb (booted is -hda).
fdisk reports

  Device     Start   End Sectors  Size Type
  /dev/sdb1     64   335     272  136K Microsoft basic data
  /dev/sdb2    336  6095    5760  2.8M EFI System
  /dev/sdb3   6096 30191   24096 11.8M Apple HFS/HFS+
  /dev/sdb4  30192 30791     600  300K Microsoft basic data

I can do as uperuser

  # mount /dev/sdb3 /mnt/hfs

without error message.
But then there is a HFS+ problem which i cannot explain yet:

  # ls /mnt/hfs
  ls: reading directory /mnt/hfs: Input/output error
  System  boot  empty-file.txt  mach_kernel

whereas

  # mount -o loop /dev/sdb /mnt/iso
  # ls /mnt/iso
  System  boot  boot.catalog  efi.img  empty-file.txt  mach_kernel

dmesg has:

  [  354.871503] hfsplus: Filesystem is marked locked, mounting read-only.
  [  359.020970] hfsplus: walked past end of dir

uname -a :

  Linux ... 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1+deb8u4 (2015-09-19) 
x86_64 GNU/Linux


It does not look like a problem with the partition.
I have no clue of HFS+ internals. It's done by Vladimir's code in

  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus.c
  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus.h
  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus_case.c
  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus_classes.c
  
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/libisofs/hfsplus_decompose.c

I only provided some glue code and replacements for copyrighted
tables (which are specified freely, to our luck).

If this is a real problem with the boot purpose of the ISO, then
we will have to ask Vladimir for help.

(Mountability and readability on Linux is nice-to-have. But i
 assume that Vladimir is too busy to work on such an issue.)


> > > And is the very first partition really needed? 
> > Vladimir wanted it.
> Not following here.

We should ask Vladimir for the exact motivation of the filler
partitions and show him an evaluation of drawbacks.


Have a nice day :)

Thomas