My first hope, soon dashed, was that it might the power supply. It would have been perhaps the easiest fix. But I determined that 12 volts were being supplied, and that the voltage didn't drop when the supply was plugged securely into the drive.
Next came some web searches. "Research" would not really be a fair way to characterize this, but maybe it would pass for research these days :-). I found "Danny"’s totally excellent teardown video, which enabled me to get the drive out of the enclosure.
I have a desktopside computer with SATA drives.
I connected the Seagate 3TB drive in place of one of the
existing drives, and tried, as superuser,
"mount /dev/sdb /foo/sdb"
No joy. More web searching and after "apt-get install hfsprogs" I got this at the end of dmesg:
[67539.205183] hfsplus: unable to find HFS+ superblock [67547.971602] hfs: can't find a HFS filesystem on dev sdb1Well, let's have a look at the drive
collin@p64:~$ sudo fdisk -l /dev/sdb Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xcea3ed1a Device Boot Start End Sectors Size Id Type /dev/sdb1 * 2048 732565503 732563456 349.3G af HFS / HFS+ collin@p64:~$So that's totally bogus; this is a 3TB drive! Then I remembered some work I did with netbsd around 2001; *BSD systems apparently use “labels” rather than the partition table. So the ptn table is just so much random bits 8^(
I decided to troll around a little, and found this. Don't ask me how I came up with 2048 blocks (with a totally unwarranted 4K blocksize) but here's what struck me:
collin@p64:~$ sudo dd status=none if=/dev/sdb bs=4k skip=2048 count=1 | hexdump -C 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000400 48 2b 00 04 80 00 21 00 48 46 53 4a 00 00 15 d7 |H+....!.HFSJ....| 00000410 d9 35 08 4d da 54 1b 92 00 00 00 00 d9 35 6a bd |.5.M.T.......5j.| 00000420 00 30 c1 f8 00 0b 41 4c 00 00 20 00 15 d5 04 00 |.0....AL.. .....| 00000430 0a f1 a3 84 0a ef 00 00 00 01 00 00 00 01 00 00 |................| 00000440 00 3c 44 75 00 1e 9a f1 00 00 00 00 00 00 00 01 |.<Du............| 00000450 00 00 00 02 00 10 2d b8 00 00 00 00 00 00 00 00 |......-.........| 00000460 00 00 00 00 00 00 00 00 7d c5 0b 14 d5 a8 92 17 |........}.......| 00000470 00 00 00 00 02 ba c0 00 02 ba c0 00 00 00 15 d6 |................| 00000480 00 00 00 01 00 00 15 d6 00 00 00 00 00 00 00 00 |................| 00000490 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000004c0 00 00 00 00 01 00 00 00 01 00 00 00 00 00 08 00 |................| 000004d0 00 00 85 d8 00 00 08 00 00 00 00 00 00 00 00 00 |................| 000004e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000510 00 00 00 00 69 a0 00 00 15 20 00 00 00 03 4d 00 |....i.... ....M.| 00000520 00 07 d0 d8 00 03 4d 00 00 00 00 00 00 00 00 00 |......M.........| 00000530 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000560 00 00 00 00 a9 00 00 00 15 20 00 00 00 05 48 00 |......... ....H.| 00000570 00 00 8d d8 00 05 48 00 00 00 00 00 00 00 00 00 |......H.........| 00000580 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 collin@p64:~$Okay, now that’s more like it. "H+" and "HFSJ" appear there. Searching around the web, I came upon the "Volume Header" section in Apple Technical Note TN1150, which begins:
Each HFS Plus volume contains a volume header 1024 bytes from the start of the volume. The volume header -- analogous to the master directory block (MDB) for HFS -- contains information about the volume as a whole, including the location of other key structures in the volume. The implementation is responsible for ensuring that this structure is updated before the volume is unmounted.Okay, so note how that "H+" begins at 0x400 (i.e., 1024) bytes from the start of this block? the vol begins 2048 blocks in, with a 4K block size, and this block is 1024 bytes in from there. What else?A copy of the volume header, the alternate volume header, is stored starting 1024 bytes before the end of the volume. The implementation should only update this copy when the length or location of one of the special files changes. The alternate volume header is intended for use solely by disk repair utilities.
Somewhere on the web I read the instructions to get testdisk, as in sudo apt-get install testdisk. I said sudo testdisk /dev/sdb and after some flailing I got this:
TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/sdb - 3000 GB / 2794 GiB - CHS 364801 255 63
Partition Start End Size in sectors
>P HFS 16384 5860524031 5860507648
Okay, so if a sector is 512 bytes, then testdisk agrees with
me that the vol starts 8MB in (MB=1024*1024 bytes). Let's see if we can
find the backup/alternate vol header by subtracting 1 from that 5860524031 number:
collin@p64:~$ sudo dd status=none if=/dev/sdb bs=512 skip=5860524030 count=1 | hexdump -C
00000000 48 2b 00 04 80 00 20 00 48 46 53 4a 00 00 15 d7 |H+.... .HFSJ....|
00000010 d9 35 08 4d da 54 0b 51 00 00 00 00 d9 35 6a bd |.5.M.T.Q.....5j.|
00000020 00 2c 98 1f 00 0a 81 3b 00 00 20 00 15 d5 04 00 |.,.....;.. .....|
00000030 0b 00 70 9f 0a dd b9 b7 00 01 00 00 00 01 00 00 |..p.............|
00000040 00 37 5a 59 00 1d 85 1d 00 00 00 00 00 00 00 01 |.7ZY............|
00000050 00 00 00 02 00 10 2d b8 00 00 00 00 00 00 00 00 |......-.........|
00000060 00 00 00 00 00 00 00 00 7d c5 0b 14 d5 a8 92 17 |........}.......|
00000070 00 00 00 00 02 ba c0 00 02 ba c0 00 00 00 15 d6 |................|
00000080 00 00 00 01 00 00 15 d6 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000000c0 00 00 00 00 01 00 00 00 01 00 00 00 00 00 08 00 |................|
000000d0 00 00 85 d8 00 00 08 00 00 00 00 00 00 00 00 00 |................|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000110 00 00 00 00 69 a0 00 00 15 20 00 00 00 03 4d 00 |....i.... ....M.|
00000120 00 07 d0 d8 00 03 4d 00 00 00 00 00 00 00 00 00 |......M.........|
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000160 00 00 00 00 a9 00 00 00 15 20 00 00 00 05 48 00 |......... ....H.|
00000170 00 00 8d d8 00 05 48 00 00 00 00 00 00 00 00 00 |......H.........|
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
collin@p64:~$
Okay, now that's good to know. One other piece of info here. I saw on
https://superuser.com/questions/657655/problems-with-mounting-hfs-drives that
there is a program gdisk, somewhat like fdisk, can
give somewhat more detail on the partition types. And that there are
(at least) two partition types of interest:
While the answer provided by mcy should work if the partition is actually an HFS+ partition, starting with OSX Yosemite the default partition type for a Mac is "Core Storage", which is used to handle logical volumes. This means that what you actually want to mount is a logical volume (using HFS+ filesytem) inside the "Core Storage" partition.What is this gdisk of which you speak? type gdisk said "not found" so I said:To see if your partition is of type "Apple Core Storage" you can use gdisk: AF05 is the code for "Apple Core Storage", while af00 is the code for "Apple HFS/HFS+".
collin@p64:~$ sudo apt-get install gdisk Reading package lists... Done Building dependency tree Reading state information... Done gdisk is already the newest version. gdisk set to manually installed. The following packages were automatically installed and are no longer required: python-cffi python-colorama python-cryptography python-distlib python-ndg-httpsclient python-openssl python-ply python-pyasn1 python-pycparser python-requests python-urllib3 python-wheel Use 'apt-get autoremove' to remove them. 0 upgraded, 0 newly installed, 0 to remove and 455 not upgraded. collin@p64:~$ type gdisk bash: type: gdisk: not found collin@p64:~$Hurmpf. Was it...? Yes it was. Here:
collin@p64:~$ sudo /sbin/gdisk -l /dev/sdb GPT fdisk (gdisk) version 0.8.10 ... *************************************************************** Found invalid GPT and valid MBR; converting MBR to GPT format in memory. *************************************************************** Disk /dev/sdb: 5860533168 sectors, 2.7 TiB Logical sector size: 512 bytes Disk identifier (GUID): C599270C-2980-42BA-996C-7BF534EE6702 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 5860533134 Partitions will be aligned on 2048-sector boundaries Total free space is 5127969645 sectors (2.4 TiB) Number Start (sector) End (sector) Size Code Name 1 2048 732565503 349.3 GiB AF00 Apple HFS/HFS+ collin@p64:~$Well, it still seems silly about the 349.3GBytes, but it says the partition code is the HFSplus one, not the core storage one. That's good news at least.
But not good enough I think. Note that even gdisk thinks we ought to be starting at sector 2048 and that the partition is only about 350gb in size. I noted "offset" and "sizelimit" options in https://superuser.com/questions/961401/mounting-hfs-partition-on-arch-linux/1088110, but mount(8) tells me that those are losetup options only:
The mount command automatically creates a loop device from a regular
file if a filesystem type is not specified or the filesystem is known
for libblkid, for example:
mount /tmp/disk.img /mnt
mount -t ext3 /tmp/disk.img /mnt
This type of mount knows about three options, namely loop, offset and
sizelimit, that are really options to losetup(8). (These options can
be used in addition to those specific to the filesystem type.)
I don't want to hack the partition table, as I might totally b0rk it; another
idea involves getting an adapter, sata↔USB, and just try mounting it on
a mac. It would have to be one with a power supply. Maybe something from
newegg.com
No comments:
Post a Comment