1 |
On Thursday 17 May 2007 23:27, Etaoin Shrdlu wrote: |
2 |
> On Thursday 17 May 2007 18:04, Mick wrote: |
3 |
> > > Thanks Dan, as I said above I tried to extract the MBR out of it by |
4 |
> > > running: |
5 |
> > > |
6 |
> > > dd if=/dev/sda of=/tmp/r1 bs=512 |
7 |
> > > |
8 |
> > > But couldn't access it whatsoever. |
9 |
> > |
10 |
> > Oops! I could access it, but of course I had to try it as root! |
11 |
> > Right, I've got it on my hard drive now, but still cannot mount it: |
12 |
> > ================================== |
13 |
> > # mount -t vfat /dev/loop2 /tmp/r1 |
14 |
> > mount: wrong fs type, bad option, bad superblock on /dev/loop2, |
15 |
> > missing codepage or other error |
16 |
> > In some cases useful info is found in syslog - try |
17 |
> > dmesg | tail or so |
18 |
> > ================================== |
19 |
> |
20 |
> IIRC, that is not the right syntax for mounting a loopback filesystem. |
21 |
> If /tmp/r1 is the file containing the filesystem, try |
22 |
> |
23 |
> mount -o loop /tmp/r1 /mnt/somewhere |
24 |
> |
25 |
> and make sure you have support for loopback devices in your kernel. |
26 |
|
27 |
Thanks for all the suggestions. I tried the correct mount loopback command |
28 |
on /dev/loop2 and I'm getting this error that mentions /dev/loop0 (how does |
29 |
this work?): |
30 |
====================================== |
31 |
# mount -t vfat -o loop /dev/loop2 /tmp/r1 |
32 |
mount: wrong fs type, bad option, bad superblock on /dev/loop0, |
33 |
missing codepage or other error |
34 |
In some cases useful info is found in syslog - try |
35 |
dmesg | tail or so |
36 |
====================================== |
37 |
|
38 |
Anyway, regarding a previous comment by Dan I tried accessing /dev/sda1 but it |
39 |
complained that the device does not exist, unlike /dev/sda which appears to |
40 |
be there. I have a couple of USB sticks that also have no partition table |
41 |
(they are like floppies) and I access these as /dev/sda. When I look at |
42 |
their few first bytes they look like this: |
43 |
====================================== |
44 |
000000 eb 3c 90 4d 53 44 4f 53 35 2e 30 00 02 20 01 00 |
45 |
000010 02 00 02 00 00 f8 f4 00 3f 00 ff 00 00 00 00 00 |
46 |
000020 00 7a 1e 00 00 00 29 96 9d 62 60 4e 4f 20 4e 41 |
47 |
000030 4d 45 20 20 20 20 46 41 54 31 36 20 20 20 33 c9 |
48 |
====================================== |
49 |
|
50 |
On the other hand the corrupt disk looks like this: |
51 |
====================================== |
52 |
000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
53 |
* |
54 |
0001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |
55 |
000200 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |
56 |
* |
57 |
020000 01 df 02 df 03 df 04 df 05 df 06 df 07 df 08 df |
58 |
020010 09 df 0a df 0b df 0c df 0d df 0e df 0f df 10 df |
59 |
020020 11 df 12 df 13 df 14 df 15 df 16 df 17 df 18 df |
60 |
020030 19 df 1a df 1b df 1c df 1d df 1e df 1f df 20 df |
61 |
020040 21 df 22 df 23 df 24 df 25 df 26 df 27 df 28 df |
62 |
020050 29 df 2a df 2b df 2c df ff ff 2e df 2f df 30 df |
63 |
====================================== |
64 |
which makes me think that it has different partitions on it, but the partition |
65 |
table is corrupted. Otherwise, I guess I would be able to access it |
66 |
through /dev/sda1. So, the question now is how do I recreate/reconstruct it? |
67 |
I'll surely need some help with it because all this hex means nothing to me. |
68 |
|
69 |
-- |
70 |
Regards, |
71 |
Mick |