Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
HELP! Rescuing an external HDD
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo
View previous topic :: View next topic  
Author Message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Fri Jun 13, 2014 8:27 pm    Post subject: HELP! Rescuing an external HDD Reply with quote

Hi all,

I did something pretty stupid and misdirected at dd. Fortunately (I hope) I caught it early and it was a small file. However, at present, I cannot access the USB drive. When I attempt an ls I get the following:

Code:
ls: reading directory .: Input/output error


A check of my dmesg reveals:

Code:
[535774.141103] EXT4-fs warning (device sdc1): __ext4_read_dirblock:908: error reading directory block (ino 2, block 0)


I used the usb drive to back u some data as I am changing over a system. That other system's drive is wiped. There was other stuff on the drive, too, so any help would be appreciated.

Best,

Alex
Back to top
View user's profile Send private message
audiodef
Watchman
Watchman


Joined: 06 Jul 2005
Posts: 5282

PostPosted: Fri Jun 13, 2014 8:37 pm    Post subject: Reply with quote

I'm not an expert at recovery, but I would start with the most basic of steps and run fsck on the drive.
_________________
Gentoo Studio: http://gentoostudio.org
Facebook: http://www.facebook.com/gentoostudio
G+: https://plus.google.com/113947758237122861689/posts
Pappy's Kernel Seeds: http://kernel-seeds.org
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Fri Jun 13, 2014 8:45 pm    Post subject: Reply with quote

audiodef wrote:
I'm not an expert at recovery, but I would start with the most basic of steps and run fsck on the drive.


I get the following error message when I do that.

Code:

fsck /dev/sdc1
fsck from util-linux 2.24.1
e2fsck 1.42.7 (21-Jan-2013)
fsck.ext4: No such file or directory while trying to open /dev/sdc1
Possibly non-existent device?


Best,

Alex
Back to top
View user's profile Send private message
audiodef
Watchman
Watchman


Joined: 06 Jul 2005
Posts: 5282

PostPosted: Fri Jun 13, 2014 10:06 pm    Post subject: Reply with quote

That's weird. Even if fsck doesn't fix it, it should be able to recognize that the device is there. Are you able to mount the hard drive? Drives should be unmounted for fsck, but you want to make sure the drive is actually connected to your system.
_________________
Gentoo Studio: http://gentoostudio.org
Facebook: http://www.facebook.com/gentoostudio
G+: https://plus.google.com/113947758237122861689/posts
Pappy's Kernel Seeds: http://kernel-seeds.org
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Fri Jun 13, 2014 10:07 pm    Post subject: Reply with quote

Brief update... I managed to fsck to run but all I wound up with was a full lost+found directory, though none of those files seems to be the sort that was on the drive, i.e. jpgs, etc. Any clue as to what is going on? Have I totally bottled it?

Alex
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2244

PostPosted: Fri Jun 13, 2014 11:16 pm    Post subject: Reply with quote

evoweiss wrote:
Brief update... I managed to fsck to run but all I wound up with was a full lost+found directory, though none of those files seems to be the sort that was on the drive, i.e. jpgs, etc. Any clue as to what is going on? Have I totally bottled it?

Alex ... when you ran dd you probably overwrote the gpt headers/partition table hence the difficulty finding /dev/sdc1. For disc rescue *never* work on the disk itself but make a copy of the block device, I generally would use sys-fs/ddrescue for this purpose. You then work on the copy so that should you damage it its easy to make another copy and start over. Once I have an image of the disk I would try and rebuild the partition table (with gpt partitoned disks you can use gdisk to 'verify' and then, via the 'recovery & transformation menu', fix any discrepencies between the main and backup data). Dependent on how successful I was with the partition recovery I would run testdisk and/or PhotoRec on the copy, to try and recover data ... only once this was done would I use fsck.

best ... khay
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Fri Jun 13, 2014 11:21 pm    Post subject: Reply with quote

khayyam wrote:
evoweiss wrote:
Brief update... I managed to fsck to run but all I wound up with was a full lost+found directory, though none of those files seems to be the sort that was on the drive, i.e. jpgs, etc. Any clue as to what is going on? Have I totally bottled it?

Alex ... when you ran dd you probably overwrote the gpt headers/partition table hence the difficulty finding /dev/sdc1. For disc rescue *never* work on the disk itself but make a copy of the block device, I generally would use sys-fs/ddrescue for this purpose. You then work on the copy so that should you damage it its easy to make another copy and start over. Once I have an image of the disk I would try and rebuild the partition table (with gpt partitoned disks you can use gdisk to 'verify' and then, via the 'recovery & transformation menu', fix any discrepencies between the main and backup data). Dependent on how successful I was with the partition recovery I would run testdisk and/or PhotoRec on the copy, to try and recover data ... only once this was done would I use fsck.


Good advice, thanks. Unfortunately, I cannot really back up the disk as it's larger than the drives in the system.

I originally made the partition using fdisk. Would it be possible to recover or is all lost at this point?

Best,

Alex
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2244

PostPosted: Sat Jun 14, 2014 12:04 am    Post subject: Reply with quote

evoweiss wrote:
Good advice, thanks. Unfortunately, I cannot really back up the disk as it's larger than the drives in the system.

Alex ... you're welcome. Well, how important is the data? I assume that if it doesn't have any value at all you wouldn't be trying to rescue it, if its irreplacable then you have decide if the cost of a new disk (to make the copy to) is worth it. In the many cases I've had to do this, for others I might add, I've always been successful and in each of these cases its always been a matter of not working on the disk itself and so the cost of a disk would have been acceptable (another reason I don't touch the disk itself is that as a last resort the disk could be sent to a professional recovery service ... and that's a sign of how important the data was).

evoweiss wrote:
I originally made the partition using fdisk. Would it be possible to recover or is all lost at this point?

I honestly can't remember off hand if MBR stores any backup of the partition table, but gparted/parted may be able to fix it (I'm not entirely sure but I seem to remember gparted has some data recovery functionality). Again, I'd always work on a copy ... as you never know what a tool is going to do and you don't get a second chance working on the actual disk. BTW sysrescecd has all these tools (gparted, gdisk, testdisk, PhotoRec) installed.

Good luck & best ... khay
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Sat Jun 14, 2014 5:58 am    Post subject: Reply with quote

Hi there,

I know next to nothing about HDD recovery and worry that I may have gone beyond the pale with what I already did. Is there any way to tell if this is the case?

I looked up those tools and cannot work out how I would go about actually recovering the drive. Sorry to be a pest.

Best,

Alex

khayyam wrote:
evoweiss wrote:
Good advice, thanks. Unfortunately, I cannot really back up the disk as it's larger than the drives in the system.

Alex ... you're welcome. Well, how important is the data? I assume that if it doesn't have any value at all you wouldn't be trying to rescue it, if its irreplacable then you have decide if the cost of a new disk (to make the copy to) is worth it. In the many cases I've had to do this, for others I might add, I've always been successful and in each of these cases its always been a matter of not working on the disk itself and so the cost of a disk would have been acceptable (another reason I don't touch the disk itself is that as a last resort the disk could be sent to a professional recovery service ... and that's a sign of how important the data was).

evoweiss wrote:
I originally made the partition using fdisk. Would it be possible to recover or is all lost at this point?

I honestly can't remember off hand if MBR stores any backup of the partition table, but gparted/parted may be able to fix it (I'm not entirely sure but I seem to remember gparted has some data recovery functionality). Again, I'd always work on a copy ... as you never know what a tool is going to do and you don't get a second chance working on the actual disk. BTW sysrescecd has all these tools (gparted, gdisk, testdisk, PhotoRec) installed.

Good luck & best ... khay
Back to top
View user's profile Send private message
khayyam
Advocate
Advocate


Joined: 07 Jun 2012
Posts: 2244

PostPosted: Sat Jun 14, 2014 10:22 am    Post subject: Reply with quote

evoweiss wrote:
I know next to nothing about HDD recovery and worry that I may have gone beyond the pale with what I already did. Is there any way to tell if this is the case?

Alex ... no, there isn't an easy way to tell exactly what state the disk is in, having run 'fsck -y' whatever changes it made are permanent. However, the fact that lost+found has some content means that some (all?) content was marked as having a problem and may still be recoverable (see: this guide).

evoweiss wrote:
I looked up those tools and cannot work out how I would go about actually recovering the drive. Sorry to be a pest.

No problem ... I'd consider the filesystem kaput, you really should copy everything from it and reformat as there is no way of knowing what sectors of the disk dd overwrote. Your problem is you don't have the disk space to move the data from the disk to a known working filesystem before doing this. So, there is no way for me to advise you as its not simply a matter of pointing a tool at the disk and saying "fix it". A recovery tool (like testdisk or photorec) will generally not "fix" the data but allow you to rescue data that may not be accessible via the normal methods (ie, accessing the filesystem). As for gparted, I really wouldn't try this because the most important thing is to recover data, not fix the partition table. As it seems you can currently mount the partition I wouldn't run anything that might effect your ability to do so and copy data from the disk.

There really isn't a magic bullet, you simply can't trust the integrity of the disk currently, that's why you should focus of data recovery (obviously to another filesystem).

best ... khay
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32104
Location: 56N 3W

PostPosted: Sat Jun 14, 2014 3:18 pm    Post subject: Reply with quote

evoweiss,

It looks like I'm too late to this party :(
fsck is the very last thing to do after everything else has failed. The reason is, is that is makes some guesses then modifies the filesystem.
It often makes a bad situation worse.

The first step is always to try mounting read only, using an alternate superblock.

If you have an image of the drive so you can get back to pre fsck state, you can still try this.
If not, its too late.

If the partition table is destroyed, well you don't really need it anyway. mount has an offset=<bytes> option so you can tell it the filesystem start' offset from the start of the drive.
You really don't want to try evey 1k boundary, so testdisk is useful to narrow things down. It often has false positives, so don't let it write a partition table for you.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Chiitoo
l33t
l33t


Joined: 28 Feb 2010
Posts: 887
Location: Here and Away Again

PostPosted: Sat Jun 14, 2014 4:38 pm    Post subject: Reply with quote

With regards to not having space for a copy, I ran into this dilemma myself very recently. An acquaintance had a drive (NTFS) where the MFT (and its mirror) were eaten up by some of the 24 bad sectors (or that's my diagnosis of it anyblue).

The drive was/is 457.8 GiBs or so, and I had no such space around to spare. I was then thinking that, everything is possible, so it should be possible to split the image and mount it later as one. I found some signs towards it being possible indeed, but I didn't really look into it more, nor test it, for I happened to get a hold of an external 1.8 TiB drive.

So, would it actually be possible, or/and at all viable route for this kind of situations?
_________________
Kind Regards,
~ The Noob Unlimited ~

Sore wa sore, kore wa kore.
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Sat Jun 14, 2014 6:59 pm    Post subject: Reply with quote

Hi all,

Many thanks for the tips, commiseration, etc. How would I use testdisk to try and rescue things (I believe the drive was ext4). The only fortunate thing is that the files are mostly not overly necessary, but, of course, it'd be nice to have them back.

One thing that might help is that the main file I'd like to recover is a .tar.gz file. It's the only such file on the drive. The other files are either .wav or .mp3, though I suspect the former. If that would help, great, though, if not, at least the best photos were printed.

Best,

Alex
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32104
Location: 56N 3W

PostPosted: Sat Jun 14, 2014 8:48 pm    Post subject: Reply with quote

evoweiss,

Testdisk can help recover the partition table, not the files.
You need to know before you start that the MSDOS Partition table you were probably using is a series of hacks to get over the immediate problem.

Entries for partitions 1..4 are stored in the MBR. That's all there was space for when the need for partitions arose HDD reached >32Mb. (Really MB)
The extended partition is a fake. Only one block of it is used. The rest reserves space on the HDD for logical partitions 'inside' it. HDD >128Mb became available.

The single used block of the extended partition contains a MBR that is almost empty. It contains a partition table entry to the first logical partition, if any.
This is used to find the next logical partition and so on, just like a linked list.

So ... you can write the entries for partitions 1..4 as often as you like, no data will be harmed
For partitions 5 an later, writing the entry in the wrong place will overwrite something valuable and break the linked list.

Testdisk will scan your HDD, its read only, for blocks that look like the start of filesystems and report them.
If it offers to write a partition table, decline but make a note of the block numbers.

Now use mount to have a look
Code:
mount -o ro,offset=<block_no * 512> -t ext4 /dev/sdX /some/mountpoint

offset is a decimal number of bytes from the start of sdX. There is really no partition number there.

Testing with
Code:
mount -o ro,offset=32256  /dev/sda /mnt/someplace
and will mount the first partition on /dev/sda without using the partition table, if the install is old enough to have the first partition start at sector 63.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Sat Jun 14, 2014 9:02 pm    Post subject: Reply with quote

NeddySeagoon wrote:
evoweiss,

Testdisk can help recover the partition table, not the files.
You need to know before you start that the MSDOS Partition table you were probably using is a series of hacks to get over the immediate problem.

Entries for partitions 1..4 are stored in the MBR. That's all there was space for when the need for partitions arose HDD reached >32Mb. (Really MB)
The extended partition is a fake. Only one block of it is used. The rest reserves space on the HDD for logical partitions 'inside' it. HDD >128Mb became available.

The single used block of the extended partition contains a MBR that is almost empty. It contains a partition table entry to the first logical partition, if any.
This is used to find the next logical partition and so on, just like a linked list.

So ... you can write the entries for partitions 1..4 as often as you like, no data will be harmed
For partitions 5 an later, writing the entry in the wrong place will overwrite something valuable and break the linked list.

Testdisk will scan your HDD, its read only, for blocks that look like the start of filesystems and report them.
If it offers to write a partition table, decline but make a note of the block numbers.


Okay, running testdisk now.

The output is as follows and doesn't sounds good:

Code:

Disk /dev/sdc1 - 1204 MB / 1149 MiB - CHS 1149 64 32
     Partition               Start        End    Size in sectors

No partition found or selected for recovery


The same came about as a result of the "deeper search".

Thoughts, including how screwed I must be :).

Best,

Alex
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32104
Location: 56N 3W

PostPosted: Sat Jun 14, 2014 9:41 pm    Post subject: Reply with quote

evoweiss,

How was the drive partitioned?
If it was one big partition, not having a partition table is the least of your problems.

The first partition will start at either sector 63 or at sector 2048 depending on the version of fdisk you used to write the partition table.
So, try to mount the first partition. Thats offset=32256 or offset=1048576.

If both fail, we can try alternate superblocks too but to limit the guessing, knowing the filesystem size (approx) would be useful as we will need to translate between disk block size (1k and filesystem block size (1k, 2k or 4k)

Is it really only a 1G drive?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Mon Jun 16, 2014 6:40 pm    Post subject: Reply with quote

Hey Neddy,

Sorry for the delay in replying.

NeddySeagoon wrote:

How was the drive partitioned?
If it was one big partition, not having a partition table is the least of your problems.


I partitioned it myself. Just one big partition. What's the recommended approach?

Quote:
The first partition will start at either sector 63 or at sector 2048 depending on the version of fdisk you used to write the partition table. So, try to mount the first partition. Thats offset=32256 or offset=1048576.


I'll do so. Might it actually be better for me to first buy another 1TB drive (I need to anyway) and to then start on this stuff?

Quote:

If both fail, we can try alternate superblocks too but to limit the guessing, knowing the filesystem size (approx) would be useful as we will need to translate between disk block size (1k and filesystem block size (1k, 2k or 4k)


Okay sounds good.

Quote:
Is it really only a 1G drive?


Sorry, my bad! It's a 1 TB device.

Best,

Alex
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Mon Jun 16, 2014 6:48 pm    Post subject: Reply with quote

Okay, so I tried the mount command, but things are still not working. The error I get is:

Code:

mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.


The corresponding syslog message is:

Code:

[249039.147946] EXT4-fs (loop0): VFS: Can't find ext4 filesystem


Same thing happens with the other offset.

Best,

Alex
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32104
Location: 56N 3W

PostPosted: Mon Jun 16, 2014 8:47 pm    Post subject: Reply with quote

evoweiss,

So lets try another superblock ...

Add in sb=131072 to the two mount commands above
Code:
mount -o ro, offset=32256 sb=131072 /dev/sdX /mnt/someplace

Try the other offset= too.

How big was the file you incorrectly dd ed?

There are more backup superblocks too

Homework :)
Read man mount - just the ext2 ext3 and ext4 filesystem specific bits.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Mon Jun 16, 2014 8:56 pm    Post subject: Reply with quote

Hi Neddy,

NeddySeagoon wrote:

So lets try another superblock ...

Add in sb=131072 to the two mount commands above
Code:
mount -o ro, offset=32256 sb=131072 /dev/sdX /mnt/someplace

Try the other offset= too.


Adding sb=131072 just gave me the mount options as opposed to doing anything.

Quote:

How big was the file you incorrectly dd ed?


I don't remember, honestly. There are a few files I wouldn't mind rescuing if possible.

Quote:

There are more backup superblocks too


Okay... as soon as I get the sb thing to work.

Quote:

Homework :)
Read man mount - just the ext2 ext3 and ext4 filesystem specific bits.


I'll try.

Best,

Alex
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Sat Jun 21, 2014 3:22 am    Post subject: Reply with quote

Hi all,

So I figured out why the command wasn't working (extra spaces), but it's still not mounting as it's saying "wrong fs type".

The external drive I ordered arrived. Any thoughts on good next steps?

Best,

Alex
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32104
Location: 56N 3W

PostPosted: Sat Jun 21, 2014 9:14 am    Post subject: Reply with quote

evoweiss,

Sorry about the extra spaces.

Use the new drive to make an image of the old drive, so you can always got back to where you are now.
We can try some more of the backup superblocks.
photorec, given some luck, can recover some file types, from filesystems. It scans the entire drive for file headers and makes some assumptions about the data layout on the drive.

On a 1Tb filesystem (my /home) you get backup superblocks at
Code:
$ sudo dumpe2fs /dev/mapper/vg-home | grep superblock
dumpe2fs 1.42.10 (18-May-2014)
  Primary superblock at 0, Group descriptors at 1-64
  Backup superblock at 32768, Group descriptors at 32769-32832
  Backup superblock at 98304, Group descriptors at 98305-98368
  Backup superblock at 163840, Group descriptors at 163841-163904
  Backup superblock at 229376, Group descriptors at 229377-229440
  Backup superblock at 294912, Group descriptors at 294913-294976
  Backup superblock at 819200, Group descriptors at 819201-819264
  Backup superblock at 884736, Group descriptors at 884737-884800
  Backup superblock at 1605632, Group descriptors at 1605633-1605696
  Backup superblock at 2654208, Group descriptors at 2654209-2654272
  Backup superblock at 4096000, Group descriptors at 4096001-4096064
  Backup superblock at 7962624, Group descriptors at 7962625-7962688
  Backup superblock at 11239424, Group descriptors at 11239425-11239488
  Backup superblock at 20480000, Group descriptors at 20480001-20480064
  Backup superblock at 23887872, Group descriptors at 23887873-23887936
  Backup superblock at 71663616, Group descriptors at 71663617-71663680
  Backup superblock at 78675968, Group descriptors at 78675969-78676032
  Backup superblock at 102400000, Group descriptors at 102400001-102400064
  Backup superblock at 214990848, Group descriptors at 214990849-214990912

On a 1Tb filesystem, the block size is 4k. You need to know this since the numbers above are in filesystem blocks but the mount sb= option is in 1k blocks.
That was a key part of your homework.

Code:
       sb=n   Instead of block 1, use block n as superblock. This could be useful  when  the  filesystem  has  been  damaged.
              (Earlier,  copies  of the superblock would be made every 8192 blocks: in block 1, 8193, 16385, ... (and one got
              thousands of copies on a big filesystem). Since version 1.08, mke2fs has a -s  (sparse  superblock)  option  to
              reduce  the  number  of backup superblocks, and since version 1.15 this is the default. Note that this may mean
              that ext2 filesystems created by a recent mke2fs cannot be mounted r/w under Linux 2.0.*.)   The  block  number
              here  uses  1 k  units.  Thus,  if  you  want  to  use logical block 32768 on a filesystem with 4 k blocks, use
              "sb=131072".


We already know that
Code:
Primary superblock at 0, Group descriptors at 1-64
  Backup superblock at 32768, Group descriptors at 32769-32832
don't work.
Try a few others. You will need to test with both offset= values as we don't know where the partition starts.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Sat Jun 21, 2014 4:40 pm    Post subject: Reply with quote

Hi Neddy,

At present, I'm using dd to clone the botched usb drive to the new usb drive. I just plugged the latter in and issued the command:

Code:

# dd if=/dev/sdc of=/dev/sdd


It may take a while, but time is something I have this weekend. Once I've got that done, I'll follow your instructions and will get back to you.

Thanks again.

Best,

Alex
Back to top
View user's profile Send private message
evoweiss
Veteran
Veteran


Joined: 07 Sep 2003
Posts: 1529
Location: Edinburgh, Scotland

PostPosted: Fri Jul 04, 2014 11:12 pm    Post subject: Reply with quote

Hi Neddy,

None of that seems to be working. All I'm getting is:

Code:

mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.


Not sure if I'm not doing something right or what.

Also, it took forever to dd the drive. It would be from one USB drive to another, so I imagine it's slow. Any way to speed that up?

Best,

Alex
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32104
Location: 56N 3W

PostPosted: Sat Jul 05, 2014 8:49 am    Post subject: Reply with quote

evoweiss,

USB HDD are slow, USB2 does not support DMA so the CPU has to read and write every byte.
USB to USB is even slower. USB3 is supposed to be better - it does DMA.

To clone my laptop hard drive (250G) takes over 4 hours to a USB2 HDD. Its only 45 min if I use the eSATA port, to the same external drive in the same enclosure.
Thats the difference that DMA makes to only the output drive. The internal HDD is always DMA

Show me some of the commands you hove been using and the resulting error messages in dmesg.

Its possible that the root directory has been trashed. Thats why I was interested in the size of the file you incorrectly dd'ed.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Other Things Gentoo All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum