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. _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
