Cannot find file system superblock error - how to recover?
Did you manage to solve the problem with the subject? Just ha an almost similar problem and badly need your help?? The filesytem is ext3 and have done almost everything. Regards, Shepherd ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386-portbld-freebsd4.8) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Wed, 18 Feb 2004 12:31:55 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Here you should have answered `y' (it doesn't ask you to change anything yet). Let's try that again, shall we? Sorry, ok I went through it again, saying Y to all the Continue? prompts but N to all the ones that talked about changing things. The final result was huge, so instead of posting it here I'll host it on my site: http://vtbsd.net/fschk.txt Sorry for timing out and sending a NAK mail too soon. Well, after all fsck doesn't seem mad (`erase everything and mark fs clean'). Quoting part of it to the list: UNKNOWN FILE TYPE I=5789755 ^ CLEAR? [yn] n 1268475613 BAD I=5789756 -1633222987 BAD I=5789756 2069254589 BAD I=5789756 -575751885 BAD I=5789756 868457706 BAD I=5789756 1801998801 BAD I=5789756 -1342935077 BAD I=5789756 -1580481935 BAD I=5789756 -1823336811 BAD I=5789756 837335149 BAD I=5789756 2115764945 BAD I=5789756 EXCESSIVE BAD BLKS I=5789756 CONTINUE? [yn] y DIRECTORY CORRUPTED I=5789753 OWNER=1001 MODE=40755 SIZE=512 MTIME=Jun 6 07:21 2001 DIR=? SALVAGE? [yn] n MISSING '.' I=5789753 OWNER=1001 MODE=40755 SIZE=512 MTIME=Jun 6 07:21 2001 DIR=? I was, not to be rude, TOO optimistic:( This is, to my mind, one of three things. a) the superblock copy we are using is largely incorrect. b) (the superblock and) several directories are. c) the whole disk is. the first one being more probable in case of a `natural' failure (like power failure or such) (if anyone's willing to second that, I'd like to hear). I have ordered an additional 80GB drive for this very purpose (along w/ an external USB enclosure but we don't have to get that working yet). I will let you know when it arrives. If the next step you want to do is going to make changes, I'm happy to wait until the 2nd drive is here and we can do the dd. Before I read the log, I thought that buying an extra drive for this very purpose wasn't necessary. Now, I've changed my opinion. Thanks! -- DoubleF Census Taker to Housewife: Did you ever have the measles, and, if so, how many? pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Try $ hd /dev/...| grep -A 5 02 00 00 00 0c 00 04 01 2e 00 00 00 02 00 00 00 Well that definitely produced something: bash-2.05b# hd /dev/ad2s1e | grep -A 5 02 00 00 00 0c 00 04 01 2e 00 00 00 02 00 00 002d 02 00 00 00 0c 00 04 01 2e 00 00 00 02 00 00 00 || 002d0010 0c 00 04 02 2e 2a 00 00 00 a0 09 00 10 00 04 00 |.*..| 002d0020 70 69 63 73 00 10 6a c0 00 f8 40 00 14 00 04 08 |[EMAIL PROTECTED]| 002d0030 6f 68 64 5b 6e 70 66 73 00 00 00 00 03 00 00 00 |ohd[npfs| 002d0040 14 00 08 0a 58 42 38 32 43 6b 6e 62 69 63 00 d9 |XB82Cknbic..| 002d0050 00 00 63 00 0c 00 04 03 65 70 63 00 00 58 63 00 |..c.epc..Xc.| -- 002f4000 02 00 00 00 0c 00 04 01 2e 00 00 00 02 00 00 00 || 002f4010 0c 00 04 02 2e 2e 00 00 00 a0 09 00 10 00 04 04 || 002f4020 70 69 63 73 00 14 6a c4 00 f8 40 00 14 00 04 08 |[EMAIL PROTECTED]| 002f4030 6f 6c 64 5f 6e 74 66 73 00 00 00 00 03 00 00 00 |old_ntfs| 002f4040 14 00 08 0a 58 46 38 36 43 6f 6e 66 69 67 00 d9 |XF86Config..| 002f4050 00 00 63 00 0c 00 04 03 65 74 63 00 00 58 63 00 |..c.etc..Xc.| That second one seems to be more intact. pics and old_ntfs and X were directories off /data (there were others). The first match would appear to be slightly corrupted (that etc might have been a backup I made of /etc at some point in case of / failure). It's still churning away but I'm going to assume that it's found all it's going going to and send this email now. For what it's worth, FedEx is estimating Monday the 23rd as delivery of the spare 80GB. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Thu, 19 Feb 2004 06:42:22 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Try $ hd /dev/...| grep -A 5 02 00 00 00 0c 00 04 01 2e 00 00 00 02 00 00 00 Well that definitely produced something: bash-2.05b# hd /dev/ad2s1e | grep -A 5 02 00 00 00 0c 00 04 01 2e 00 00 00 02 00 00 002d 02 00 00 00 0c 00 04 01 2e 00 00 00 02 00 00 00 || 002d0010 0c 00 04 02 2e 2a 00 00 00 a0 09 00 10 00 04 00 |.*..| 002d0020 70 69 63 73 00 10 6a c0 00 f8 40 00 14 00 04 08 |[EMAIL PROTECTED]| 002d0030 6f 68 64 5b 6e 70 66 73 00 00 00 00 03 00 00 00 |ohd[npfs| 002d0040 14 00 08 0a 58 42 38 32 43 6b 6e 62 69 63 00 d9 |XB82Cknbic..| 002d0050 00 00 63 00 0c 00 04 03 65 70 63 00 00 58 63 00 |..c.epc..Xc.| -- 002f4000 02 00 00 00 0c 00 04 01 2e 00 00 00 02 00 00 00 || 002f4010 0c 00 04 02 2e 2e 00 00 00 a0 09 00 10 00 04 04 || 002f4020 70 69 63 73 00 14 6a c4 00 f8 40 00 14 00 04 08 |[EMAIL PROTECTED]| 002f4030 6f 6c 64 5f 6e 74 66 73 00 00 00 00 03 00 00 00 |old_ntfs| 002f4040 14 00 08 0a 58 46 38 36 43 6f 6e 66 69 67 00 d9 |XF86Config..| 002f4050 00 00 63 00 0c 00 04 03 65 74 63 00 00 58 63 00 |..c.etc..Xc.| You created directories in / of that drive (that is, /data) recently, didn't you? That second one seems to be more intact. pics and old_ntfs and X were directories off /data (there were others). The first match would appear to be slightly corrupted (that etc might have been a backup I made of /etc at some point in case of / failure). If you are feeling adventurous (not in the sense of writing anything there yet), you could `walk' the directory structure manually so as to find out if it's still there. Just mask out the inode numbers, use this # hd /dev/ad2s1e | grep -A 5 .. .. .. .. 0c 00 04 01 2e 00 00 00 .. .. .. .. and be ready to read a huge amount of hexdump:). If you wish to see more of a directory, increase the `5' in -A (afterwards context line count). It's still churning away but I'm going to assume that it's found all it's going going to and send this email now. For what it's worth, FedEx is estimating Monday the 23rd as delivery of the spare 80GB. -- DoubleF The illegal we do immediately. The unconstitutional takes a bit longer. -- Henry Kissinger pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Here you should have answered `y' (it doesn't ask you to change anything yet). Let's try that again, shall we? Sorry, ok I went through it again, saying Y to all the Continue? prompts but N to all the ones that talked about changing things. The final result was huge, so instead of posting it here I'll host it on my site: http://vtbsd.net/fschk.txt Well, after all fsck doesn't seem mad (`erase everything and mark fs clean'). But if you are really are paranoid, as you should be, you should copy the whole contents of the harddrive, maybe to a remote machine, by dd (over NFS, perhaps). Perhaps the `sparse' dd option would help save a bit of space (by creating `holes' in the file where there were NUL's on the harddrive). I have ordered an additional 80GB drive for this very purpose (along w/ an external USB enclosure but we don't have to get that working yet). I will let you know when it arrives. If the next step you want to do is going to make changes, I'm happy to wait until the 2nd drive is here and we can do the dd. Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Sorry, you were recovering an 80G disk, and now you say the 80G has 4.9 on it. Did you erase anything? Is this a remote machine? No, it was not the drive that had the OS on it. It was originally mounted as /data on a system that had FreeBSD 5.1 installed on a separate drive. We determined the 80GB was UFS1. You wanted to try troubleshooting using FreeBSD 4.9, so I obtained a spare system which I installed FreeBSD 4.9-RELEASE on. I then moved the 80GB from the 5.1 system (which is actually 5.2 now) and installed it into the 4.9 system on the 2nd controller. So now 4.9 is installed on a 20GB on /dev/ad0, and our problem 80GB is /dev/ad2. You can boot 4.9, right? Examine the output of disklabel ...s1 and ...s1c to make heart feel better. bash-2.05b# disklabel /dev/ad2s1 # /dev/ad2s1: type: ESDI disk: ad6s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 9731 sectors/unit: 156344517 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1563445170unused0 0# (Cyl.0 - 9731*) e: 15634451704.2BSD 2048 1638489 # (Cyl.0 - 9731*) bash-2.05b# disklabel /dev/ad2s1c # /dev/ad2s1c: type: ESDI disk: ad6s1 label: flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 9731 sectors/unit: 156344517 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1563445170unused0 0# (Cyl.0 - 9731*) e: 15634451704.2BSD 2048 1638489 # (Cyl.0 - 9731*) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 3 Feb 2004 23:05:05 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Sorry, you were recovering an 80G disk, and now you say the 80G has 4.9 on it. Did you erase anything? Is this a remote machine? No, it was not the drive that had the OS on it. It was originally mounted as /data on a system that had FreeBSD 5.1 installed on a separate drive. We determined the 80GB was UFS1. You wanted to try troubleshooting using FreeBSD 4.9, so I obtained a spare system which I installed FreeBSD 4.9-RELEASE on. I then moved the 80GB from the 5.1 system (which is actually 5.2 now) and installed it into the 4.9 system on the 2nd controller. So now 4.9 is installed on a 20GB on /dev/ad0, and our problem 80GB is /dev/ad2. Thank you for the explanation. You can boot 4.9, right? Examine the output of disklabel ...s1 and ...s1c to make heart feel better. bash-2.05b# disklabel /dev/ad2s1 [snip] 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1563445170unused0 0# (Cyl.0 - 9731*) e: 15634451704.2BSD 2048 1638489 # (Cyl.0 - 9731*) bash-2.05b# disklabel /dev/ad2s1c [snip] 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1563445170unused0 0# (Cyl.0 - 9731*) e: 15634451704.2BSD 2048 1638489 # (Cyl.0 - 9731*) Good:) Well, as it's UFS1 as we've figured out, the next logical thing would be to try mounting /dev/ad2s1c r/o, and if that fails, try fscking it. -- DoubleF The faster we go, the rounder we get. -- The Grateful Dead pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Well, as it's UFS1 as we've figured out, the next logical thing would be to try mounting /dev/ad2s1c r/o, and if that fails, try fscking it. bash-2.05b# mount -r /dev/ad2s1c /data mount: /dev/ad2s1c on /data: incorrect super block bash-2.05b# fsck /dev/ad2s1c ** /dev/ad2s1c BAD SUPER BLOCK: MAGIC NUMBER WRONG /dev/ad2s1c: NOT LABELED AS A BSD FILE SYSTEM (unused) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Wed, 4 Feb 2004 06:06:06 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Well, as it's UFS1 as we've figured out, the next logical thing would be to try mounting /dev/ad2s1c r/o, and if that fails, try fscking it. bash-2.05b# mount -r /dev/ad2s1c /data mount: /dev/ad2s1c on /data: incorrect super block bash-2.05b# fsck /dev/ad2s1c ** /dev/ad2s1c BAD SUPER BLOCK: MAGIC NUMBER WRONG /dev/ad2s1c: NOT LABELED AS A BSD FILE SYSTEM (unused) And /dev/ad2s1e? -- DoubleF Excellent day for drinking heavily. Spike office water cooler. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: And /dev/ad2s1e? bash-2.05b# mount -r /dev/ad2s1e /data mount: /dev/ad2s1e on /data: incorrect super block bash-2.05b# fsck /dev/ad2s1e ** /dev/ad2s1e BAD SUPER BLOCK: MAGIC NUMBER WRONG LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y USING ALTERNATE SUPERBLOCK AT 32 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes 416 BAD I=2 412 BAD I=3 424 BAD I=4 414 BAD I=4 417 BAD I=5 INCORRECT BLOCK COUNT I=4257794 (8928 should be 9952) CORRECT? [yn] Hmmm that looks more promising, although I'm not sure exactly what it's trying to warn me about, or how bad things are from that, so I'm going to leave it there for now. :) And if I remember correctly, even though fsck has used an alternate superblock to perform the repair process, it hasn't actually replaced the master superblock with the alternate one, so I'd still need to fix that manually somehow... correct? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Wed, 4 Feb 2004 06:37:11 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: And /dev/ad2s1e? bash-2.05b# mount -r /dev/ad2s1e /data mount: /dev/ad2s1e on /data: incorrect super block bash-2.05b# fsck /dev/ad2s1e ** /dev/ad2s1e BAD SUPER BLOCK: MAGIC NUMBER WRONG LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y USING ALTERNATE SUPERBLOCK AT 32 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes 416 BAD I=2 412 BAD I=3 424 BAD I=4 414 BAD I=4 417 BAD I=5 INCORRECT BLOCK COUNT I=4257794 (8928 should be 9952) CORRECT? [yn] Hmmm that looks more promising, although I'm not sure exactly what it's trying to warn me about, or how bad things are from that, so I'm going to leave it there for now. :) This really looks weird. The incorrect block counts seem somewhat suspicious. Try using fsck -n (answer `no'), and recording what else comes up. If you know what fsdb(8) is, it might be helpful (still with the -r (read-only) option, and the -d option as well). I don't, but I'm learning it intensively at the moment:). And if I remember correctly, even though fsck has used an alternate superblock to perform the repair process, it hasn't actually replaced the master superblock with the alternate one, so I'd still need to fix that manually somehow... correct? Yes, by means of dd. -- DoubleF The only possible interpretation of any research whatever in the `social sciences' is: some do, some don't. -- Ernest Rutherford pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Try using fsck -n (answer `no'), and recording what else comes up. That won't work, because it answers no to the first question of looking for alternate superblocks, then aborts immediately. So I'm just going to manually say no to all questions after yes to the first: bash-2.05b# fsck /dev/ad2s1e ** /dev/ad2s1e BAD SUPER BLOCK: MAGIC NUMBER WRONG LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y USING ALTERNATE SUPERBLOCK AT 32 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes 416 BAD I=2 412 BAD I=3 424 BAD I=4 414 BAD I=4 417 BAD I=5 INCORRECT BLOCK COUNT I=4257794 (8928 should be 9952) CORRECT? [yn] n 17227776 DUP I=4257795 1722 DUP I=4257795 17227778 DUP I=4257795 17227779 DUP I=4257795 17227780 DUP I=4257795 17227781 DUP I=4257795 17227782 DUP I=4257795 17227783 DUP I=4257795 17227784 DUP I=4257795 17227785 DUP I=4257795 17227786 DUP I=4257795 EXCESSIVE DUP BLKS I=4257795 CONTINUE? [yn] n UPDATE STANDARD SUPERBLOCK? [yn] n * FILE SYSTEM MARKED DIRTY * If you know what fsdb(8) is, it might be helpful (still with the -r (read-only) option, and the -d option as well). I don't, but I'm learning it intensively at the moment:). I don't, and the man page sufficiently put the fear of the almighty in me as far as it goes Use this tool with extreme caution--you can damage an FFS file system beyond what fsck(8) can repair. It's also a bit out of my league as far as understanding how to make use of it. so I'd still need to fix that manually somehow... correct? Yes, by means of dd. Hmm although that last fsck question UPDATE STANDARD SUPERBLOCK? [yn] seemed interesting. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Wed, 4 Feb 2004 08:26:47 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Try using fsck -n (answer `no'), and recording what else comes up. That won't work, because it answers no to the first question of looking for alternate superblocks, then aborts immediately. So I'm just going to manually say no to all questions after yes to the first: bash-2.05b# fsck /dev/ad2s1e ** /dev/ad2s1e BAD SUPER BLOCK: MAGIC NUMBER WRONG LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y USING ALTERNATE SUPERBLOCK AT 32 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes 416 BAD I=2 412 BAD I=3 424 BAD I=4 414 BAD I=4 417 BAD I=5 INCORRECT BLOCK COUNT I=4257794 (8928 should be 9952) CORRECT? [yn] n 17227776 DUP I=4257795 1722 DUP I=4257795 17227778 DUP I=4257795 17227779 DUP I=4257795 17227780 DUP I=4257795 17227781 DUP I=4257795 17227782 DUP I=4257795 17227783 DUP I=4257795 17227784 DUP I=4257795 17227785 DUP I=4257795 17227786 DUP I=4257795 EXCESSIVE DUP BLKS I=4257795 CONTINUE? [yn] n Here you should have answered `y' (it doesn't ask you to change anything yet). Let's try that again, shall we? UPDATE STANDARD SUPERBLOCK? [yn] n * FILE SYSTEM MARKED DIRTY * Well, after all fsck doesn't seem mad (`erase everything and mark fs clean'). But if you are really are paranoid, as you should be, you should copy the whole contents of the harddrive, maybe to a remote machine, by dd (over NFS, perhaps). Perhaps the `sparse' dd option would help save a bit of space (by creating `holes' in the file where there were NUL's on the harddrive). If you know what fsdb(8) is, it might be helpful (still with the -r (read-only) option, and the -d option as well). I don't, but I'm learning it intensively at the moment:). I don't, and the man page sufficiently put the fear of the almighty in me as far as it goes Use this tool with extreme caution--you can damage an FFS file system beyond what fsck(8) can repair. It's also a bit out of my league as far as understanding how to make use of it. It's not harmful in `-r'-mode, but I'm afraid it won't help because it wouldn't even use an alternate superblock, as I've found out. so I'd still need to fix that manually somehow... correct? Yes, by means of dd. Hmm although that last fsck question UPDATE STANDARD SUPERBLOCK? [yn] seemed interesting. That's another option. -- DoubleF An elephant is a mouse with an operating system. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
Hello, gentlemen. For those of you still interested in this little adventure, I now have the 80GB drive mounted on the 2nd IDE controller in its own dedicated FreeBSD 4.9-RELEASE system. ad0: 19092MB WDC WD200BB-75AUA1 [38792/16/63] at ata0-master UDMA100 ad2: 76345MB MAXTOR 6L080J4 [155114/16/63] at ata1-master UDMA33 I'm ready to proceed if you're still willing, if not I understand! :) (If anyone else new to this problem and would like to help, you can use google or the archives, or I can catch you up if you'd like) Many thanks already to all who have helped so far. = Scott I. Remick --==-- Jabber IM: [EMAIL PROTECTED] Save the internet - Use a Mozilla-based browser: http://vtbsd.net/mozilla/ Jabber - Ad-free, and because MSN and AIM just plain suck: http://www.jabber.org/ FreeBSD: Because making unix user-friendly is easier than debugging Windows. http://vtbsd.net/freebsd/ Out with Eisner, bring back Disney: http://www.savedisney.com/ A: Because it reverses the logical flow of conversation. Q: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 3 Feb 2004 16:05:26 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: Hello, gentlemen. For those of you still interested in this little adventure, I now have the 80GB drive mounted on the 2nd IDE controller in its own dedicated FreeBSD 4.9-RELEASE system. ad0: 19092MB WDC WD200BB-75AUA1 [38792/16/63] at ata0-master UDMA100 ad2: 76345MB MAXTOR 6L080J4 [155114/16/63] at ata1-master UDMA33 I'm ready to proceed if you're still willing, if not I understand! :) Oh, there are survivors:) Sorry, you were recovering an 80G disk, and now you say the 80G has 4.9 on it. Did you erase anything? Is this a remote machine? (If anyone else new to this problem and would like to help, you can use google or the archives, or I can catch you up if you'd like) Many thanks already to all who have helped so far. You can boot 4.9, right? Examine the output of disklabel ...s1 and ...s1c to make heart feel better. -- DoubleF We have only two things to worry about: That things will never get back to normal, and that they already have. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I mean trying to mount it, to fsck it, using dd|hd to find the superblock, etc. I just want to be *really* sure we know what we are doing. Well, I don't have experience making bootable FreeBSD floppies... it might be more useful for me to grab a small spare HDD and install 4.9 on it. Should I do that and get back to you once I'm ready? While we are on that, do you have an empty disk to copy this disk's contents to? I'm not sure, but maybe I have an idea... I could probably come up with something. Would it have to be installed in the machine, or just available on the network? Unfortunately I don't remember how much data was used on that drive so I don't know what my goal is. :( ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 15:05, Sergey 'DoubleF' Zaharchenko wrote: On Tue, 6 Jan 2004 13:29:26 +1030 Malcolm Kay [EMAIL PROTECTED] probably wrote: On Tue, 6 Jan 2004 10:59, Scott I. Remick wrote: Sorry for the delay... holidays had me busy. Me too:) Hopefully you're still around and interested in picking up where we left off. I think we're definitely onto something... Looking back over some of your e-mails I find: QUOTE su-2.05b# disklabel -r /dev/ad6s1c # /dev/ad6s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 156344517 63unused0 0 # raw part, don't edit e: 156344517 634.2BSD 2048 1638489 partition c: partition extends past end of unit disklabel: partition c doesn't start at 0! disklabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit That doesn't look good. ENDQUOTE The 63 offset is spurious. I've seen this before somewhere but can't remember the details -- i.e the value 63. I know where you've seen this. The normal offset for the first *slice* is 63 sectors, for some historical reasons (those extra sectors were to be used for bad block replacement or something like that). Yes, I expect it in the output from fdisk. Ignoring for the moment that the BIOS ideas of geometry has nothing to do with the physical reality; all slices start at sector 1 of a track so having used sector 1 of the first track (cylinder 0 head 0) for the MBR, the first slice must start at cylinder 0 head 1 sector 1; usually an offset of 63 with the assumed virtual geometry. (Nothing to do with bad block replacement which on modern drives is almost completely hidden) But I have seen the 63 before in corrupted disklabels, not just slice positions. Not sure how the 63 made it into the disklabel, though. Neither do I. Malcolm Kay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 19:43:44 +1030 Malcolm Kay [EMAIL PROTECTED] probably wrote: On Tue, 6 Jan 2004 15:05, Sergey 'DoubleF' Zaharchenko wrote: On Tue, 6 Jan 2004 13:29:26 +1030 Malcolm Kay [EMAIL PROTECTED] probably wrote: On Tue, 6 Jan 2004 10:59, Scott I. Remick wrote: Sorry for the delay... holidays had me busy. Me too:) Hopefully you're still around and interested in picking up where we left off. I think we're definitely onto something... Looking back over some of your e-mails I find: QUOTE su-2.05b# disklabel -r /dev/ad6s1c # /dev/ad6s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 156344517 63unused0 0 # raw part, don't edit e: 156344517 634.2BSD 2048 1638489 partition c: partition extends past end of unit disklabel: partition c doesn't start at 0! disklabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit That doesn't look good. ENDQUOTE The 63 offset is spurious. I've seen this before somewhere but can't remember the details -- i.e the value 63. I know where you've seen this. The normal offset for the first *slice* is 63 sectors, for some historical reasons (those extra sectors were to be used for bad block replacement or something like that). Yes, I expect it in the output from fdisk. Ignoring for the moment that the BIOS ideas of geometry has nothing to do with the physical reality; all slices start at sector 1 of a track so having used sector 1 of the first track (cylinder 0 head 0) for the MBR, the first slice must start at cylinder 0 head 1 sector 1; usually an offset of 63 with the assumed virtual geometry. (Nothing to do with bad block replacement which on modern drives is almost completely hidden) Yes I know, I meant used to be used for:) But I have seen the 63 before in corrupted disklabels, not just slice positions. Maybe in dedicated disklabels? How did they get *that* corrupted? Not sure how the 63 made it into the disklabel, though. Neither do I. Malcolm Kay -- DoubleF You look like a million dollars. All green and wrinkled. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 19:57:09 +1030 Malcolm Kay [EMAIL PROTECTED] probably wrote: On Tue, 6 Jan 2004 15:38, Scott I. Remick wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I wonder whether editing the label and setting both offsets to 0 might solve the problem. It definitely seems like that, as the actual offset of the partition is 0, as dd shows. Ok, sounds like a plan. Not that I know what I'm doing. Should I use something like the following command to save my current disklabel? bsdlabel /dev/ad6s1c disklabel.ad6s1c.backup Then do I just edit a copy of that textfile, change the offsets to 0, then write it back like this? bsdlabel -R /dev/ad6s1c dislabel.ad6s1c.new And maybe prefix that by a $ bsdlabel -R /dev/ad6s1c dislabel.ad6s1c.new which would just check your new layout for errors, without writing anything, and print your file out as disklabel understands it. And lastly... your talk about offsets. The man page for bsdlabel describes using it on the whole disk (ad6) and not a slice or partition. If I run it It can't be fdisk that you are reading about? on ad6, I get: bsdlabel: /dev/ad6: no valid label found Beware; if you write a disklabel (or presumably bsdlabel; I have no experience with 5.x) to ad6 you create a dangerously dedicated disk, i.e. a disk without slices. And of course the label isn't there, just because nobody wanted a `DD' disk. If I run it on the slice ad6s1 I get: # /dev/ad6s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1563445170unused0 0 # raw part, don't edit e: 15634451704.2BSD 2048 1638489 And there I see the offset of 0 you might be talking about...? Are we looking at the proper label? Just want to make sure before I mess things up. Are you saying that the disklabels reported for ad6s1 and ad6s1c are different? And the `new' one seems to be correct for a 80G drive (+- a couple of megabytes)? Have you touched anything? Now, mount might work. Under FreeBSD 4.x ad6s1 and ad6s1c would normally be aliases referencing the entire slice. Maybe 5.x is different! I'm now very confused. Uhum. disklabel said that the offset was 63 in your previous posting, didn't it? What does # ls -l /dev/ad6s1 /dev/ad6s1c say? Any differences? I have none. What is reported by fdisk? Let me guess: a single large slice. Malcolm Kay Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- DoubleF [Sir Stafford Cripps] has all the virtues I dislike and none of the vices I admire. -- Winston Churchill pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Malcolm Kay [EMAIL PROTECTED] wrote: Beware; if you write a disklabel (or presumably bsdlabel; I have no experience with 5.x) to ad6 you create a dangerously dedicated disk, i.e. a disk without slices. Ok. I am not saying that's what I want to do, I only mentioned it because the man page for disklabel/bsdlabel uses the entire disk (/dev/da0) as an example. man disklabel brings up bsdlabel, which is why I mention bsdlabel instead. http://www.freebsd.org/cgi/man.cgi?query=bsdlabel Are you saying that the disklabels reported for ad6s1 and ad6s1c are different? This is correct. Your surprise suggests that it was good I mentioned that, eh? :) Glad I haven't done anything yet. In summary, ad6s1 returns an offset of 0 and no error. ad6s1c returns an offset of 63 and the rest of the info is identical except for the following error tagged on at the end: partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit Under FreeBSD 4.x ad6s1 and ad6s1c would normally be aliases referencing the entire slice. Maybe 5.x is different! I'm now very confused. I'm not sure... maybe Sergey wants to pipe in here on this point? What is reported by fdisk? Ah, I'm at work now. Can't do that from here... I'll let you know later. Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: And maybe prefix that by a $ bsdlabel -R /dev/ad6s1c dislabel.ad6s1c.new which would just check your new layout for errors, without writing anything, and print your file out as disklabel understands it. So you're saying, run it as user and not root for the sake of testing it in a read-only setting? Would that be better than using -n? From the man page: The -n stops the bsdlabel program right before the disk would have been modified, and displays the result instead of writing it. And lastly... your talk about offsets. The man page for bsdlabel describes using it on the whole disk (ad6) and not a slice or partition. If I run it It can't be fdisk that you are reading about? Nope. man bsdlabel mentions: disk represents the disk in question, and may be in the form da0 or /dev/da0. It will display the partition layout. But I see now all the later examples mention da0s1 so maybe I misunderstood. And the `new' one seems to be correct for a 80G drive (+- a couple of megabytes)? Have you touched anything? Now, mount might work. Haven't changed anything yet. Which one are you calling the new one? Mount would be done on the partion (ad6s1c) which gives errors with bsdlabel and has an offset of 63, not the whole slice (ad6s1) which has an offset of 0 and doesn't give errors (with bsdlabel). Uhum. disklabel said that the offset was 63 in your previous posting, didn't it? 63 for ad6s1c, 0 for ad6s1. This is what's got Malcolm confused. What does # ls -l /dev/ad6s1 /dev/ad6s1c say? Any differences? I have none. su-2.05b# ls -l /dev/ad6s1 /dev/ad6s1c crw-r- 1 root operator4, 20 Dec 29 08:11 /dev/ad6s1 crw-r- 1 root operator4, 21 Dec 29 08:11 /dev/ad6s1c And to recap: su-2.05b# bsdlabel /dev/ad6s1 # /dev/ad6s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1563445170unused0 0 # raw part, don't edit e: 15634451704.2BSD 2048 1638489 su-2.05b# bsdlabel /dev/ad6s1c # /dev/ad6s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 156344517 63unused0 0 # raw part, don't edit e: 156344517 634.2BSD 2048 1638489 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 06:31:08 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: And maybe prefix that by a $ bsdlabel -R /dev/ad6s1c dislabel.ad6s1c.new Sorry that was to be $ bsdlabel -R -n /dev/ad6s1c dislabel.ad6s1c.new :( which would just check your new layout for errors, without writing anything, and print your file out as disklabel understands it. So you're saying, run it as user and not root for the sake of testing it in a read-only setting? Would that be better than using -n? From the man page: The -n stops the bsdlabel program right before the disk would have been modified, and displays the result instead of writing it. And lastly... your talk about offsets. The man page for bsdlabel describes using it on the whole disk (ad6) and not a slice or partition. If I run it It can't be fdisk that you are reading about? Nope. man bsdlabel mentions: disk represents the disk in question, and may be in the form da0 or /dev/da0. It will display the partition layout. But I see now all the later examples mention da0s1 so maybe I misunderstood. A little before that the manual says: Disk device name All disklabel forms require a disk device name, which should always be the raw device name representing the disk or slice. For example da0 rep- resents the entire disk regardless of any DOS partitioning, and da0s1 represents a slice. Some devices, most notably ccd, require that the So that da0 is just an example, albeit a perverted one. And the `new' one seems to be correct for a 80G drive (+- a couple of megabytes)? Have you touched anything? Now, mount might work. Haven't changed anything yet. Which one are you calling the new one? Mount The one you sent the last time (with the 0-s). would be done on the partion (ad6s1c) which gives errors with bsdlabel and has an offset of 63, not the whole slice (ad6s1) which has an offset of 0 and doesn't give errors (with bsdlabel). Uhum. disklabel said that the offset was 63 in your previous posting, didn't it? 63 for ad6s1c, 0 for ad6s1. This is what's got Malcolm confused. It confuses me too. What does # ls -l /dev/ad6s1 /dev/ad6s1c say? Any differences? I have none. su-2.05b# ls -l /dev/ad6s1 /dev/ad6s1c crw-r- 1 root operator4, 20 Dec 29 08:11 /dev/ad6s1 crw-r- 1 root operator4, 21 Dec 29 08:11 /dev/ad6s1c Indeed it's not like in 4.x, where they were the same. And what about # ls -l /dev/ad6s1a /dev/ad6s1b (these minor numbers don't seem to be in order). Anyway, the correct beginning for the filesystem is 0 (starting with ad6s1), as the superblock is 16 sectors from there. And to recap: su-2.05b# bsdlabel /dev/ad6s1 # /dev/ad6s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1563445170unused0 0 # raw part, don't edit e: 15634451704.2BSD 2048 1638489 su-2.05b# bsdlabel /dev/ad6s1c # /dev/ad6s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 156344517 63unused0 0 # raw part, don't edit e: 156344517 634.2BSD 2048 1638489 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit Indeed. I'm confused. 5.x doesn't look like 4.x. 2 different(?) labels on the same slice don't look good to me (or are the nubers just calculated differently?). I will probably download some 5.1 boot floppies to reproduce the situation. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- DoubleF Speak softly and carry a +6 two-handed sword. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Sorry that was to be $ bsdlabel -R -n /dev/ad6s1c dislabel.ad6s1c.new :( No worries... I figured it out :) Indeed it's not like in 4.x, where they were the same. And what about # ls -l /dev/ad6s1a /dev/ad6s1b (these minor numbers don't seem to be in order). Neither exists. Just so you know: My motherboard (Asus A7V133) has 2 integrated IDE controllers. Besides the native VIA controller there is a Promise ATA100. The following are the relevant snippets from dmesg: atapci0: VIA 82C686B UDMA100 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 atapci1: Promise PDC20265 UDMA100 controller port 0x8000-0x803f,0x8400-0x8403,0x8800-0x8807,0x9000-0x9003,0x9400-0x9407 mem 0xd400-0xd401 irq 10 at device 17.0 on pci0 ata2: at 0x9400 on atapci1 ata3: at 0x8800 on atapci1 ad4: 19595MB MAXTOR 6L020L1 [39813/16/63] at ata2-master UDMA100 ad6: 76345MB MAXTOR 6L080J4 [155114/16/63] at ata3-master UDMA100 acd0: CDROM CRD-8400B at ata0-master PIO4 Mounting root from ufs:/dev/ad4s1a cd0 at ata0 bus 0 target 0 lun 0 cd0: LG CD-ROM CRD-8400B 1.03 Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: cd present [279440 x 2048 byte records] (yes, I use atapicam) and ls /dev/ad*: crw-r- 1 root operator4, 10 Dec 29 08:11 /dev/ad4 crw-r- 1 root operator4, 12 Dec 29 08:11 /dev/ad4s1 crw-r- 1 root operator4, 14 Dec 29 03:11 /dev/ad4s1a crw-r- 1 root operator4, 15 Dec 29 08:11 /dev/ad4s1b crw-r- 1 root operator4, 16 Dec 29 08:11 /dev/ad4s1c crw-r- 1 root operator4, 17 Dec 29 03:11 /dev/ad4s1d crw-r- 1 root operator4, 18 Dec 29 03:11 /dev/ad4s1e crw-r- 1 root operator4, 19 Dec 29 03:11 /dev/ad4s1f crw-r- 1 root operator4, 13 Dec 29 08:11 /dev/ad6 crw-r- 1 root operator4, 20 Dec 29 08:11 /dev/ad6s1 crw-r- 1 root operator4, 21 Dec 29 08:11 /dev/ad6s1c crw-r- 1 root operator4, 22 Dec 29 08:11 /dev/ad6s1e Let me know if you come up with any suggestions on what I should try next. Thanks ever so much! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 08:32:31 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: I'm in the process of downloading the floppies... --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Sorry that was to be $ bsdlabel -R -n /dev/ad6s1c dislabel.ad6s1c.new :( No worries... I figured it out :) Indeed it's not like in 4.x, where they were the same. And what about # ls -l /dev/ad6s1a /dev/ad6s1b (these minor numbers don't seem to be in order). Neither exists. Just so you know: My motherboard (Asus A7V133) has 2 Ouch! I've forgotten about devfs. So these numbers could be OK. integrated IDE controllers. Besides the native VIA controller there is a Promise ATA100. The following are the relevant snippets from dmesg: And what about ad4? Does disklabel show different values for the slice and the `c' partition? -- DoubleF Chicago law prohibits eating in a place that is on fire. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I'm in the process of downloading the floppies... ok cool And what about ad4? Does disklabel show different values for the slice and the `c' partition? Hmm not only are they different as w/ ad6, but I get the same error on the c partition: su-2.05b# bsdlabel /dev/ad4s1 # /dev/ad4s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 102400004.2BSD 2048 16384 64008 b: 2097152 1024000 swap c: 401314410unused0 0 # raw part, don't edit d: 524288 31211524.2BSD 2048 16384 32776 e: 1024000 36454404.2BSD 2048 16384 64008 f: 35462001 46694404.2BSD 2048 16384 28552 su-2.05b# bsdlabel /dev/ad4s1c # /dev/ad4s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 1024000 634.2BSD 2048 16384 64008 b: 2097152 1024063 swap c: 40131441 63unused0 0 # raw part, don't edit d: 524288 31212154.2BSD 2048 16384 32776 e: 1024000 36455034.2BSD 2048 16384 64008 f: 35462001 46695034.2BSD 2048 16384 28552 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition f: partition extends past end of unit The plot thickens... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 09:12:22 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I'm in the process of downloading the floppies... ok cool I can't find a zero-bad floppy in this place! It's all the holidays! And what about ad4? Does disklabel show different values for the slice and the `c' partition? Hmm not only are they different as w/ ad6, but I get the same error on the c partition: su-2.05b# bsdlabel /dev/ad4s1 # /dev/ad4s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 102400004.2BSD 2048 16384 64008 b: 2097152 1024000 swap c: 401314410unused0 0 # raw part, don't edit d: 524288 31211524.2BSD 2048 16384 32776 e: 1024000 36454404.2BSD 2048 16384 64008 f: 35462001 46694404.2BSD 2048 16384 28552 su-2.05b# bsdlabel /dev/ad4s1c # /dev/ad4s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 1024000 634.2BSD 2048 16384 64008 b: 2097152 1024063 swap c: 40131441 63unused0 0 # raw part, don't edit d: 524288 31212154.2BSD 2048 16384 32776 e: 1024000 36455034.2BSD 2048 16384 64008 f: 35462001 46695034.2BSD 2048 16384 28552 partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition f: partition extends past end of unit The plot thickens... With `c', they're all offset by 63(why?). But still, you can mount the partitions on the ad4s1, so the disklabel should be ok... -- DoubleF Is your job running? You'd better go catch it! pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I can't find a zero-bad floppy in this place! It's all the holidays! That's what AOL disks (vs. discs) used to be good for. :) With `c', they're all offset by 63(why?). But still, you can mount the partitions on the ad4s1, so the disklabel should be ok... Yeah. Starts to suggest what we were thinking was a evidence related to the problem is really unrelated and normal behavior (is disklabel/bsdlabel only meant to be run on slices and not bsd-partitions?). Are we looking in the wrong place? What about that potentially good superblock we found a while ago? (the skip 16 one that contained /data in it) Should we be saving that somewhere while we can? (how?) Anyone out there know 5.x file-system dirtiness like the back of their hand? C'mon, you know you wanna join the fun. :) Where's my time machine so I can go back and back up this drive... ah well I'm learning a ton. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 09:48:40 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I can't find a zero-bad floppy in this place! It's all the holidays! That's what AOL disks (vs. discs) used to be good for. :) With `c', they're all offset by 63(why?). But still, you can mount the partitions on the ad4s1, so the disklabel should be ok... Yeah. Starts to suggest what we were thinking was a evidence related to the problem is really unrelated and normal behavior (is disklabel/bsdlabel only meant to be run on slices and not bsd-partitions?). Are we looking in the wrong place? After trying out 5.2-RC2, it seems like the offsets reported with the `c' slice are from the beginning of the disk, not from the beginning of the slice. That accounts for the +63 difference. I guess it's documented somewhere, but as I don't use 5.x I haven't read its docs. What about that potentially good superblock we found a while ago? (the skip 16 one that contained /data in it) Should we be saving that somewhere while we can? (how?) I think you already have a copy (the data at offset 32 seems to be it). If you want, do a # dd if=/dev/ad6s1 skip=16 count=16 of=/some/file Please tell me everything what you tried to use to mount/fsck the drive (and the results, of course). Anyone out there know 5.x file-system dirtiness like the back of their hand? C'mon, you know you wanna join the fun. :) Try booting from a 4.x floppy and doing it all over again... The FS is UFS1, isn't it? -- DoubleF Why does New Jersey have more toxic waste dumps and California have more lawyers? New Jersey had first choice. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I can't find a zero-bad floppy in this place! It's all the holidays! That's what AOL disks (vs. discs) used to be good for. :) With `c', they're all offset by 63(why?). But still, you can mount the partitions on the ad4s1, so the disklabel should be ok... Yeah. Starts to suggest what we were thinking was a evidence related to the problem is really unrelated and normal behavior (is disklabel/bsdlabel only meant to be run on slices and not bsd-partitions?). Sorry, I haven't been following this whole thread and so am not responding to your real problem/question. But, just in regards to this fragment: You have it backwards in this question. Disklabel is meant to run only on bsd partitions and not slices. Slices (1-4) are the major divisions of the disk and partitions (a-h) are divisions within slices. Fdisk is what creates slices. jerry Are we looking in the wrong place? What about that potentially good superblock we found a while ago? (the skip 16 one that contained /data in it) Should we be saving that somewhere while we can? (how?) Anyone out there know 5.x file-system dirtiness like the back of their hand? C'mon, you know you wanna join the fun. :) Where's my time machine so I can go back and back up this drive... ah well I'm learning a ton. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I think you already have a copy (the data at offset 32 seems to be it). If you want, do a # dd if=/dev/ad6s1 skip=16 count=16 of=/some/file ok, done. Is there a way to use fsck_ufs -b now to fix this? Or is that premature? And if I remember correctly, that doesn't actually APPLY the alternate superblock... it just allows fsck to run while utilizing an alternate one. So we need to use some sort of dd command to copy it to the proper location, correct? Please tell me everything what you tried to use to mount/fsck the drive (and the results, of course). Well, my memory is sketchy so I don't know how much use it'd be. But I was saving a file to /data (ad6) when the system hung. Then it rebooted on its own. Of course fsck ran on bootup but it gave up and told me I had to run it manually. When I did (I don't remember any parameters I specifically used, if any) I got: /dev/ad6s1c Cannot find file system superblock /dev/ad6s1c: NOT LABELED AS A BSD FILE SYSTEM I remember there being some of the other common message for little things that you just tell it to go ahead and fix. But the above error was a brick wall and would keep me from going multi-user. Ultimately I had to comment-out the line in fstab: #/dev/ad6s1c/data ufs rw 2 2 So I could at least boot. And that's the way I've been ever since. Trying to mount it now gives: su-2.05b# mount -r /dev/ad6s1c /data mount: /dev/ad6s1c on /data: incorrect super block And so we stand. Try booting from a 4.x floppy and doing it all over again... The FS is UFS1, isn't it? Ummm... doing what all over again? Wipe the disk and redo the partitions? I hope we're not quite there yet. How does using 4.x give me an advantage over 5.1? I'm not clear on that part. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
--- Jerry McAllister [EMAIL PROTECTED] wrote: (is disklabel/bsdlabel only meant to be run on slices and not bsd-partitions?). You have it backwards in this question. Disklabel is meant to run only on bsd partitions and not slices. Slices (1-4) are the major divisions of the disk and partitions (a-h) are divisions within slices. Fdisk is what creates slices. Ok, well the reason I thought it might be the other way is because if you run disklabel (bsdlabel) on a slice (such as /dev/ad4s1 on my machine, which is working, or /dev/ad0s1 on another machine I have access to) it works fine (and reports an offset of 0), but if you run it on the partition (/dev/ad0s1c) you get an offset of 63 and errors like: partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition f: partition extends past end of unit So why does disklabel/bsdlabel produce errors when run on the partition even when the disk is fine, if it is meant to be run on partitions and not slices? Trying to learn... thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
--- Jerry McAllister [EMAIL PROTECTED] wrote: (is disklabel/bsdlabel only meant to be run on slices and not bsd-partitions?). You have it backwards in this question. Disklabel is meant to run only on bsd partitions and not slices. Slices (1-4) are the major divisions of the disk and partitions (a-h) are divisions within slices. Fdisk is what creates slices. First, as I look at what I wrote, I said this wrong in two ways - because I didn't read carefully and had just come off a bad headache, probably caused by breathing spray paint fumes - always use in well ventilated area. The biggie!! disklabel DOES work on slices and CREATES partitions. It does not work on partitions - it creates them which is where my sleepy [Groggy has already been claimed by a famous contributer] got lost. So, trying to run disklabel on ad0s1c would definitely cause an error. The other thing is, I should have left out the word 'only' (after writing the rest of it correctly, of course) because disklabel can, but usually shouldn't, be run on the whole disk ad0 (as apposed to just a slice ad0s1) which will create a dangerously dedicated disk. There is no real danger as long as you only use FreeBSD on it and don't want to multi-boot it or anything. Since you only lose the tiny bit by slicing it (63 sectors), you should just always first slice it (with fdisk) - even if that means making it all one big slice. That will make sure things are happy should you get weird creative ideas later on. Ok, well the reason I thought it might be the other way is because if you run disklabel (bsdlabel) on a slice (such as /dev/ad4s1 on my machine, which is working, or /dev/ad0s1 on another machine I have access to) it works fine (and reports an offset of 0), but if you run it on the partition (/dev/ad0s1c) you get an offset of 63 and errors like: Yes, the offset in disklabel is from the beginning of the slice. I am not sure what it is trying to do if you try to further partition a partition. Anyway, the 'c' partition is a special one that refers to the whole slice regardless of the partitions it has been carved in to. I would have to go wading through code to figure out how it is handled differently. Just for fun, try doing a disklabel on ad0s1a or something like that and see what it does - on a disk you can afford to trash. Anyway, sorry for the first round of mis-statement. jerry partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition f: partition extends past end of unit So why does disklabel/bsdlabel produce errors when run on the partition even when the disk is fine, if it is meant to be run on partitions and not slices? Trying to learn... thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Wed, 7 Jan 2004 06:09, Scott I. Remick wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I think you already have a copy (the data at offset 32 seems to be it). If you want, do a # dd if=/dev/ad6s1 skip=16 count=16 of=/some/file ok, done. Is there a way to use fsck_ufs -b now to fix this? Or is that premature? And if I remember correctly, that doesn't actually APPLY the alternate superblock... it just allows fsck to run while utilizing an alternate one. So we need to use some sort of dd command to copy it to the proper location, correct? Please tell me everything what you tried to use to mount/fsck the drive (and the results, of course). Well, my memory is sketchy so I don't know how much use it'd be. But I was saving a file to /data (ad6) when the system hung. Then it rebooted on its own. Of course fsck ran on bootup but it gave up and told me I had to run it manually. When I did (I don't remember any parameters I specifically used, if any) I got: /dev/ad6s1c Cannot find file system superblock /dev/ad6s1c: NOT LABELED AS A BSD FILE SYSTEM This is true. That partition is labeled as unused. I believe you should be trying to mount /dev/ad6s1e. I remember there being some of the other common message for little things that you just tell it to go ahead and fix. But the above error was a brick wall and would keep me from going multi-user. Ultimately I had to comment-out the line in fstab: #/dev/ad6s1c/data ufs rw 2 2 Certainly wrong in 4.x, I suspect also wrong in 5.x. Do you have a line mounting ad4s1c for the other disk? So I could at least boot. And that's the way I've been ever since. Trying to mount it now gives: su-2.05b# mount -r /dev/ad6s1c /data mount: /dev/ad6s1c on /data: incorrect super block And so we stand. Malcolm Kay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
--- Malcolm Kay [EMAIL PROTECTED] wrote: This is true. That partition is labeled as unused. I believe you should be trying to mount /dev/ad6s1e. su-2.05b# mount -r /dev/ad6s1e /data mount: /dev/ad6s1e on /data: incorrect super block #/dev/ad6s1c/data ufs rw 2 2 Certainly wrong in 4.x, I suspect also wrong in 5.x. Yikes, well that's the way it had been for about a year. How come it worked? I must have made an inexperienced mistake early on, but it WAS working. Can this be fixed? Do you have a line mounting ad4s1c for the other disk? No, that's the only one using the c partition. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 15:17:29 -0500 (EST) Jerry McAllister [EMAIL PROTECTED] probably wrote: --- Jerry McAllister [EMAIL PROTECTED] wrote: (is disklabel/bsdlabel only meant to be run on slices and not bsd-partitions?). You have it backwards in this question. Disklabel is meant to run only on bsd partitions and not slices. Slices (1-4) are the major divisions of the disk and partitions (a-h) are divisions within slices. Fdisk is what creates slices. First, as I look at what I wrote, I said this wrong in two ways - because I didn't read carefully and had just come off a bad headache, probably caused by breathing spray paint fumes - always use in well ventilated area. The biggie!! disklabel DOES work on slices and CREATES partitions. It does not work on partitions - it creates them which is where my sleepy [Groggy has already been claimed by a famous contributer] got lost. So, trying to run disklabel on ad0s1c would definitely cause an error. The other thing is, I should have left out the word 'only' (after writing the rest of it correctly, of course) because disklabel can, but usually shouldn't, be run on the whole disk ad0 (as apposed to just a slice ad0s1) which will create a dangerously dedicated disk. There is no real danger as long as you only use FreeBSD on it and don't want to multi-boot it or anything. Since you only lose the tiny bit by slicing it (63 sectors), you should just always first slice it (with fdisk) - even if that means making it all one big slice. That will make sure things are happy should you get weird creative ideas later on. Ok, well the reason I thought it might be the other way is because if you run disklabel (bsdlabel) on a slice (such as /dev/ad4s1 on my machine, which is working, or /dev/ad0s1 on another machine I have access to) it works fine (and reports an offset of 0), but if you run it on the partition (/dev/ad0s1c) you get an offset of 63 and errors like: Yes, the offset in disklabel is from the beginning of the slice. I am not sure what it is trying to do if you try to further partition a partition. Anyway, the 'c' partition is a special one that refers to the whole slice regardless of the partitions it has been carved in to. As for now, I have the impression that it's so in 4.x, but in 5.x it's some kind kind of special. If in 4.x the adXsY and adXsYc nodes were identical, it just isn't so in 5.x, and `bsdlabel' shows offsets from beginning of th *physical disk*, not the slice (why?). I would have to go wading through code to figure out how it is handled differently. Just for fun, try doing a disklabel on ad0s1a or something like that and see what it does - on a disk you can afford to trash. Anyway, sorry for the first round of mis-statement. jerry partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition f: partition extends past end of unit So why does disklabel/bsdlabel produce errors when run on the partition even when the disk is fine, if it is meant to be run on partitions and not slices? Trying to learn... thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- DoubleF He was a modest, good-humored boy. It was Oxford that made him insufferable. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 11:39:57 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I think you already have a copy (the data at offset 32 seems to be it). If you want, do a # dd if=/dev/ad6s1 skip=16 count=16 of=/some/file ok, done. Is there a way to use fsck_ufs -b now to fix this? Or is that premature? And if I remember correctly, that doesn't actually APPLY the alternate superblock... it just allows fsck to run while utilizing an alternate one. So we need to use some sort of dd command to copy it to the proper location, correct? Please tell me everything what you tried to use to mount/fsck the drive (and the results, of course). Well, my memory is sketchy so I don't know how much use it'd be. But I was saving a file to /data (ad6) when the system hung. Then it rebooted on its own. Of course fsck ran on bootup but it gave up and told me I had to run it manually. When I did (I don't remember any parameters I specifically used, if any) I got: /dev/ad6s1c Cannot find file system superblock /dev/ad6s1c: NOT LABELED AS A BSD FILE SYSTEM I remember there being some of the other common message for little things that you just tell it to go ahead and fix. But the above error was a brick wall and would keep me from going multi-user. Ultimately I had to comment-out the line in fstab: #/dev/ad6s1c/data ufs rw 2 2 So I could at least boot. And that's the way I've been ever since. Trying to mount it now gives: su-2.05b# mount -r /dev/ad6s1c /data mount: /dev/ad6s1c on /data: incorrect super block And so we stand. Try booting from a 4.x floppy and doing it all over again... The FS is UFS1, isn't it? Ummm... doing what all over again? I mean trying to mount it, to fsck it, using dd|hd to find the superblock, etc. I just want to be *really* sure we know what we are doing. While we are on that, do you have an empty disk to copy this disk's contents to? I'm not sure, but maybe I have an idea... Wipe the disk and redo the partitions? I hope we're not quite there yet. How does using 4.x give me an advantage over 5.1? I'm not clear on that part. Simplicity. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- DoubleF Lackland's Laws: (1) Never be first. (2) Never be last. (3) Never volunteer for anything pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
Sorry for the delay... holidays had me busy. Hopefully you're still around and interested in picking up where we left off. I think we're definitely onto something... --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: su-2.05b# hd /dev/ad6s1 | grep 54 19 01 00 1620 54 19 01 00 74 10 68 81 23 00 00 e8 d5 03 00 00 |T...t.h.#...| These: 2550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 |T...| 4550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 |T...| 002e6550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 DON'T look like false positives. They're just what you were supposed to get. Let's have a look at # dd if=/dev/ad6s1 skip=16 |hd su-2.05b# dd if=/dev/ad6s1 skip=16 |hd 00 04 00 04 00 04 00 04 08 04 00 04 10 04 00 04 || 0010 18 04 00 04 98 05 00 00 00 00 00 00 ff ff ff ff || 0020 9e 8d cd 3f 31 6c 54 06 d5 15 4b 06 ad 05 00 04 |...?1lT...K.| 0030 00 44 00 04 00 0c 00 04 08 04 00 04 08 04 00 04 |.D..| 0040 00 04 00 04 3c 04 00 00 00 c0 ff ff 00 fc ff ff |...| 0050 0e 04 00 04 0b 04 00 00 07 00 00 00 00 10 00 00 || 0060 03 00 00 00 02 00 00 00 00 08 00 00 00 fc ff ff || 0070 0a 04 00 04 00 14 00 04 80 04 00 04 04 04 00 04 || 0080 00 04 00 04 00 14 00 04 01 04 00 04 00 04 00 04 || 0090 00 ec 01 3f f2 6d 8d 6c 98 05 00 00 00 20 00 00 |...?.m.l. ..| 00a0 00 40 00 00 01 00 00 00 00 10 00 00 00 10 00 00 |[EMAIL PROTECTED]| 00b0 1b 95 00 04 59 04 00 04 00 5c 00 04 00 64 01 04 |Y\...d..| 00c0 34 0c 00 00 1e 25 31 04 b9 8c 92 04 1b 1f 00 04 |4%1.| 00d0 00 04 00 86 2f 64 61 74 61 04 00 04 00 04 00 04 |/data...| 00e0 00 04 00 04 00 04 00 04 00 04 00 04 00 04 00 04 || # dd if=/dev/ad6s1 skip=32 |hd su-2.05b# dd if=/dev/ad6s1 skip=32 |hd 00 00 00 00 00 00 00 00 08 00 00 00 10 00 00 00 || 0010 18 00 00 00 98 05 00 00 00 04 00 00 ff ff ff ff || 0020 00 ec 01 3f 31 68 54 02 d5 15 4b 02 ad 01 00 00 |...?1hT...K.| 0030 00 40 00 00 00 08 00 00 08 00 00 00 08 00 00 00 |[EMAIL PROTECTED]| 0040 00 00 00 00 3c 00 00 00 00 c0 ff ff 00 f8 ff ff |...| 0050 0e 00 00 00 0b 00 00 00 07 00 00 00 00 10 00 00 || 0060 03 00 00 00 02 00 00 00 00 08 00 00 00 fc ff ff || 0070 0a 00 00 00 00 10 00 00 80 00 00 00 04 00 00 00 || 0080 00 00 00 00 00 10 00 00 01 00 00 00 00 00 00 00 || 0090 00 ec 01 3f f2 6d 8d 6c 98 05 00 00 00 20 00 00 |...?.m.l. ..| 00a0 00 40 00 00 01 00 00 00 00 10 00 00 00 10 00 00 |[EMAIL PROTECTED]| 00b0 1b 95 00 00 59 00 00 00 00 58 00 00 00 64 01 00 |YX...d..| 00c0 01 00 00 00 b9 62 49 00 fd 77 93 00 0c 00 00 00 |.bI..w..| 00d0 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || I see /data in that first one, so I'm getting hopeful ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 10:59, Scott I. Remick wrote: Sorry for the delay... holidays had me busy. Hopefully you're still around and interested in picking up where we left off. I think we're definitely onto something... Looking back over some of your e-mails I find: QUOTE su-2.05b# disklabel -r /dev/ad6s1c # /dev/ad6s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 156344517 63unused0 0 # raw part, don't edit e: 156344517 634.2BSD 2048 1638489 partition c: partition extends past end of unit disklabel: partition c doesn't start at 0! disklabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit That doesn't look good. ENDQUOTE The 63 offset is spurious. I've seen this before somewhere but can't remember the details -- i.e the value 63. I wonder whether editing the label and setting both offsets to 0 might solve the problem. You could always make a copy of the existing label and put it back if the changes don't help. You could in addition check the size for the partitions against the size given by fdisk for the slice. Malcolm Kay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Tue, 6 Jan 2004 13:29:26 +1030 Malcolm Kay [EMAIL PROTECTED] probably wrote: On Tue, 6 Jan 2004 10:59, Scott I. Remick wrote: Sorry for the delay... holidays had me busy. Me too:) Hopefully you're still around and interested in picking up where we left off. I think we're definitely onto something... Looking back over some of your e-mails I find: QUOTE su-2.05b# disklabel -r /dev/ad6s1c # /dev/ad6s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 156344517 63unused0 0 # raw part, don't edit e: 156344517 634.2BSD 2048 1638489 partition c: partition extends past end of unit disklabel: partition c doesn't start at 0! disklabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit That doesn't look good. ENDQUOTE The 63 offset is spurious. I've seen this before somewhere but can't remember the details -- i.e the value 63. I know where you've seen this. The normal offset for the first *slice* is 63 sectors, for some historical reasons (those extra sectors were to be used for bad block replacement or something like that). Not sure how the 63 made it into the disklabel, though. I wonder whether editing the label and setting both offsets to 0 might solve the problem. It definitely seems like that, as the actual offset of the partition is 0, as dd shows. You could always make a copy of the existing label and put it back if the changes don't help. You could in addition check the size for the partitions against the size given by fdisk for the slice. Malcolm Kay ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- DoubleF Never settle with words what you can accomplish with a flame thrower. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I wonder whether editing the label and setting both offsets to 0 might solve the problem. It definitely seems like that, as the actual offset of the partition is 0, as dd shows. Ok, sounds like a plan. Not that I know what I'm doing. Should I use something like the following command to save my current disklabel? bsdlabel /dev/ad6s1c disklabel.ad6s1c.backup Then do I just edit a copy of that textfile, change the offsets to 0, then write it back like this? bsdlabel -R /dev/ad6s1c dislabel.ad6s1c.new And lastly... your talk about offsets. The man page for bsdlabel describes using it on the whole disk (ad6) and not a slice or partition. If I run it on ad6, I get: bsdlabel: /dev/ad6: no valid label found If I run it on the slice ad6s1 I get: # /dev/ad6s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 1563445170unused0 0 # raw part, don't edit e: 15634451704.2BSD 2048 1638489 And there I see the offset of 0 you might be talking about...? Are we looking at the proper label? Just want to make sure before I mess things up. Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Mon, 8 Dec 2003 21:52:54 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I wonder what did destroy it. Of course, system crashes can do wonders, but... Well, I was trying to save a file to that drive when my system spontaneously rebooted for no apparent reason. In fact, there should be a way, because a valid superblock copy has a correct checksum. Perhaps I'll hack up a program to do that taking information from the /usr/src/sys/ufs/... There's also a magic number for a superblock, mentioned in fs.h (in 4.8 it's 0x011954). I see: #define FS_UFS1_MAGIC 0x011954/* UFS1 fast filesystem magic number */ #define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic number */ And I remember this drive was UFS2, because I was wondering if I should be concerned that this drive was UFS2 and the system drive was UFS1 (/, /var, /usr). However, the following command turns up no results after several mins: su-2.05b# hd /dev/ad6s1 | grep 19 01 54 19 Yet this won't work unless the bytes all line up on the same line. If they're split across lines in the hd output, there'll be no match. True, but thanks to the position of the magic number in the superblock (I don't think it changed in 5.x) , it never crosses a line boundary. Even though your command is for UFS1, I get several matches, but they must be false-positives as I know I used UFS2: su-2.05b# hd /dev/ad6s1 | grep 54 19 01 00 1620 54 19 01 00 74 10 68 81 23 00 00 e8 d5 03 00 00 |T...t.h.#...| These: 2550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 |T...| 4550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 |T...| 002e6550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 DON'T look like false positives. They're just what you were supposed to get. Let's have a look at # dd if=/dev/ad6s1 skip=16 |hd # dd if=/dev/ad6s1 skip=32 |hd |T...| 00548740 51 19 01 00 52 19 01 00 53 19 01 00 54 19 01 00 |Q...R...S...T...| 00549740 51 19 01 00 52 19 01 00 53 19 01 00 54 19 01 00 |Q...R...S...T...| These definitely are false positives. Unless somehow I am confused...? My verdict would be that it's indeed UFS1, whatever you think about it. Any other ideas for finding an intact superblock off this drive and repairing it? Anyone? = Scott I. Remick --==-- ICQ: 450152 Save the internet - Use a Mozilla-based browser: http://vtbsd.net/mozilla/ FreeBSD: Because making unix user-friendly is easier than debugging Windows. http://vtbsd.net/freebsd/ Voici mon secret. Il est tres simple: on ne voit bien qu'avec le coeur. L'essentiel est invisible pour les yeux. Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- DoubleF That boy's about as sharp as a pound of wet liver -- Foghorn Leghorn pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I wonder what did destroy it. Of course, system crashes can do wonders, but... Well, I was trying to save a file to that drive when my system spontaneously rebooted for no apparent reason. In fact, there should be a way, because a valid superblock copy has a correct checksum. Perhaps I'll hack up a program to do that taking information from the /usr/src/sys/ufs/... There's also a magic number for a superblock, mentioned in fs.h (in 4.8 it's 0x011954). I see: #define FS_UFS1_MAGIC 0x011954/* UFS1 fast filesystem magic number */ #define FS_UFS2_MAGIC 0x19540119 /* UFS2 fast filesystem magic number */ And I remember this drive was UFS2, because I was wondering if I should be concerned that this drive was UFS2 and the system drive was UFS1 (/, /var, /usr). However, the following command turns up no results after several mins: su-2.05b# hd /dev/ad6s1 | grep 19 01 54 19 Yet this won't work unless the bytes all line up on the same line. If they're split across lines in the hd output, there'll be no match. Even though your command is for UFS1, I get several matches, but they must be false-positives as I know I used UFS2: su-2.05b# hd /dev/ad6s1 | grep 54 19 01 00 1620 54 19 01 00 74 10 68 81 23 00 00 e8 d5 03 00 00 |T...t.h.#...| 2550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 |T...| 4550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 |T...| 002e6550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 |T...| 00548740 51 19 01 00 52 19 01 00 53 19 01 00 54 19 01 00 |Q...R...S...T...| 00549740 51 19 01 00 52 19 01 00 53 19 01 00 54 19 01 00 |Q...R...S...T...| Unless somehow I am confused...? Any other ideas for finding an intact superblock off this drive and repairing it? Anyone? = Scott I. Remick --==-- ICQ: 450152 Save the internet - Use a Mozilla-based browser: http://vtbsd.net/mozilla/ FreeBSD: Because making unix user-friendly is easier than debugging Windows. http://vtbsd.net/freebsd/ Voici mon secret. Il est tres simple: on ne voit bien qu'avec le coeur. L'essentiel est invisible pour les yeux. Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Thu, 4 Dec 2003 21:07:20 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I've got a (probably bad) idea. If you say that the partition was mounted as /data, then you could do a # hd /dev/ad6s1 |grep /data It should come up soon (the superblock should be close to the beginning of the drive, right?). This way you can at least figure out where your superblock lies (rounding the address of `/data' to 8K). Considering the above discussion, you can calculate the *correct* address of the `e' partition by subtracting 8K or 64K or 256K. See if it matches the one in the disklabel. Of course, this is all possible only if your superblock isn't screwed enough to NOT contain `/data'. Been running about a minute so far... nada. So I guess your assumption is correct: the 1st superblock is destroyed (as fsck suggested when it barfed). I wonder what did destroy it. Of course, system crashes can do wonders, but... Just a minute. Are you sure that the filesystem was newfs'd with the default parameters? If it were for me to newfs it, I would probably choose larger blockfragment sizes, as I would probably be storing large files. The superblock copy positions depend on the block/frag size. If you specify parameters different from those used for actually newfs'ing it the very first time, newfs -N will give you *incorrect* copy addresses! Well, specifying custom block/frag sizes is a bit out of my customization forte at the moment, and certainly at the time this drive went in. I'm 99% positive I used sysinstall to set it up. I remember some quirks about the sysinstall method, and also deciding that the by-hand method was unnecessarily complicated for my needs. This has taught me that, should I ever choose to do that, that writing down these custom values is CRITICAL. Is there any way to positively identify a superblock location (say, using hd | grep ) using known information? Just a random thought. In fact, there should be a way, because a valid superblock copy has a correct checksum. Perhaps I'll hack up a program to do that taking information from the /usr/src/sys/ufs/... There's also a magic number for a superblock, mentioned in fs.h (in 4.8 it's 0x011954). So, for me, grepping gives $ hd /dev/ad2s2 | grep 54 19 01 00 2550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 |T...| 4550 01 00 00 00 00 00 00 00 00 00 00 00 54 19 01 00 |T...| 001e9150 11 00 07 00 54 19 01 00 a4 b2 3a c0 00 00 00 00 |T...:| 00a97570 8b 48 60 81 b9 5c 05 00 00 54 19 01 00 75 13 8b |H`\...T...u.| 00a98900 05 00 00 54 19 01 00 74 0b 68 54 5f 2d c0 e8 91 |...T...t.hT_-| 00efb150 11 00 07 00 54 19 01 00 a4 b2 3a c0 00 00 00 00 |T...:| 013b3f50 00 54 19 01 00 75 13 8b 51 30 81 fa 00 00 01 00 |.T...u.Q0| 013b52d0 00 00 8b 70 0c 81 be 5c 05 00 00 54 19 01 00 74 |..p.\...T...t| 01705760 8b 48 60 81 b9 5c 05 00 00 54 19 01 00 75 13 8b |H`\...T...u.| 01706af0 05 00 00 54 19 01 00 74 0b 68 34 89 2a c0 e8 91 |...T...t.h4*| 01831f50 00 54 19 01 00 75 13 8b 51 30 81 fa 00 00 01 00 |.T...u.Q0| 018332d0 00 00 8b 70 0c 81 be 5c 05 00 00 54 19 01 00 74 |..p.\...T...t| . . . Only the first two are real --- the superblock and the first copy (I'm on UFS1). The rest are false positives. You might want to try using $ hd /dev/ad2s2 | grep 54 19 01 00 | to filter out most of them. Have fun. If the disk is that screwed, you might also want to try out tct (/usr/ports/sysutils/tct). I'm not sure, but it might be helpful later(?) Although I'm treating this as a learning experience, I also REALLY REALLY don't want to loose all that data. I do appreciate the help you've been giving me. Thanks again. I'm choosing to remain optimistic. I used to salvage lots of data from DOS/Windows partitions (still do) so learning the tricks of the trade in my new OS of choice is important to me. (PS: already pricing out external USB hard drive enclosures for making backups of this drive in the future) A good idea would also be to print out the hd of the superblock contents on a sheet of paper when you find it and put it in a cool dry place:) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- DoubleF New Year's Eve is the time of year when a man most feels his age, and his wife most often reminds him to act it. -- Webster's Unafraid Dictionary pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
On Thu, 4 Dec 2003 06:17:40 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: [so you want the list cc'd. good...] Oh yes there are... what's surprising? If you are sure that the problem is with the superblock, pick any you wish. The actual number of superblock copies depends on the disk size and the parameters you give to newfs. [...] It's about THE superblock, not a superblock copy. There can be only one superblock. There may be many copies. But if you dd them to the superblock, that'll be fine. Ahh ok, I've learned something new. Guess I misinterpreted the information I found online. I'm not complaining: this is GOOD news. :) BTW, what's the output of ``disklabel -r /dev/ad6s1c'' ? su-2.05b# disklabel -r /dev/ad6s1c # /dev/ad6s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 156344517 63unused0 0 # raw part, don't edit e: 156344517 634.2BSD 2048 1638489 partition c: partition extends past end of unit disklabel: partition c doesn't start at 0! disklabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit That doesn't look good. True. By the way, the past posts I've read suggest that even if I use fsck_ffs -b to run fsck with a diff superblock (say, the one at 160) that it doesn't actually fix the master copy, and that I still need to use dd to fix the original. The command I've seen used is: dd if=/dev/ad6s1c skip=32 of=/dev/ad6s1c seek=16 bs=512 count=16 In fact, when you mess with superblocks, it's messing with filesystems (thus it's different from messing with disklabels). So I guess you should use /dev/ad6s1e here. `e' should be the partition, and `c' --- the whole disk. 1) Do I just replace the 32 of skip=32 with 160 (or whichever superblock makes fsck_ffs -b happy)? Probably yes. The thing is you want to copy some 8192 bytes from one location to another. But I never had a chance to treat a superblock that way... Go ask a person who did! 2) I've also read that the size and location of the original superblock can vary. Do I have to modify the seek/bs/count values to account for this? And Yes. skip here is the location of the copy, seek is the location of the superblock (see below for values). if so, how do I find the proper values? Nothing done yet... don't wanna screw this up. Thanks everyone! If you want to be more sure, try dd'ing your (suspectedly damaged) superblock and some of its (suspectedly OK) copies into different files: # dd if=/dev/ad6s1e skip=... bs=512 count=16 of=somefile As /usr/src/sys/ufs/ffs/fs.h suggests, for THE superblock skip should be 16 if you have UFS1 or 128 or 512 if you have UFS2 (if my maths is correct). These commands shouldn't do anything harmful to /dev/ad6s1e. Of course, after that, you could hack up a program which will read superblocks and display them according to their structure defined as `struct fs' in /usr/src/sys/ufs/ffs/fs.h. Let's not do it today, right? If your superblock copies will appear similar to each other (use cmp(1) or md5(1)), then you can be sure that you've found the copies (so far you haven't done any mistakes in your calculations). Then it's up to you to commit the change. I've just tried it on a test machine. The copies matched. Hmm:) = Scott I. Remick --==-- ICQ: 450152 Save the internet - Use a Mozilla-based browser: http://vtbsd.net/mozilla/ FreeBSD: Because making unix user-friendly is easier than debugging Windows. http://vtbsd.net/freebsd/ Voici mon secret. Il est tres simple: on ne voit bien qu'avec le coeur. L'essentiel est invisible pour les yeux. Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- DoubleF Peter's Law of Substitution: Look after the molehills, and the mountains will look after themselves. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: Oh yes there are... what's surprising? If you are sure that the problem is with the superblock, pick any you wish. The actual number of superblock copies depends on the disk size and the parameters you give to newfs. [...] It's about THE superblock, not a superblock copy. There can be only one superblock. There may be many copies. But if you dd them to the superblock, that'll be fine. Ahh ok, I've learned something new. Guess I misinterpreted the information I found online. I'm not complaining: this is GOOD news. :) BTW, what's the output of ``disklabel -r /dev/ad6s1c'' ? su-2.05b# disklabel -r /dev/ad6s1c # /dev/ad6s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 156344517 63unused0 0 # raw part, don't edit e: 156344517 634.2BSD 2048 1638489 partition c: partition extends past end of unit disklabel: partition c doesn't start at 0! disklabel: An incorrect partition c may cause problems for standard system utilities partition e: partition extends past end of unit That doesn't look good. By the way, the past posts I've read suggest that even if I use fsck_ffs -b to run fsck with a diff superblock (say, the one at 160) that it doesn't actually fix the master copy, and that I still need to use dd to fix the original. The command I've seen used is: dd if=/dev/ad6s1c skip=32 of=/dev/ad6s1c seek=16 bs=512 count=16 1) Do I just replace the 32 of skip=32 with 160 (or whichever superblock makes fsck_ffs -b happy)? 2) I've also read that the size and location of the original superblock can vary. Do I have to modify the seek/bs/count values to account for this? And if so, how do I find the proper values? Nothing done yet... don't wanna screw this up. Thanks everyone! = Scott I. Remick --==-- ICQ: 450152 Save the internet - Use a Mozilla-based browser: http://vtbsd.net/mozilla/ FreeBSD: Because making unix user-friendly is easier than debugging Windows. http://vtbsd.net/freebsd/ Voici mon secret. Il est tres simple: on ne voit bien qu'avec le coeur. L'essentiel est invisible pour les yeux. Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: If you want to be more sure, try dd'ing your (suspectedly damaged) superblock and some of its (suspectedly OK) copies into different files: # dd if=/dev/ad6s1e skip=... bs=512 count=16 of=somefile As /usr/src/sys/ufs/ffs/fs.h suggests, for THE superblock skip should be 16 if you have UFS1 or 128 or 512 if you have UFS2 (if my maths is correct). These commands shouldn't do anything harmful to /dev/ad6s1e. Either I'm doing something wrong, or things aren't good. Given: su-2.05b# newfs -N /dev/ad6s1e /dev/ad6s1e: 76340.1MB (156344516 sectors) block size 16384, fragment size 2048 using 416 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, ... 152046368, 152422720, 152799072, 153175424, 153551776, 153928128, 154304480, 154680832, 155057184, 155433536, 155809888, 156186240 I take 6 superblock copies (3 from beginning, 3 from end): su-2.05b# dd if=/dev/ad6s1e skip=160 bs=512 count=16 of=sb1 16+0 records in 16+0 records out 8192 bytes transferred in 0.026774 secs (305969 bytes/sec) su-2.05b# dd if=/dev/ad6s1e skip=376512 bs=512 count=16 of=sb2 16+0 records in 16+0 records out 8192 bytes transferred in 0.008415 secs (973502 bytes/sec) su-2.05b# dd if=/dev/ad6s1e skip=752864 bs=512 count=16 of=sb3 16+0 records in 16+0 records out 8192 bytes transferred in 0.006808 secs (1203283 bytes/sec) su-2.05b# dd if=/dev/ad6s1e skip=155433536 bs=512 count=16 of=sb4 16+0 records in 16+0 records out 8192 bytes transferred in 0.023173 secs (353513 bytes/sec) su-2.05b# dd if=/dev/ad6s1e skip=155809888 bs=512 count=16 of=sb5 16+0 records in 16+0 records out 8192 bytes transferred in 0.011078 secs (739484 bytes/sec) su-2.05b# dd if=/dev/ad6s1e skip=156186240 bs=512 count=16 of=sb6 16+0 records in 16+0 records out 8192 bytes transferred in 0.010837 secs (755932 bytes/sec) None of these are the same: su-2.05b# cmp sb1 sb2 sb1 sb2 differ: char 1, line 1 su-2.05b# cmp sb1 sb3 sb1 sb3 differ: char 1, line 1 su-2.05b# cmp sb2 sb3 sb2 sb3 differ: char 1, line 1 I don't include sb4-6 here because they're all null: su-2.05b# hexdump -C sb4 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 2000 su-2.05b# hexdump -C sb5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 2000 su-2.05b# hexdump -C sb6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 2000 I am suspecting there is something wrong in my syntax for fetching the superblocks. I see that the SB size is always 8192 bytes regardless so it should be 512*16 as in the dd command. And I checked that the #s output by newfs -N were block positions and not raw byte permissions. However newfs -N is saying that it is reporting the positions using a blocksize of 16384. In which case, 160 would mean 160 * 16384 = 2621440 (byte pos). To translate to the 512-byte blocks, this means the skip should be 5120 (and 12048384 and 24091648 respectively for the 2nd 3rd sb positions). However, when I grab 8192-byte chunks using these skip settings w/ dd, they don't match up either. I was hoping I was onto something. :( Yet you say using the same # output by newfs -N as the skip for dd worked for you... hmm. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Thu, 4 Dec 2003 08:24:16 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: If you want to be more sure, try dd'ing your (suspectedly damaged) superblock and some of its (suspectedly OK) copies into different files: # dd if=/dev/ad6s1e skip=... bs=512 count=16 of=somefile As /usr/src/sys/ufs/ffs/fs.h suggests, for THE superblock skip should be 16 if you have UFS1 or 128 or 512 if you have UFS2 (if my maths is correct). These commands shouldn't do anything harmful to /dev/ad6s1e. [snip] I am suspecting there is something wrong in my syntax for fetching the superblocks. I see that the SB size is always 8192 bytes regardless so it should be 512*16 as in the dd command. And I checked that the #s output by newfs -N were block positions and not raw byte permissions. However newfs -N is saying that it is reporting the positions using a blocksize of 16384. In which case, 160 would mean 160 * 16384 = 2621440 (byte pos). To translate to the 512-byte blocks, this means the skip should be 5120 (and 12048384 and 24091648 respectively for the 2nd 3rd sb positions). However, when I grab 8192-byte chunks using these skip settings w/ dd, they don't match up either. I was hoping I was onto something. :( Unless I am very much mistaken, the positions reported by newfs should always be multiplied by the sector size (512), not by the block size. So what you were doing is ok... Yet you say using the same # output by newfs -N as the skip for dd worked for you... hmm. This suggests that something else (looking suspiciously at the disklabel) is screwed, not the superblocks... I think we'll end up digging through the hex dump of the beginning of the drive. I've got a (probably bad) idea. If you say that the partition was mounted as /data, then you could do a # hd /dev/ad6s1 |grep /data It should come up soon (the superblock should be close to the beginning of the drive, right?). This way you can at least figure out where your superblock lies (rounding the address of `/data' to 8K). Considering the above discussion, you can calculate the *correct* address of the `e' partition by subtracting 8K or 64K or 256K. See if it matches the one in the disklabel. Of course, this is all possible only if your superblock isn't screwed enough to NOT contain `/data'. This won't find you the copies of the superblock, BTW, as they are not modified my a mount. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- DoubleF Non-Reciprocal Laws of Expectations: Negative expectations yield negative results. Positive expectations yield negative results. pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
On Thu, 4 Dec 2003 08:24:16 -0800 (PST) Scott I. Remick [EMAIL PROTECTED] probably wrote: --- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: If you want to be more sure, try dd'ing your (suspectedly damaged) superblock and some of its (suspectedly OK) copies into different files: # dd if=/dev/ad6s1e skip=... bs=512 count=16 of=somefile As /usr/src/sys/ufs/ffs/fs.h suggests, for THE superblock skip should be 16 if you have UFS1 or 128 or 512 if you have UFS2 (if my maths is correct). These commands shouldn't do anything harmful to /dev/ad6s1e. Either I'm doing something wrong, or things aren't good. Given: su-2.05b# newfs -N /dev/ad6s1e Just a minute. Are you sure that the filesystem was newfs'd with the default parameters? If it were for me to newfs it, I would probably choose larger blockfragment sizes, as I would probably be storing large files. The superblock copy positions depend on the block/frag size. If you specify parameters different from those used for actually newfs'ing it the very first time, newfs -N will give you *incorrect* copy addresses! /dev/ad6s1e: 76340.1MB (156344516 sectors) block size 16384, fragment size 2048 using 416 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, ... 152046368, 152422720, 152799072, 153175424, 153551776, 153928128, 154304480, 154680832, 155057184, 155433536, 155809888, 156186240 -- DoubleF The computing field is always in need of new cliches. -- Alan Perlis pgp0.pgp Description: PGP signature
Re: Cannot find file system superblock error - how to recover?
--- Sergey 'DoubleF' Zaharchenko [EMAIL PROTECTED] wrote: I've got a (probably bad) idea. If you say that the partition was mounted as /data, then you could do a # hd /dev/ad6s1 |grep /data It should come up soon (the superblock should be close to the beginning of the drive, right?). This way you can at least figure out where your superblock lies (rounding the address of `/data' to 8K). Considering the above discussion, you can calculate the *correct* address of the `e' partition by subtracting 8K or 64K or 256K. See if it matches the one in the disklabel. Of course, this is all possible only if your superblock isn't screwed enough to NOT contain `/data'. Been running about a minute so far... nada. So I guess your assumption is correct: the 1st superblock is destroyed (as fsck suggested when it barfed). Just a minute. Are you sure that the filesystem was newfs'd with the default parameters? If it were for me to newfs it, I would probably choose larger blockfragment sizes, as I would probably be storing large files. The superblock copy positions depend on the block/frag size. If you specify parameters different from those used for actually newfs'ing it the very first time, newfs -N will give you *incorrect* copy addresses! Well, specifying custom block/frag sizes is a bit out of my customization forte at the moment, and certainly at the time this drive went in. I'm 99% positive I used sysinstall to set it up. I remember some quirks about the sysinstall method, and also deciding that the by-hand method was unnecessarily complicated for my needs. This has taught me that, should I ever choose to do that, that writing down these custom values is CRITICAL. Is there any way to positively identify a superblock location (say, using hd | grep ) using known information? Just a random thought. Although I'm treating this as a learning experience, I also REALLY REALLY don't want to loose all that data. I do appreciate the help you've been giving me. Thanks again. I'm choosing to remain optimistic. I used to salvage lots of data from DOS/Windows partitions (still do) so learning the tricks of the trade in my new OS of choice is important to me. (PS: already pricing out external USB hard drive enclosures for making backups of this drive in the future) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Cannot find file system superblock error - how to recover?
Running 5.1-REL on a system w/ 2 drives. Was saving a file to 2nd drive (mounts as /data) and system suddenly froze then rebooted. Never good. Fsck barfed on startup telling me I had to run it manually. The error I'm stuck with is: /dev/ad6s1c Cannot find file system superblock /dev/ad6s1c: NOT LABELED AS A BSD FILE SYSTEM Searching on this error hasn't been very productive. Some people talk about a LOOK FOR ALTERNATE SUPERBLOCKS? question that I'm not getting when I run fsck. There's also mention of an undocumented -b option to fsck for fixing this. Then there's some scary manual method using dd: dd if=/dev/ad6s1c skip=32 of=/dev/ad6s1c seek=16 bs=512 count=16 But before I do that I definitely want confirmation. Please tell me there's hope for this drive...this Windows PC makes me feel dirty. Thanks in advance. :) = Scott I. Remick --==-- ICQ: 450152 Save the internet - Use a Mozilla-based browser: http://vtbsd.net/mozilla/ FreeBSD: Because making unix user-friendly is easier than debugging Windows. http://vtbsd.net/freebsd/ Voici mon secret. Il est tres simple: on ne voit bien qu'avec le coeur. L'essentiel est invisible pour les yeux. Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
On Wed, 3 Dec 2003 00:06:12 -0800 (PST)
Scott I. Remick [EMAIL PROTECTED] wrote:
Running 5.1-REL on a system w/ 2 drives. Was saving a file to 2nd drive
(mounts as /data) and system suddenly froze then rebooted. Never good. Fsck
barfed on startup telling me I had to run it manually. The error I'm stuck
with is:
/dev/ad6s1c
Cannot find file system superblock
/dev/ad6s1c: NOT LABELED AS A BSD FILE SYSTEM
Searching on this error hasn't been very productive. Some people talk about
a LOOK FOR ALTERNATE SUPERBLOCKS? question that I'm not getting when I run
fsck. There's also mention of an undocumented -b option to fsck for fixing
this.
FSCK_FFS(8) FreeBSD System Manager's ManualFSCK_FFS(8)
NAME
fsck_ffs, fsck_ufs -- file system consistency check and interactive
repair
SYNOPSIS
fsck_ffs [-BFpfny] [-b block#] [-c level] [-m mode] filesystem ...
-b Use the block specified immediately after the flag as the super
block for the file system. Block 32 is usually an alternate
super block.
The key world is usually.
Then there's some scary manual method using dd:
dd if=/dev/ad6s1c skip=32 of=/dev/ad6s1c seek=16 bs=512 count=16
Try doing a newfs -N and see if using some of the alternatives
super-blocks in fsck_ufs will help. Note that the alternate superblock
is no longer always at 32, it depends on the size of the file system.
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/ufs/ffs/fs.h?rev=1.39content-type=text/x-cvsweb-markup
* Depending on the architecture and the media, the superblock may
* reside in any one of four places. For tiny media where every block
* counts, it is placed at the very front of the partition. Historically,
* UFS1 placed it 8K from the front to leave room for the disk label and
* a small bootstrap. For UFS2 it got moved to 64K from the front to leave
* room for the disk label and a bigger bootstrap, and for really piggy
* systems we check at 256K from the front if the first three fail. In
* all cases the size of the superblock will be SBLOCKSIZE. All values are
* given in byte-offset form, so they do not imply a sector size. The
* SBLOCKSEARCH specifies the order in which the locations should be searched.
*/
#define SBLOCK_FLOPPY 0
#define SBLOCK_UFS1 8192
#define SBLOCK_UFS2 65536
#define SBLOCK_PIGGY262144
#define SBLOCKSIZE 8192
#define SBLOCKSEARCH \
{ SBLOCK_UFS2, SBLOCK_UFS1, SBLOCK_FLOPPY, SBLOCK_PIGGY, -1 }
--
IOnut
Unregistered ;) FreeBSD user
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot find file system superblock error - how to recover?
--- Ion-Mihai Tetcu [EMAIL PROTECTED] wrote: FSCK_FFS(8) NAME fsck_ffs, fsck_ufs -- file system consistency check and interactive repair SYNOPSIS fsck_ffs [-BFpfny] [-b block#] [-c level] [-m mode] filesystem ... -b Use the block specified immediately after the flag as the super block for the file system. Block 32 is usually an alternate super block. Ah, somehow never knew about fsck_ffs. Now I do :-) Does it matter that /dev/ad6s1c is UFS2 and not UFS1? Try doing a newfs -N and see if using some of the alternatives super-blocks in fsck_ufs will help. Note that the alternate superblock is no longer always at 32, it depends on the size of the file system. Whoa, something doesn't seem right. I do: su-2.05b# newfs -N /dev/ad6s1c /dev/ad6s1c: 76340.1MB (156344516 sectors) block size 16384, fragment size 2048 using 416 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664, 10538016, 10914368, 11290720, 11667072, 12043424, 12419776, 12796128, 13172480, 13548832, 13925184, 14301536, 14677888, 15054240, 15430592, 15806944, 16183296, 16559648, 16936000, 17312352, 17688704, 18065056, 18441408, 18817760, 19194112, 19570464, 19946816, 20323168, 20699520, 21075872, 21452224, 21828576, 22204928, 22581280, 22957632, 2984, 23710336, 24086688, 24463040, 24839392, 25215744, 25592096, 25968448, 26344800, 26721152, 27097504, 27473856, 27850208, And this actually continues for quite a bit. There aren't really that many copies of the superblock on the drive, right? * Depending on the architecture and the media, the superblock may * reside in any one of four places. Yeah, a lot more than four... Haven't tried anything yet. Awaiting expert advice first... Thanks! = Scott I. Remick --==-- ICQ: 450152 Save the internet - Use a Mozilla-based browser: http://vtbsd.net/mozilla/ FreeBSD: Because making unix user-friendly is easier than debugging Windows. http://vtbsd.net/freebsd/ Voici mon secret. Il est tres simple: on ne voit bien qu'avec le coeur. L'essentiel est invisible pour les yeux. Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
