Hi, One of my shared volumes crashed the other day on a RH-7.2, 2.4.9-31 system. These are the first errors in the log: kernel: EXT3-fs error (device ide0(3,9)): ext3_readdir: bad entry in directory #2424833: rec_len is smaller than minimal - offset=0, inode=2553887680, rec_len=0, name_len=0 kernel: EXT3-fs error (device ide0(3,9)): ext3_readdir: bad entry in directory #2424833: rec_len is smaller than minimal - offset=0, inode=2553887680, rec_len=0, name_len=0 kernel: attempt to access beyond end of device kernel: 03:09: rw=0, want=558629008, limit=53600841 e2fsck complains : e2fsck 1.26 (3-Feb-2002) Group descriptors look bad... trying backup blocks... e2fsck: Attempt to read block from filesystem resulted in short read while checking ext3 journal for /share6 e2fsck: io manager magic bad! What can be done? Thank you, Adrian _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
On Apr 02, 2002 22:52 +0900, Andy Paul wrote:> One of my shared volumes crashed the other day on a RH-7.2, 2.4.9-31 system. > > These are the first errors in the log: > > kernel: EXT3-fs error (device ide0(3,9)): ext3_readdir: bad entry in > directory #2424833: rec_len is smaller than minimal - offset=0, > inode=2553887680, rec_len=0, name_len=0 > > kernel: EXT3-fs error (device ide0(3,9)): ext3_readdir: bad entry in > directory #2424833: rec_len is smaller than minimal - offset=0, > inode=2553887680, rec_len=0, name_len=0These errors indicate a read error on the device, I think.> kernel: attempt to access beyond end of device > kernel: 03:09: rw=0, want=558629008, limit=53600841 > > > e2fsck complains : > > e2fsck 1.26 (3-Feb-2002) > Group descriptors look bad... trying backup blocks... > e2fsck: Attempt to read block from filesystem resulted in short read while > checking ext3 journal for /share6 > e2fsck: io manager magic bad!Try running "e2fsck -b 32768" or "e2fsck -b 98304". It may be that e2fsck 1.26 already checks all of the possible backup block groups for you, but I don't know what version that was added in. You should also try whether "dd if=/dev/hda9" works at all, since it seems you have some pretty major problems. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
>On Apr 02, 2002 22:52 +0900, Andy Paul wrote: > > One of my shared volumes crashed the other day on a RH-7.2, 2.4.9-31 >system. > > > > These are the first errors in the log: > > > > kernel: EXT3-fs error (device ide0(3,9)): ext3_readdir: bad entry in > > directory #2424833: rec_len is smaller than minimal - offset=0, > > inode=2553887680, rec_len=0, name_len=0 > > > > kernel: EXT3-fs error (device ide0(3,9)): ext3_readdir: bad entry in > > directory #2424833: rec_len is smaller than minimal - offset=0, > > inode=2553887680, rec_len=0, name_len=0 > >These errors indicate a read error on the device, I think. > > > kernel: attempt to access beyond end of device > > kernel: 03:09: rw=0, want=558629008, limit=53600841 > > > > > > e2fsck complains : > > > > e2fsck 1.26 (3-Feb-2002) > > Group descriptors look bad... trying backup blocks... > > e2fsck: Attempt to read block from filesystem resulted in short read >while > > checking ext3 journal for /share6 > > e2fsck: io manager magic bad! > >Try running "e2fsck -b 32768" or "e2fsck -b 98304". It may be that >e2fsck 1.26 already checks all of the possible backup block groups for >you, but I don't know what version that was added in.I have tried them with the same result.> >You should also try whether "dd if=/dev/hda9" works at all, since it >seems you have some pretty major problems.dd, hexdump work properly with the partition. Forgot to mention, the partition is (was ?) rather big (40G), used 87%. Is there any ("hard") way to recover anything? Many thanks, Adrian _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx
On Apr 03, 2002 19:34 +0900, Andy Paul wrote:> >You should also try whether "dd if=/dev/hda9" works at all, since it > >seems you have some pretty major problems. > > dd, hexdump work properly with the partition. Forgot to mention, the > partition is (was ?) rather big (40G), used 87%. Is there any ("hard") way > to recover anything?Well, "restore from backup"... That said, it is _very_ strange that your primary and backup superblocks are corrupted. Since the backup superblocks (and group descriptors) are never written to by the kernel, they should be OK unless you wiped out the entire disk. A few interesting tidbits would be the first few kB of "od -Ax -tx4 /dev/hda9" and if you download the e2fsprogs source and build the "findsuper" tool, it may be able to shed a bit of light on what happened to your filesystem. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
On Apr 03, 2002 19:34 +0900, Andy Paul wrote:> One of my shared volumes crashed the other day on a RH-7.2, 2.4.9-31 > system.Note - what do you mean by "shared"? Is it possible the "sharee" wiped out your disk (reformat, repartition, "dd", whatever)? Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Hi,>Well, "restore from backup"...- I suppose I can survive without it. Would have used RAID, had I needed an insurance policy. I am more concerned about not finding the cause and having the same experience repeated next time. - The error sequence started when a user tried to access some data using samba. Noticing some strange delay, he cancelled the request, however samba (?) seemed to have entered some retry loop, trying to access various inodes/blocks for about 1 hour, and filling the log with errors. - Logs, lastcomm etc. revealed no user activity at all around the time of the first ext3 crash (never mind reformat, repartition etc.) - Since last time, I ran a tool called e2salvage on the partition. It crashed with segmentation fault while recovering directories (I wonder if it has anything to do with the cache in the ext3 journal). E2salvage recommends operating on a partition backup, however, since size > 40G ... No change in e2fsck output. - About the partition table, fdisk /dev/hda complains (as usual) about the number of cylinders exceeding 1024. A partition table check returns "372 unallocated sectors", nothing else. - I have also run a badblocks read-only test on /dev/hda9 - no errors.>A few interesting tidbits would be the first few kB of "od -Ax -tx4 >/dev/hda9" >and if you download the e2fsprogs source and build the "findsuper" tool, >it may be able to shed a bit of light on what happened to your filesystem.#od -Ax -tx4 /dev/hda9 000000 00000000 00000000 00000000 00000000 * 000200 9a038c08 9476785f 49bf458f c00096e3 000210 c0dd9d88 df60366d f7ad5d48 2432d146 000220 cd952938 a2d228ad 57f389dc decf21d9 000230 d31f8edf 19863e30 2f9c1e64 36d8b495 000240 4d4bdf55 31fb24cd bfe3b8e8 436dff0d 000250 43640232 a71269b4 dacc53f4 f760eb02 000260 68d0dd63 2ab8971b 14c97c3b 44d7ef04 000270 34b362cd 827354da dd585d3f 47ec2c14 000280 108fc1ef a0188d00 98a5ede5 5a4b9a43 000290 6ce17b7d cf5b848a cb26031a 3ade1754 0002a0 e4c18c09 c97600ea 2e40867a 28569659 0002b0 5a86849c dbc862b7 dce57ae2 06e53156 0002c0 2163ab53 0470cf48 642c2d18 7ac95adf 0002d0 14071c09 19fb4458 f4045773 08f8eab6 0002e0 ba3ef0f1 dfefc49e 6fc23069 3fbc4970 0002f0 5d904c2f 287f6771 9ac79d3b ca539414 000300 3ce1958a 031f8c6d 2e204397 9591afb8 000310 9b1081fd cd2aee09 012cb52d f67e6f1f 000320 e8a03f57 507dc344 2531845a bdf5bb63 000330 dd4693ea f318e434 03046fc3 6345a28a 000340 9e9cfa13 c4c6e7b9 83a777f2 21d6872a 000350 dab3c2f7 adae3d0a 22e505fe 12bf3a0d 000360 ebbb3403 85015e67 1cf90921 556f17ce 000370 f4a1b2ab 3895d9ac 86261867 29492d70 000380 00adcff4 e7807cf7 6f65903a 12435611 000390 2e227519 fdc27743 00f3b313 f8895a7c 0003a0 bee70736 5fdb7711 a1fbc911 3d1a13c9 0003b0 3d1481da 8370c700 0c33429d f26d8702 0003c0 a4a98eaa 91ef6f70 7f84d804 df080ac9 0003d0 7618b509 8223591e cc9ea424 b62a61e3 0003e0 e0fa72b2 43e66cce 7f9f4afd 2866def1 0003f0 d9995854 d6aaaddf 04b01455 41407ffe 000400 00664000 00cc7892 000a393a 00267129 000410 00662dfc 00000000 00000002 00000002 000420 00008000 00008000 00004000 3ca7c82d 000430 3cb11525 00250019 0003ef53 00000001 000440 3c05b658 00ed4e00 00000000 00000001 000450 00000000 0000000b 00000080 00000004 000460 00000002 00000001 a73c96f6 d34646c9 000470 8258dcb3 d03f0f27 6168732f 00366572 000480 00000000 00000000 00000000 00000000 * 0004e0 00000008 00000000 00000000 00000000 0004f0 00000000 00000000 00000000 00000000 * 000800 9a038c08 9476785f 49bf458f c00096e3 000810 c0dd9d88 df60366d f7ad5d48 2432d146 000820 cd952938 a2d228ad 57f389dc decf21d9 000830 d31f8edf 19863e30 2f9c1e64 36d8b495 000840 4d4bdf55 31fb24cd bfe3b8e8 436dff0d 000850 43640232 a71269b4 dacc53f4 f760eb02 000860 68d0dd63 2ab8971b 14c97c3b 44d7ef04 000870 34b362cd 827354da dd585d3f 47ec2c14 000880 108fc1ef a0188d00 98a5ede5 5a4b9a43 000890 6ce17b7d cf5b848a cb26031a 3ade1754 0008a0 e4c18c09 c97600ea 2e40867a 28569659 0008b0 5a86849c dbc862b7 dce57ae2 06e53156 0008c0 2163ab53 0470cf48 642c2d18 7ac95adf 0008d0 14071c09 19fb4458 f4045773 08f8eab6 0008e0 ba3ef0f1 dfefc49e 6fc23069 3fbc4970 0008f0 5d904c2f 287f6771 9ac79d3b ca539414 000900 3ce1958a 031f8c6d 2e204397 9591afb8 000910 9b1081fd cd2aee09 012cb52d f67e6f1f 000920 e8a03f57 507dc344 2531845a bdf5bb63 000930 dd4693ea f318e434 03046fc3 6345a28a 000940 9e9cfa13 c4c6e7b9 83a777f2 21d6872a 000950 dab3c2f7 adae3d0a 22e505fe 12bf3a0d 000960 ebbb3403 85015e67 1cf90921 556f17ce 000970 f4a1b2ab 3895d9ac 86261867 29492d70 000980 00adcff4 e7807cf7 6f65903a 12435611 000990 2e227519 fdc27743 00f3b313 f8895a7c 0009a0 bee70736 5fdb7711 a1fbc911 3d1a13c9 0009b0 3d1481da 8370c700 0c33429d f26d8702 0009c0 a4a98eaa 91ef6f70 7f84d804 df080ac9 0009d0 7618b509 8223591e cc9ea424 b62a61e3 0009e0 e0fa72b2 43e66cce 7f9f4afd 2866def1 0009f0 d9995854 d6aaaddf 04b01455 41407ffe 000a00 9a038c08 9476785f 49bf458f c00096e3 000a10 c0dd9d88 df60366d f7ad5d48 2432d146 000a20 cd952938 a2d228ad 57f389dc decf21d9 000a30 d31f8edf 19863e30 2f9c1e64 36d8b495 000a40 4d4bdf55 31fb24cd bfe3b8e8 436dff0d 000a50 43640232 a71269b4 dacc53f4 f760eb02 000a60 68d0dd63 2ab8971b 14c97c3b 44d7ef04 000a70 34b362cd 827354da dd585d3f 47ec2c14 000a80 108fc1ef a0188d00 98a5ede5 5a4b9a43 000a90 6ce17b7d cf5b848a cb26031a 3ade1754 000aa0 e4c18c09 c97600ea 2e40867a 28569659 000ab0 5a86849c dbc862b7 dce57ae2 06e53156 000ac0 2163ab53 0470cf48 642c2d18 7ac95adf 000ad0 14071c09 19fb4458 f4045773 08f8eab6 000ae0 ba3ef0f1 dfefc49e 6fc23069 3fbc4970 000af0 5d904c2f 287f6771 9ac79d3b ca539414 000b00 3ce1958a 031f8c6d 2e204397 9591afb8 000b10 9b1081fd cd2aee09 012cb52d f67e6f1f 000b20 e8a03f57 507dc344 2531845a bdf5bb63 000b30 dd4693ea f318e434 03046fc3 6345a28a 000b40 9e9cfa13 c4c6e7b9 83a777f2 21d6872a 000b50 dab3c2f7 adae3d0a 22e505fe 12bf3a0d 000b60 ebbb3403 85015e67 1cf90921 556f17ce 000b70 f4a1b2ab 3895d9ac 86261867 29492d70 000b80 00adcff4 e7807cf7 6f65903a 12435611 000b90 2e227519 fdc27743 00f3b313 f8895a7c 000ba0 bee70736 5fdb7711 a1fbc911 3d1a13c9 000bb0 3d1481da 8370c700 0c33429d f26d8702 000bc0 a4a98eaa 91ef6f70 7f84d804 df080ac9 000bd0 7618b509 8223591e cc9ea424 b62a61e3 000be0 e0fa72b2 43e66cce 7f9f4afd 2866def1 000bf0 d9995854 d6aaaddf 04b01455 41407ffe 000c00 9a038c08 9476785f 49bf458f c00096e3 000c10 c0dd9d88 df60366d f7ad5d48 2432d146 000c20 cd952938 a2d228ad 57f389dc decf21d9 000c30 d31f8edf 19863e30 2f9c1e64 36d8b495 000c40 4d4bdf55 31fb24cd bfe3b8e8 436dff0d 000c50 43640232 a71269b4 dacc53f4 f760eb02 000c60 68d0dd63 2ab8971b 14c97c3b 44d7ef04 000c70 34b362cd 827354da dd585d3f 47ec2c14 000c80 108fc1ef a0188d00 98a5ede5 5a4b9a43 000c90 6ce17b7d cf5b848a cb26031a 3ade1754 000ca0 e4c18c09 c97600ea 2e40867a 28569659 000cb0 5a86849c dbc862b7 dce57ae2 06e53156 000cc0 2163ab53 0470cf48 642c2d18 7ac95adf 000cd0 14071c09 19fb4458 f4045773 08f8eab6 000ce0 ba3ef0f1 dfefc49e 6fc23069 3fbc4970 000cf0 5d904c2f 287f6771 9ac79d3b ca539414 000d00 3ce1958a 031f8c6d 2e204397 9591afb8 000d10 9b1081fd cd2aee09 012cb52d f67e6f1f 000d20 e8a03f57 507dc344 2531845a bdf5bb63 000d30 dd4693ea f318e434 03046fc3 6345a28a 000d40 9e9cfa13 c4c6e7b9 83a777f2 21d6872a 000d50 dab3c2f7 adae3d0a 22e505fe 12bf3a0d 000d60 ebbb3403 85015e67 1cf90921 556f17ce 000d70 f4a1b2ab 3895d9ac 86261867 29492d70 000d80 00adcff4 e7807cf7 6f65903a 12435611 000d90 2e227519 fdc27743 00f3b313 f8895a7c 000da0 bee70736 5fdb7711 a1fbc911 3d1a13c9 000db0 3d1481da 8370c700 0c33429d f26d8702 000dc0 a4a98eaa 91ef6f70 7f84d804 df080ac9 000dd0 7618b509 8223591e cc9ea424 b62a61e3 000de0 e0fa72b2 43e66cce 7f9f4afd 2866def1 000df0 d9995854 d6aaaddf 04b01455 41407ffe 000e00 9a038c08 9476785f 49bf458f c00096e3 000e10 c0dd9d88 df60366d f7ad5d48 2432d146 000e20 cd952938 a2d228ad 57f389dc decf21d9 000e30 d31f8edf 19863e30 2f9c1e64 36d8b495 000e40 4d4bdf55 31fb24cd bfe3b8e8 436dff0d 000e50 43640232 a71269b4 dacc53f4 f760eb02 000e60 68d0dd63 2ab8971b 14c97c3b 44d7ef04 000e70 34b362cd 827354da dd585d3f 47ec2c14 000e80 108fc1ef a0188d00 98a5ede5 5a4b9a43 000e90 6ce17b7d cf5b848a cb26031a 3ade1754 000ea0 e4c18c09 c97600ea 2e40867a 28569659 000eb0 5a86849c dbc862b7 dce57ae2 06e53156 000ec0 2163ab53 0470cf48 642c2d18 7ac95adf 000ed0 14071c09 19fb4458 f4045773 08f8eab6 000ee0 ba3ef0f1 dfefc49e 6fc23069 3fbc4970 000ef0 5d904c2f 287f6771 9ac79d3b ca539414 000f00 3ce1958a 031f8c6d 2e204397 9591afb8 000f10 9b1081fd cd2aee09 012cb52d f67e6f1f 000f20 e8a03f57 507dc344 2531845a bdf5bb63 000f30 dd4693ea f318e434 03046fc3 6345a28a 000f40 9e9cfa13 c4c6e7b9 83a777f2 21d6872a 000f50 dab3c2f7 adae3d0a 22e505fe 12bf3a0d 000f60 ebbb3403 85015e67 1cf90921 556f17ce 000f70 f4a1b2ab 3895d9ac 86261867 29492d70 000f80 00adcff4 e7807cf7 6f65903a 12435611 000f90 2e227519 fdc27743 00f3b313 f8895a7c 000fa0 bee70736 5fdb7711 a1fbc911 3d1a13c9 000fb0 3d1481da 8370c700 0c33429d f26d8702 000fc0 a4a98eaa 91ef6f70 7f84d804 df080ac9 000fd0 7618b509 8223591e cc9ea424 b62a61e3 000fe0 e0fa72b2 43e66cce 7f9f4afd 2866def1 000ff0 d9995854 d6aaaddf 04b01455 41407ffe 001000 98393bc0 02000000 04930800 080617c5 001010 bffff078 00000230 bffff038 0805d591 001020 00000000 00000052 bffff858 0805b89a 001030 00000000 080cfb6c bffff858 0805b76a 001040 00000000 00000000 40161ce0 00000002 001050 080ce7cc 00000000 080708da 000000c8 001060 bffff070 bffff6b0 00000000 0000005f 001070 0806fb30 04000000 080ce7cc 00000000 001080 080cfb0c 00000000 080cf8cc 00000000 001090 080ce54c 00000000 080cf96c 00000000 0010a0 080ce78c 00000000 080cfb0c 00000000 0010b0 080cfb0c 00000000 080ce78c 00000000 0010c0 00000296 bffff358 0000002b 00000000 0010d0 00000000 00000000 40015c60 00000007 0010e0 00000010 00000000 40000a80 00000001 0010f0 40015f18 bffff0dc 4004690c 000000a8 001100 00000000 04000000 4005f868 00000000 001110 00000000 00000000 00000000 00000000 * 001190 00000000 00000000 00000000 bffff1c0 0011a0 bffff250 00000002 bffff2f8 0807d430
On Apr 08, 2002 15:08 +0900, Andy Paul wrote:> - I suppose I can survive without it. Would have used RAID, had I needed an > insurance policy. I am more concerned about not finding the cause and > having the same experience repeated next time.Well, RAID is not a form of backup, especially in a case like this. It only protects you from disk failures, not software screw-ups.> - The error sequence started when a user tried to access some data using > samba. Noticing some strange delay, he cancelled the request, however samba > (?) seemed to have entered some retry loop, trying to access various > inodes/blocks for about 1 hour, and filling the log with errors.Sounds like a software problem to me.> #od -Ax -tx4 /dev/hda9 > 000200 9a038c08 9476785f 49bf458f c00096e3 > : : : : : > 0003f0 d9995854 d6aaaddf 04b01455 41407ffeThis chunk is repeated every few sectors on your disk. This is why I think it looks like a software problem.> 000400 00664000 00cc7892 000a393a 00267129 > 000410 00662dfc 00000000 00000002 00000002 > 000420 00008000 00008000 00004000 3ca7c82d > 000430 3cb11525 00250019 0003ef53 00000001 > 000440 3c05b658 00ed4e00 00000000 00000001 > 000450 00000000 0000000b 00000080 00000004 > 000460 00000002 00000001 a73c96f6 d34646c9 > 000470 8258dcb3 d03f0f27 6168732f 00366572This seems like a normal superblock (probably written out later over the rest of the junk on the disk).> 000800 9a038c08 9476785f 49bf458f c00096e3 > : : : : : > 0009f0 d9995854 d6aaaddf 04b01455 41407ffe > 000a00 9a038c08 9476785f 49bf458f c00096e3 > : : : : : > 000bf0 d9995854 d6aaaddf 04b01455 41407ffe > 000c00 9a038c08 9476785f 49bf458f c00096e3 > : : : : : > 000e00 9a038c08 9476785f 49bf458f c00096e3 > : : : : : > 000ff0 d9995854 d6aaaddf 04b01455 41407ffe> #./findsuper /dev/hda9 512 0 > starting at 0, with 512 byte increments > thisoff block fs_blk_sz blksz grp last_mount > 1024 1 13400210 4096 0 Mon Apr 1 11:38:37 2002Normal superblock...> 8053760 7865 13400210 4096 0 Mon Apr 1 11:38:37 2002 > : : : : : : : : : : : > 8082432 7893 13400210 4096 0 Mon Apr 1 11:38:37 2002Superblocks in the journal...> 134217728 131072 13400210 4096 1 Mon Apr 1 11:38:37 2002 > 402653184 393216 13400210 4096 3 Mon Apr 1 11:38:37 2002 > 671088640 655360 13400210 4096 5 Mon Apr 1 11:38:37 2002 > 939524096 917504 13400210 4096 7 Mon Apr 1 11:38:37 2002 > 1207959552 1179648 13400210 4096 9 Mon Apr 1 11:38:37 2002 > 3355443200 3276800 13400210 4096 25 Mon Apr 1 11:38:37 2002 > 3623878656 3538944 13400210 4096 27 Mon Apr 1 11:38:37 2002 > 6576668672 6422528 13400210 4096 49 Mon Apr 1 11:38:37 2002 > 10871635968 10616832 13400210 4096 81 Mon Apr 1 11:38:37 2002Backup superblocks. ^^^^ Try using some of these numbers for e2fsck, e2fsck -b 131072 /dev/hda9 e2fsck -b 393216 /dev/hda9 e2fsck -b 917504 /dev/hda9 : Cheers, Andreas -- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/
>From: Andreas Dilger <adilger@clusterfs.com> >To: Andy Paul <aaspaul@hotmail.com> >CC: ext3-users@redhat.com >Subject: Re: ext3 crash >Date: Mon, 8 Apr 2002 02:23:17 -0600 > >On Apr 08, 2002 15:08 +0900, Andy Paul wrote: > > - I suppose I can survive without it. Would have used RAID, had I needed >an > > insurance policy. I am more concerned about not finding the cause and > > having the same experience repeated next time. > >Well, RAID is not a form of backup, especially in a case like this. It >only protects you from disk failures, not software screw-ups. > > > - The error sequence started when a user tried to access some data using > > samba. Noticing some strange delay, he cancelled the request, however >samba > > (?) seemed to have entered some retry loop, trying to access various > > inodes/blocks for about 1 hour, and filling the log with errors. > >Sounds like a software problem to me. > > > #od -Ax -tx4 /dev/hda9 > > 000200 9a038c08 9476785f 49bf458f c00096e3 > > : : : : : > > 0003f0 d9995854 d6aaaddf 04b01455 41407ffe > >This chunk is repeated every few sectors on your disk. This is why I >think it looks like a software problem. > > > 000400 00664000 00cc7892 000a393a 00267129 > > 000410 00662dfc 00000000 00000002 00000002 > > 000420 00008000 00008000 00004000 3ca7c82d > > 000430 3cb11525 00250019 0003ef53 00000001 > > 000440 3c05b658 00ed4e00 00000000 00000001 > > 000450 00000000 0000000b 00000080 00000004 > > 000460 00000002 00000001 a73c96f6 d34646c9 > > 000470 8258dcb3 d03f0f27 6168732f 00366572 > >This seems like a normal superblock (probably written out later over the >rest of the junk on the disk). > > > 000800 9a038c08 9476785f 49bf458f c00096e3 > > : : : : : > > 0009f0 d9995854 d6aaaddf 04b01455 41407ffe > > 000a00 9a038c08 9476785f 49bf458f c00096e3 > > : : : : : > > 000bf0 d9995854 d6aaaddf 04b01455 41407ffe > > 000c00 9a038c08 9476785f 49bf458f c00096e3 > > : : : : : > > 000e00 9a038c08 9476785f 49bf458f c00096e3 > > : : : : : > > 000ff0 d9995854 d6aaaddf 04b01455 41407ffe > > > #./findsuper /dev/hda9 512 0 > > starting at 0, with 512 byte increments > > thisoff block fs_blk_sz blksz grp last_mount > > 1024 1 13400210 4096 0 Mon Apr 1 11:38:37 2002 > >Normal superblock... > > > 8053760 7865 13400210 4096 0 Mon Apr 1 11:38:37 2002 > > : : : : : : : : : : : > > 8082432 7893 13400210 4096 0 Mon Apr 1 11:38:37 2002 > >Superblocks in the journal... > > > 134217728 131072 13400210 4096 1 Mon Apr 1 11:38:37 2002 > > 402653184 393216 13400210 4096 3 Mon Apr 1 11:38:37 2002 > > 671088640 655360 13400210 4096 5 Mon Apr 1 11:38:37 2002 > > 939524096 917504 13400210 4096 7 Mon Apr 1 11:38:37 2002 > > 1207959552 1179648 13400210 4096 9 Mon Apr 1 11:38:37 2002 > > 3355443200 3276800 13400210 4096 25 Mon Apr 1 11:38:37 2002 > > 3623878656 3538944 13400210 4096 27 Mon Apr 1 11:38:37 2002 > > 6576668672 6422528 13400210 4096 49 Mon Apr 1 11:38:37 2002 > > 10871635968 10616832 13400210 4096 81 Mon Apr 1 11:38:37 2002 > >Backup superblocks. ^^^^ Try using some of these numbers for e2fsck, > >e2fsck -b 131072 /dev/hda9 >e2fsck -b 393216 /dev/hda9 >e2fsck -b 917504 /dev/hda9 >: >e2fsck produced the following output : --------- # e2fsck -b 131072 /dev/hda9 e2fsck 1.26 (3-Feb-2002) e2fsck: Bad magic number in super-block while trying to open /dev/hda9 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> # e2fsck -b 393216 /dev/hda9 e2fsck 1.26 (3-Feb-2002) e2fsck: Bad magic number in super-block while trying to open /dev/hda9 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> # e2fsck -b 10616832 /dev/hda9 e2fsck 1.26 (3-Feb-2002) e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hda9 Could this be a zero-length partition? # e2fsck -b 6422528 /dev/hda9 e2fsck 1.26 (3-Feb-2002) e2fsck: Bad magic number in super-block while trying to open /dev/hda9 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> ----------- I think I would like to stop at this point, due to lack of time ( and patience). I will reformat the partition tomorrow. Andreas, thank you for your time. Adrian _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com