I would like to better understand what is on this hard disk, and how I can mount it into Linux (specifically Debian GNU/Linux, Stable):

It was created on a Powerbook g4 "alu book" with the default program, and used as a backup drive. Now I'm trying to rescue it or at least just use dd to save images of the partitions where the data actually is (where?). It has been mounted a few times in old macs, but doesn't always, and should have a single partition with a handful of files in it.

I was thinking to use dd to blow away the appropriate bytes; will this let me mount it like a standard GPT uefi drive?

Data speaks:

First 2 blocks

Here is what the first 2 512-byte-blocks look like, dumped out into Bash


Manual mount

Trying to mount individual pieces of this partition, is not what I want to do; I want to mount the entire drive, like it would read on a mac. I don't understand where the files are, and why there are 15-16 partitions instead of one!

Output from 'Analyse' option on testdisk

Disk /dev/sdb - 160 GB / 149 GiB - CHS 19457 255 63
     Partition               Start        End    Size in sectors
 P HFS                       262208  148499399  148237192
 P HFS                    148499400  148523975      24576
 P HFS                    148786120  212717799   63931680
 P HFS                    212979944  271039599   58059656
 P HFS                    271301744  312581791   41280048

and here are the preceeding partitions according to testdisk initial info:

1 P partition_map                  1         63         63                 
2 P Driver43                      64        119         56
3 P Driver43                     120        175         56
4 P Driver_ATA                   176        231         56
5 P Driver_ATA                   232        287         56
6 P FWDriver                     288        799        512
7 P Driver_IOKit                 800       1311        512
8 P Patches                     1312       1823        512
9 P Free                        1824     263967     262144
10 P HFS                       263968 ...


(parted) unit b                                                           
(parted) p                                                                
Model: ST916082 3AS (scsi)
Disk /dev/sdb: 160041885696B
Sector size (logical/physical): 512B/512B
Partition Table: mac

Number  Start          End            Size          File system  Name                      Flags
 1      512B           32767B         32256B                     Apple
 2      32768B         61439B         28672B                     Macintosh
 3      61440B         90111B         28672B                     Macintosh
 4      90112B         118783B        28672B                     Macintosh
 5      118784B        147455B        28672B                     Macintosh
 6      147456B        409599B        262144B                    Macintosh
 7      409600B        671743B        262144B                    Macintosh
 8      671744B        933887B        262144B                    Patch Partition
10      135151616B     91240419327B   91105267712B  hfs+         Apple_HFS_Untitled_1
11      91240419328B   91777290239B   536870912B    hfs+         Apple_HFS_Untitled_2
13      91911507968B   113693339647B  21781831680B  hfs+         Apple_HFS_Untitled_3
14      113693339648B  113727942655B  34603008B     hfs+         Apple_HFS_Untitled_4
16      113862160384B  160041877503B  46179717120B  hfs+         Apple_HFS_Untitled_5

2 Answers 2


If you have space, please back up the disk as a whole (e.g. dd if=/dev/sdb of=disk.img bs=1M), before running random programs like fsck on things that you don't think are valid partitions :p. I'm not saying you've damaged it, but there's a very good chance of doing so while experimenting.

The partition table shown by parted & the kernel looks incredible :(.

But if it was created on a PowerMac, surely that's too old for GPT.

And your ASCII dump (while not a recommended way of identification) does look like there's an Apple Partition Map there. Note the 'PM' signature. 'ER' also fits in.

If there was a PC-style MBR you'd expect to see some error messages in the ASCII dump of the first sector.

This is looking mutually exclusive with GPT as well. Barring black magic, which there's no reason for anyone to have loosed upon the world. (Black magic as used in Linux boot media for compatibility; see the ER link above. Your information has too many points of divergence from this case - e.g. there'd be an MBR super-imposed on the first sector, containing error messages used by isolinux).

I don't have any Mac experience, but I suggest running testdisk. It works like parted's rescue mode. See if it identifies anything reasonable, i.e. a Mac-supported filesystem that covers the majority of the drive. I think should show a starting offset for the partition in terms of 512-byte sectors.

Then you could try the offset identified by testdisk using a loop device. E.g.

losetup -f -o offset-in-bytes /dev/sdb

=> loopN

mount /dev/loopN /mnt

If you can't mount the filesystem and you only have a few files using common formats, you could try photorec (from the same link). It works like testdisk but on common file formats (originally for photos, hence the name) instead of file systems.

  • thanks @sourcejedi . I didn't do any repairs with fsck.hfplus ;}, but you reminded me that I may have improperly unmounted the disk trying to read it on an even older iMac G3 frontloader. I will try testdisk since it is in the Debian repository anyway. Aug 7, 2014 at 15:02
  • Additional info: I did run 'search for filesystems' from a Gparted live system once, and it additionally found #1: fat32 (6880 MiB) which had files in it like a Windows MBR. Aug 7, 2014 at 15:07
  • I've updated the post above with output from analyze on testdisk 6.13 Aug 7, 2014 at 16:12
  • 1
    Surely 148237192 * 512 = 75 897 442 304 bytes. But yes, if none of the existing 5 HFS partitions can be mounted under linux, it would be interesting to look at the 5 HFS filesystems which testdisk found at rather different locations. While bearing in mind that mounting HFS+ on Linux could potentially be a destructive operation & that backups are a really good idea.
    – sourcejedi
    Aug 7, 2014 at 17:20
  • 1
    Yes, I think the drive is messed up. Because we're expecting it to only have one partition/filesystem, but we're seeing the drive split into several smaller pieces. Maybe it just had an "interesting" history, but it seems pretty off.
    – sourcejedi
    Aug 7, 2014 at 20:12

Maybe it could work with darling-dmg, it can read rather modern Apple_partition_map :

sudo apt-get install libfuse-dev cmake
git clone https://github.com/darlinghq/darling-dmg
mkdir darling-dmg-build && cd darling-dmg-build
cmake ../darling-dmg
./darling-dmg disk_afs.bin mount_dir/

If it's not working, the source code is fairly readable, maybe you can patch it for your needs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.