adebar
Big d00d
|
Hallo!
Gestern hatte ich ein Problem mit meiner externen Festplatte (Iomega Network Hard Drive). Das Netzwerklaufwerk als das die Platte mit meinem (Windows-)Rechner verbunden war erschien leer, obwohl sich auf der Platte Daten befanden.
Da die NetHDD unter Linux läuft und das Dateisystem der Platte ext2/ext3 (genau weiß ich es leider nicht mehr) ist, hab ich mir gedacht ich häng sie zur Überprüfung in meinen Linux-Rechner.
Leider lässt sich die Festplatte nicht mounten. Wenn ich sie über das GUI vom Konqueror mounten will bekomm ich den Fehler "mount: can't find /dev/hdb2/ in /etc/fstab or /etc/mtab". Wenn ich "mount /dev/hdb2 /mnt/disk" eingib erhalte ich den Fehler "wrong fs type, bad option, bad superblock on /dev/hdb2, missing codepage or other error".
Wo liegt der Fehler? Warum lässt sich die Festplatte nicht mounten?
Bearbeitet von adebar am 25.02.2006, 14:28
|
pilli
Little Overclocker
|
Hallo!
Gestern hatte ich ein Problem mit meiner externen Festplatte (Iomega Network Hard Drive). Das Netzwerklaufwerk als das die Platte mit meinem (Windows-)Rechner verbunden war erschien leer, obwohl sich auf der Platte Daten befanden.
Da die NetHDD unter Linux läuft und das Dateisystem der Platte ext2/ext3 (genau weiß ich es leider nicht mehr) ist, hab ich mir gedacht ich häng sie zur Überprüfung in meinen Linux-Rechner.
Leider lässt sich die Festplatte nicht mounten. Wenn ich sie über das GUI vom Konqueror mounten will bekomm ich den Fehler "mount: can't find /dev/hdb2/ in /etc/fstab or /etc/mtab". Wenn ich "mount /dev/hdb2 /mnt/disk" eingib erhalte ich den Fehler "wrong fs type, bad option, bad superblock on /dev/hdb2, missing codepage or other error".
Wo liegt der Fehler? Warum lässt sich die Festplatte nicht mounten? für konqueror musst du die platte in /etc/fstab eintragen. schon mal "fsck /dev/hdb2" oder "e2fsck /dev/hdb2" probiert ? checkt die festplatte ohne mounten! genauere details drüber siehe man page. bist dir sicher das die platte auf /dev/hdb2 liegt? welche distri verwendest?
Bearbeitet von pilli am 22.02.2006, 18:26
|
that
Hoffnungsloser Optimist
|
mach mal "fdisk -l /dev/hdb", um zu sehen welche Partitionen da drauf sind.
|
adebar
Big d00d
|
mach mal "fdisk -l /dev/hdb", um zu sehen welche Partitionen da drauf sind. linux:~ # fdisk -l /dev/hdb
Disk /dev/hdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hdb1 1 1 8032 83 Linux
/dev/hdb2 2 30401 244188000 83 Linux
|
adebar
Big d00d
|
für konqueror musst du die platte in /etc/fstab eintragen.
schon mal "fsck /dev/hdb2" oder "e2fsck /dev/hdb2" probiert ? checkt die festplatte ohne mounten! genauere details drüber siehe man page.
bist dir sicher das die platte auf /dev/hdb2 liegt? welche distri verwendest? Die Platte liegt sicher auf /dev/hdb2. Ich verwende SUSE 10.0. linux:~ # fsck /dev/hdb2
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
fsck.ext2: Filesystem revision too high while trying to open /dev/hdb2
The filesystem revision is apparently too high for this version of e2fsck.
(Or the filesystem superblock is corrupt)
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
fsck.ext2 /dev/hdb2 failed (status 0x8). Run manually!
|
that
Hoffnungsloser Optimist
|
mach mal "dumpe2fs -h /dev/hdb2".
|
adebar
Big d00d
|
linux:~ # dumpe2fs -h /dev/hdb2
dumpe2fs 1.38 (30-Jun-2005)
dumpe2fs: Filesystem revision too high while trying to open /dev/hdb2
Couldn't find valid filesystem superblock.
|
that
Hoffnungsloser Optimist
|
Hm, jetzt fällt mir auch nix mehr dazu ein, weil e2fsprogs 1.38 ist die aktuelle Version. Kann sein, dass die da irgendwas eigenes basteln - oder irgendwas ist kaputt. Du könntest den Output von hexdump -s 1024 -n 512 -C < /dev/hdb2
mit der Struktur ext2_super_block in /usr/src/linux/include/linux/ext2_fs.h vergleichen, ob das überhaupt irgendwie nach einem ext2fs Superblock aussieht.
|
adebar
Big d00d
|
markus@linux:~> hexdump -s 1024 -n 512 -C < /dev/hdb2
00000400 e0 a8 d2 09 00 88 a3 0b 00 08 00 08 e4 9c 41 09 |..............A.|
00000410 e2 ad d1 09 00 08 00 08 02 08 00 08 02 08 00 08 |................|
00000420 00 88 00 08 00 88 00 08 20 48 00 08 a7 bf 6c 4b |........ H....lK|
00000430 7b 4b fb 4b 46 08 1b 08 53 ef 02 08 01 08 00 08 |{K.KF...S.......|
00000440 21 2a 9a 39 00 4e ed 08 00 08 00 08 01 08 00 08 |!*.9.N..........|
00000450 00 08 00 08 0b 08 00 08 80 08 00 08 00 08 00 08 |................|
00000460 02 08 00 08 03 08 00 08 b4 5c 2f 9b a7 ca 40 89 |.........\/...@.|
00000470 a6 b9 42 6c 6b d9 ef 0b 00 08 00 08 00 08 00 08 |..Blk...........|
00000480 00 08 00 08 00 08 00 08 00 08 00 08 00 08 00 08 |................|
*
00000600
Das is der Output. struct ext2_super_block {
__le32 s_inodes_count; /* Inodes count */
__le32 s_blocks_count; /* Blocks count */
__le32 s_r_blocks_count; /* Reserved blocks count */
__le32 s_free_blocks_count; /* Free blocks count */
__le32 s_free_inodes_count; /* Free inodes count */
__le32 s_first_data_block; /* First Data Block */
__le32 s_log_block_size; /* Block size */
__le32 s_log_frag_size; /* Fragment size */
__le32 s_blocks_per_group; /* # Blocks per group */
__le32 s_frags_per_group; /* # Fragments per group */
__le32 s_inodes_per_group; /* # Inodes per group */
__le32 s_mtime; /* Mount time */
__le32 s_wtime; /* Write time */
__le16 s_mnt_count; /* Mount count */
__le16 s_max_mnt_count; /* Maximal mount count */
__le16 s_magic; /* Magic signature */
__le16 s_state; /* File system state */
__le16 s_errors; /* Behaviour when detecting errors */
__le16 s_minor_rev_level; /* minor revision level */
__le32 s_lastcheck; /* time of last check */
__le32 s_checkinterval; /* max. time between checks */
__le32 s_creator_os; /* OS */
__le32 s_rev_level; /* Revision level */
__le16 s_def_resuid; /* Default uid for reserved blocks */
__le16 s_def_resgid; /* Default gid for reserved blocks */
/*
* These fields are for EXT2_DYNAMIC_REV superblocks only.
*
* Note: the difference between the compatible feature set and
* the incompatible feature set is that if there is a bit set
* in the incompatible feature set that the kernel doesn't
* know about, it should refuse to mount the filesystem.
*
* e2fsck's requirements are more strict; if it doesn't know
* about a feature in either the compatible or incompatible
* feature set, it must abort and not try to meddle with
* things it doesn't understand...
*/
__le32 s_first_ino; /* First non-reserved inode */
__le16 s_inode_size; /* size of inode structure */
__le16 s_block_group_nr; /* block group # of this superblock */
__le32 s_feature_compat; /* compatible feature set */
__le32 s_feature_incompat; /* incompatible feature set */
__le32 s_feature_ro_compat; /* readonly-compatible feature set */
__u8 s_uuid[16]; /* 128-bit uuid for volume */
char s_volume_name[16]; /* volume name */
char s_last_mounted[64]; /* directory where last mounted */
__le32 s_algorithm_usage_bitmap; /* For compression */
/*
* Performance hints. Directory preallocation should only
* happen if the EXT2_COMPAT_PREALLOC flag is on.
*/
__u8 s_prealloc_blocks; /* Nr of blocks to try to preallocate*/
__u8 s_prealloc_dir_blocks; /* Nr to preallocate for dirs */
__u16 s_padding1;
/*
* Journaling support valid if EXT3_FEATURE_COMPAT_HAS_JOURNAL set.
*/
__u8 s_journal_uuid[16]; /* uuid of journal superblock */
__u32 s_journal_inum; /* inode number of journal file */
__u32 s_journal_dev; /* device number of journal file */
__u32 s_last_orphan; /* start of list of inodes to delete */
__u32 s_hash_seed[4]; /* HTREE hash seed */
__u8 s_def_hash_version; /* Default hash version to use */
__u8 s_reserved_char_pad;
__u16 s_reserved_word_pad;
__le32 s_default_mount_opts;
__le32 s_first_meta_bg; /* First metablock block group */
__u32 s_reserved[190]; /* Padding to the end of the block */
};
Das is die Struktur ext2_super_block in /usr/src/linux/include/linux/ext2_fs.h. Ehrlich gesagt: Keine Ahnung, ob das die selbe Struktur ist.
Bearbeitet von adebar am 24.02.2006, 17:03
|
that
Hoffnungsloser Optimist
|
OK, das ist ein Superblock, aber der ist leider defekt. Regelmäßig alle 16 Bits ist eines überall auf 1 gesetzt, z.B. steht in den Bereichen, wo überall "00 00" stehen sollte, "00 08" (binär 00000000 00001000).
Sieht nach einem Hardwareproblem bei irgendeiner 16 Bit breiten Schnittstelle aus (z.B. IDE-Kabel). Bete, dass das Problem beim Lesen auftritt und die Daten nicht so auf der Platte stehen.
|
adebar
Big d00d
|
Kann ich da noch was tun, oder sind die Daten eh schon om Nirvana? Gibt's irgendein Programm, mit dem ich einen neuen Superblock auf die Platte geben kann?
Bearbeitet von adebar am 25.02.2006, 10:17
|
that
Hoffnungsloser Optimist
|
Warum glaubst du, das Hardwareproblem tritt nur beim Superblock auf?
Wenn das Problem beim Lesen auftritt, betrifft es die ganze Platte. Wenn es beim Schreiben aufgetreten ist, dann betrifft es alles, was seit Entstehung des Problems auf die Platte geschrieben wurde.
Falls es ein Leseproblem ist, ist nach Reparatur der Hardware (wenn du Glück hast, Tausch des IDE-Kabels) alles wieder in Ordnung.
Im Fall eines Schreibproblems müsste man sich mal auf die Suche nach den anderen Superblocks machen.
Wenn dir Daten ein paar hundert Euro wert sind, dann gib die Platte einer Datenrettungsfirma.
|
adebar
Big d00d
|
linux:~ # mke2fs -n /dev/hdb2
mke2fs 1.38 (30-Jun-2005)
warning: 216 blocks unused.
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
30583008 inodes, 61046784 blocks
3052350 blocks (5.00%) reserved for the super user
First data block=0
1863 block groups
32768 blocks per group, 32768 fragments per group
16416 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Anscheinend gibts auf der Platte noch Backups vom Superblock... Der Superblock bei 32768 schaut imho ganz in Ordnung aus: linux:~ # hexdump -s 32768 -n 512 -C < /dev/hdb2
00008000 00 00 c0 01 01 00 c0 01 12 00 c0 01 84 6d 1a 40 |.............m.@|
00008010 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008020 00 80 c0 01 01 80 c0 01 12 80 c0 01 2a 2a 13 40 |............**.@|
00008030 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008040 00 00 c1 01 01 00 c1 01 12 00 c1 01 97 60 18 40 |.............`.@|
00008050 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008060 00 80 c1 01 01 80 c1 01 12 80 c1 01 43 5f 18 40 |............C_.@|
00008070 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008080 00 00 c2 01 01 00 c2 01 12 00 c2 01 00 00 04 40 |...............@|
00008090 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000080a0 00 80 c2 01 01 80 c2 01 12 80 c2 01 37 50 19 40 |............7P.@|
000080b0 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000080c0 00 00 c3 01 01 00 c3 01 12 00 c3 01 73 4c 16 40 |............sL.@|
000080d0 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000080e0 00 80 c3 01 01 80 c3 01 12 80 c3 01 21 6d 18 40 |............!m.@|
000080f0 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008100 00 00 c4 01 01 00 c4 01 12 00 c4 01 73 6f 19 40 |............so.@|
00008110 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008120 00 80 c4 01 01 80 c4 01 12 80 c4 01 6f 68 19 40 |............oh.@|
00008130 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008140 00 00 c5 01 01 00 c5 01 12 00 c5 01 fe 69 1a 40 |.............i.@|
00008150 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008160 00 80 c5 01 01 80 c5 01 12 80 c5 01 6e 70 1a 40 |............np.@|
00008170 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008180 00 00 c6 01 01 00 c6 01 12 00 c6 01 f2 64 19 40 |.............d.@|
00008190 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000081a0 00 80 c6 01 01 80 c6 01 12 80 c6 01 8f 70 1a 40 |.............p.@|
000081b0 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000081c0 00 00 c7 01 01 00 c7 01 12 00 c7 01 a9 6b 1a 40 |.............k.@|
000081d0 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000081e0 00 80 c7 01 01 80 c7 01 12 80 c7 01 2b 6f 1a 40 |............+o.@|
000081f0 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008200
Bearbeitet von adebar am 25.02.2006, 11:18
|
that
Hoffnungsloser Optimist
|
Anscheinend gibts auf der Platte noch Backups vom Superblock...
Der Superblock bei 32768 schaut imho ganz in Ordnung aus: Gute Idee, mit mke2fs -n nach den Backups zu suchen. Allerdings hast du vergessen, 32768 mit der Blockgröße zu multiplizieren. Was du da gedumpt hast, hat zwar den oben beschriebenen Bitfehler nicht, ist aber auch kein Superblock. Wenn du einen Superblock gefunden hast, steht in der vierten Zeile im zweiten Block "53 ef" (das ist das Feld "s_magic"). Jedenfalls deutet das darauf hin, dass das Problem nicht alle Sektoren betrifft, und daher vermutlich beim Schreiben aufgetreten ist. Solltest du einen intakten Superblock finden, müsstest du noch feststellen, welche Sektoren von dem Bitproblem betroffen sind. Höchstwahrscheinlich beschränkt sich das nicht auf den ersten Superblock. Du solltest AUF KEINEN FALL versuchen, das Filesystem zu mounten oder zu reparieren, so lange du nicht ein komplettes Image davon als Backup hast.
Bearbeitet von that am 25.02.2006, 12:20 (Warnung added)
|
adebar
Big d00d
|
Gute Idee, mit mke2fs -n nach den Backups zu suchen. Allerdings hast du vergessen, 32768 mit der Blockgröße zu multiplizieren. Verdammte Details Wenn du einen Superblock gefunden hast, steht in der vierten Zeile im zweiten Block "53 ef" (das ist das Feld "s_magic").
Jedenfalls deutet das darauf hin, dass das Problem nicht alle Sektoren betrifft, und daher vermutlich beim Schreiben aufgetreten ist. linux:~ # hexdump -s 134217728 -n 512 -C < /dev/hdb2
08000000 e0 a8 d2 01 00 80 a3 03 00 00 00 00 36 db 94 03 |............6...|
08000010 d5 a8 d2 01 00 00 00 00 02 00 00 00 02 00 00 00 |................|
08000020 00 80 00 00 00 80 00 00 20 40 00 00 00 00 00 00 |........ @......|
08000030 7b 2c 9a 39 00 00 1b 00 53 ef 00 00 01 00 00 00 |{,.9....S.......|
08000040 21 2a 9a 39 00 4e ed 00 00 00 00 00 01 00 00 00 |!*.9.N..........|
08000050 00 00 00 00 0b 00 00 00 80 00 01 00 00 00 00 00 |................|
08000060 02 00 00 00 01 00 00 00 b4 5c 2f 9b a7 ca 40 89 |.........\/...@.|
08000070 a6 b1 42 6c 6b d1 ef 0b 00 00 00 00 00 00 00 00 |..Blk...........|
08000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
08000200
Das schaut nach einem gültigen Superblock aus... Auch das Feld s_magic ist enthalten. Du solltest AUF KEINEN FALL versuchen, das Filesystem zu mounten oder zu reparieren, so lange du nicht ein komplettes Image davon als Backup hast. Das wird schwierig, weil ich keine andere Platte hab, wohin ich ein 250GB großes Backup geben kann... Und ganz nebenbei gibts ein neues Problem: linux:~ # fsck -b 134217728 /dev/hdb2
fsck 1.38 (30-Jun-2005)
e2fsck 1.38 (30-Jun-2005)
fsck.ext2: Invalid argument while trying to open /dev/hdb2
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
fsck.ext2 /dev/hdb2 failed (status 0x8). Run manually!
Würde es was bringen, das Backup bei 0x08000000 über den eigentlichen Superblock drüber zu spielen und dann zu sehen, ob die Platte läuft?
Bearbeitet von adebar am 25.02.2006, 12:53
|