Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

A client sent a 2 TB drive to AWSs import/export service; AWS put it in an S3 bucket in two chunks. I catted the two chunks together as an iso file, and tried to mount it, using the directions listed by osgx in this post:

How to mount a .bin image file in linux

After issuing the sudo file -sk /dev/mapper/* command, I got the following output:

$ sudo file -sk /dev/mapper/* 
/dev/mapper/control: ERROR: cannot read `/dev/mapper/control' (Invalid argument)
/dev/mapper/loop1p1: x86 boot sector, code offset 0x58+2, OEM-ID "BSD  4.4", sectors/track 32, heads 16, sectors 409600 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 3151, serial number 0x67e317ed, label: "EFI        " DOS executable (COM), boot code
/dev/mapper/loop1p2: Macintosh HFS Extended version 4 data last mounted by: 'HFSJ', created: Mon Apr 28 16:51:09 2014, last modified: Thu Jun 12 22:02:44 2014, last checked: Mon Apr 28 17:51:09 2014, block size: 4096, number of blocks: 488294668, free blocks: 301586546

loop1p1 showed up as FAT 32, so I issued the mount command:

$ sudo mount -o ro -t auto /dev/mapper/loop1p1 files/

After which, mount showed that /dev/mapper/loop1p1 was mounted on files/, but there was nothing inside that directory except an empty dir named ._.Trashes, and a file by the same name. I got the following output when looking at the file:

$ file files/._.Trashes 
files/._.Trashes: AppleDouble encoded Macintosh file

I have no idea what to make of that Mac file.

Looking at dmesg suggests that both loop files should have been FAT 32 (I'm not sure about this, but it seems logical):

[157233.776926] XFS (loop2): bad magic number
[157233.776952] XFS (loop2): SB validate failed with error 22.
[157233.777173] FAT-fs (loop2): bogus number of reserved sectors
[157233.777181] FAT-fs (loop2): Can't find a valid FAT filesystem
[157233.777225] You didn't specify the type of your ufs filesystem
[157233.777225] 
[157233.777225] mount -t ufs -o ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
[157233.777225] 
[157233.777225] >>>WARNING<<< Wrong ufstype may corrupt your filesystem, default is ufstype=old
[157233.777315] ufs_read_super: bad magic number
[157327.336107] ISOFS: Unable to identify CD-ROM format.

I'm not sure where to start troubleshooting this. One note - the first chunk gave an incorrect md5sum. I tried transferring that file from S3 to ec2 twice, and got the same error both times, and had to do the second chunk twice as well, although the second time I did not get an md5sum error. I would have kept trying with the first, but it's a 1.025 TB file, and takes an enormous amount of time to transfer. Still, I would have expected some recoverable files.

Any ideas on where I should start with this? I'm really at a loss.

This is an Ubuntu LTS ec2 instance that is going to be dedicated to this process - though hopefully, from here on out, we'll get this client to send in >1 TB drives, so AWS puts the files right on the EBS volume, instead of requiring all these extra steps.

share|improve this question
    
askubuntu.com/questions/332315 seems potentially useful for mounting an HFS partition. –  Michael - sqlbot Jun 24 at 11:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.