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