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

[Andrei Borzenkov <arvidjaar@gmail.com>]

23.12.2015 01:54, Thomas Schmitt пишет:
> 
> The HFS+ failure is due to APM block size 2048.
> Linux has 512 hardcoded.
> 

No, it has not.

> 
> 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.

Do not confuse APM and HFS+. Block size in APM has no relation to block
size in HFS+. Neither in Linux nor in GRUB. And GRUB never uses APM
block size when reading HFS+ either.

> 
> In fs/hfsplus/hfsplus_raw.h i see:
> 
>   #define HFSPLUS_SECTOR_SIZE        512
>   #define HFSPLUS_SECTOR_SHIFT         9
> 

This is simply *minimal* HFS+ block size, same as in GRUB.

> 
>> I am not sure what is intended here, but apparently Linux does not
>> support APM
> 
> It supports APM with block size 512.

It supports APM with any size. It is just that APM has lower priority in
Linux so MSDOS or GPT win and Linux does not support multiple partition
labels on device.

And again - APM is irrelevant here, we do not access HFS+ via APM, we
access it via GPT in this case. If I adjust gpt3 to be of the same size
as apple2 it is happily mounted by Linux. So there is absolutely no
issue with block size in HFS+.

> 
> 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.
> 

If you insist on covering the whole range, just add one more GPT
partition after it.

> 
>> 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.
> 

Not following here. The whole image is created by dedicated tool and is
mainly intended for read-only media anyway.