hfsplus partition will not mount
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
I have a hard disk image of a Mac OS X system.
macbook1.img is the entire disk, including partition table.
hfs1.img is part of the entire disk from offset 209735680 onwards.
hfs2.img is part of the entire disk from offset 209735680 onwards and then truncated according to the length of the partition.
I tried to mount it with:
mount -t hfsplus -o ro,loop,
Give this in dmesg
[320231.611112] hfs: unable to find HFS+ superblock
[320293.525940] hfs: invalid secondary volume header
[320293.525944] hfs: unable to find HFS+ superblock
[320629.619113] hfs: invalid secondary volume header
After I use dd to extract just the hfsplus partition into a single file, it still fails to mount.
Only when I truncate the image file to the exact length of the partition according to the partition table, does the mount command actually mount the image with:
mount -t hfsplus -o ro,loop hfs2.img /n1/macbook/fs
I conclude that there must be a bug in the Linux kernel hfsplus code, that wrongly locates the secondary volume header unless the image size is correct.
Output of file:
hfs1.img: Macintosh HFS Extended version 4 data last mounted by: 'HFSJ', created: Wed May 11 07:33:43 2011, last modified: Wed Oct 5 16:49:16 2011, last checked: Wed May 11 15:33:43 2011, block size: 4096, number of blocks: 14567302, free blocks: 4402186
hfs2.img: Macintosh HFS Extended version 4 data last mounted by: 'HFSJ', created: Wed May 11 08:33:43 2011, last modified: Wed Oct 5 16:49:16 2011, last checked: Wed May 11 15:33:43 2011, block size: 4096, number of blocks: 14567302, free blocks: 4402186
macbook1.img: x86 boot sector; partition 1: ID=0xee, starthead 254, startsector 1, 117210232 sectors, extended partition table (last)\011, code offset 0x0
output of parted:
Disk /n1/macbook/
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 20480B 209735679B 209715200B fat32 EFI system partition boot
2 209735680B 59877404671B 59667668992B hfs+ Customer
ls -l
-rw-r--r-- 1 root root 59801907200 2011-11-13 15:12 hfs1.img
-rw-r--r-- 1 root root 59667668992 2011-11-13 16:46 hfs2.img
-rw-r--r-- 1 root root 60011642880 2011-10-29 14:14 macbook1.img
ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: udisks 1.0.4-1
Uname: Linux 3.1.0+ x86_64
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
CustomUdevRuleF
Date: Sun Nov 13 18:35:30 2011
MachineType: Dell Inc. Inspiron 1521
ProcEnviron:
LANGUAGE=en_GB:en
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=
SourcePackage: udisks
Symptom: storage
Title: Internal hard disk partition cannot be mounted manually
UpgradeStatus: Upgraded to oneiric on 2011-10-14 (29 days ago)
dmi.bios.date: 02/03/2008
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A06
dmi.board.name: 0GU163
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.
dmi.product.name: Inspiron 1521
dmi.sys.vendor: Dell Inc.
The HFS+ volume format specifies that the alternate volume header is to be located 1024 bytes before the end of the volume. Without the partition table information to specify the actual length of the partition, Linux must assume that the partition is the size of the device, which in the case of a loopback device would be the size of the source file. The HFS+ metadata does not seem to contain any information about the size of the volume, only the size and number of allocation blocks on the volume, which doesn't help in locating the alternate volume header because that data structure may be stored outside of the allocation blocks.
So in this case the hfsplus driver is behaving correctly according to the specification and doing the best it can do based on the available information since it does not have accurate information about the size of the volume. If you wish to mount an HFS+ volume you must supply information about where the end of the volume is, either via partition table information or by truncating the image to the actual size of the partition containing the HFS+ volume. Therefore I'm closing this bug as Invalid.