Re: input/output error on hd - resolved
As a follow up to the previous thread on which I was the OP have followed the advice given, contacted Ian Dowse who kindly walked me through fixing my hard drive. Here is a synopsis as best as I can do to explain what was done: First find out the offsets of the bad sectors, and check with dd that you can't read them Then write zeros over that sector dd if=/dev/zero seek=12345 count=1 of=/dev/ad1 and recheck that the original failing dd now works. After fixing all the bad sectors that way, you'll probably have much more luck with standard tools such as fsck. %sudo fsck /dev/ad1s1a ** /dev/ad1s1a Cannot find file system superblock /dev/ad1s1a: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 490223412 Try editing the disklabel with `disklabel -e ad1s1', and changing the line to look like: a: 49022341204.2BSD2048 16384 94088 %sudo fsck /dev/ad1s1a ** /dev/ad1s1a Cannot find file system superblock LOOK FOR ALTERNATE SUPERBLOCKS? [yn] y 32 is not a file system superblock 28780512 is not a file system superblock 57560992 is not a file system superblock [snip] 460486688 is not a file system superblock 489267168 is not a file system superblock SEARCH FOR ALTERNATE SUPER-BLOCK FAILED. YOU MUST USE THE -b OPTION TO FSCK TO SPECIFY THE LOCATION OF AN ALTERNATE SUPER-BLOCK TO SUPPLY NEEDED INFORMATION; SEE fsck(8). % looking for superblocks in the right place. What do you get if you run the following - this is a crude way to search for superblocks: dd if=/dev/ad1 bs=32k | hd -v | grep 19 01 54 19 Better still, if you can get a hex dump using dd and hd of a few kb before one of the matching lines, the parameters can be extracted from there. %sudo dd if=/dev/ad1 bs=32k | hd -v | grep 19 01 54 19 Password: 8b10 00 74 27 3d 19 01 54 19 75 31 8b 04 bd 9d 34 00 |.t'=..T.u14.| 8bd0 8b 4d 64 81 bd 5c 05 00 00 19 01 54 19 89 c6 89 |.Md..\.T| 0001c350 00 00 00 00 00 00 00 00 00 00 00 00 19 01 54 19 |..T.| 005ec350 00 00 00 00 00 00 00 00 00 00 00 00 19 01 54 19 |..T.| 0b7e0350 00 00 00 00 00 00 00 00 00 00 00 00 19 01 54 19 |..T.| Looks good - the 3rd and later lines look like superblocks - try: fsck_ffs -b 160 /dev/ad1s1a (160 is calculated by taking 0x0001c350 from the third line above, subtracting 0x550 to get the start of the superblock, and then dividing by 512 to get the sector number, and finally subtracting the partition offset of 63) I'm guessing that fsck was looking for superblocks in the wrong place becasue without a valid superblock it was assuming that the filesystem was UFS1 not UFS2. As far as I can tell, for UFS2 the first standard backup superblock is usually at block 160, whereas for UFS1 it's at block 32. I guess fsck_ffs and/or the man page need to be updated to deal with that. === In end, it worked fine and that HD is back in business. Thanks Ian, and everyone else that helped out on this one. Marty -- Web Installed Formmail - http://face2interface.com/formINSTal/ Webmaster's BBS - http://bbs.face2interface.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
On 2/26/07, Jerry McAllister [EMAIL PROTECTED] wrote: On Mon, Feb 26, 2007 at 04:49:46PM +1100, Ian Smith wrote: Firstly, Marty, you should run dumpfs(8) on your ad1s1a. Well this didn't raise my spirits too much: %sudo dumpfs /dev/ad1s1a dumpfs: /dev/ad1s1a: could not read superblock to fill out disk % So I can get to all but my dead blocks via the DD command and work with it in hex; used to do mainframe assembler programming and don't particularly mind the workout, so to speak. Only with a road map it's not possible. Maybe I should write Ian Dowse and see if he can point me in the right direction (pun intended). Marty :--\ With the -m switch, this produces a single line suitable for feeding into newfs with all parameters, and is probably worth saving for all slices in case of any subsequent emergencies. I've just done that for mine, anyway, along with fdisk and boot0cfg -v output, and bsdlabel output for UFS slices. Yes. Good call. I couldn't think of the dumpfs command the other evening when I was writing, but that is the place to start. Definitely run that output to a file. It will take some learning to understand how to follow it out. There are tables somewhere that tell what each of those things mean and what fields to look in in the raw data to find each thing - and to write it back if that is what you will want to do. Note that it will tell you in the first line if your filesystem if UFS2 or something else. Good luck - maybe if you are successful, you can write a paper on it and post it to a web page somewhere. I probably should have way back when and then I would remember more now. jerry Without the -m switch, feed the output to a file, or less, as it's very voluminous. For a 240GB drive, it'll likely be huge. However the data at the head is probably what's needed, though I can't make much of it. This post by Ian Dowse explains how to compute where the superblocks are, for a quoted example dumpfs: http://noc.caravan.ru/faq/SBLOCK.html Note however that Ian is talking about UFS1 (where the superblock offset was 32) but if you consult fsck_ffs(8) you'll see (under -b) that for UFS2, which you almost certainly would have used, it's at 140 .. I gather that's the offset from the start of each cylinder group? Also assuming my bad sectors really are totally bad, wouldn't fsck allow me to mark them as unusable and move on? No, fsck does not do that. Marking blocks bad happend below the level of the OS - generally in the disk controller itself. It remaps sectors until it runs out of spares and when it runs out, it starts reporting unrecoverable errors. This is not even reported to the OS until it runs out of spares. The only thing you can do with those bad sectors is to try and figure out if any of them are superblocks. If they are, you can probably rebuild it from other superblock clones. If it is not, it is probably lost data. In that case try to overwrite the bad sector. If that works, then the sector itself is OK, but the data that was there is gone. If it doesn't work, then it is bad and there is a good chance that more than data got nuked in the power failure - eg, it damaged the disk or controller in some way. Seeing if fsck_ffs will use any discovered alternate superblocks would be the first step, and if so, whether that helps to get it mounted. I'd certainly be careful to mount it read-only before trying data recovery! Since Marty has already been bravely using dd :) rewriting those sectors should be easy enough, bearing in mind the apparent off-by-one numbering difference between the sectors dd found bad and those fsck reported bad. But, the next thing seems to be learning about how to follow the file chains and how to find and read and write superblocks. Alternatively you can decide it isn't worth the effort to recover and try and write over the drive completely - just totally trash it - and see if those bad sectors will write. If you did that, then you would have to rebuild the slice and partition table and do a newfs before you could again use the drive and everything previously on it would be lost. Well if a dd rewriting those specific contiguous sectors failed, I doubt that newfs would do any better, so the dd is definitely worth a try, but I wouldn't write anything further to the fs until all else has failed. Good luck. I can only echo that, again. Maybe someone who has some experience in tracking file chains can respond and give you more helpp than can I. Ditto for that .. I'm now very thoroughly out of my depth here, though I've learned a few new things through the exercise. Maybe mailing Ian Dowse with circumstances and the dumpfs head might be worth a try, Marty? See the website committers' page for his address. Cheers, Ian -- Web Installed Formmail - http://face2interface.com/formINSTal/
Re: input/output error on hd
On Mon, Feb 26, 2007 at 04:49:46PM +1100, Ian Smith wrote: On Sun, 25 Feb 2007, Jerry McAllister wrote: On Sun, Feb 25, 2007 at 10:38:01AM -0500, Marty Landman wrote: On 2/24/07, Jerry McAllister [EMAIL PROTECTED] wrote: Well, I think you are past any label problems now and on to the bad sectors and/or finding superbocks.Although I am not quite clear from above what resulted in the 'INCOMPLETE LABEL...' message. Ok then, can you point me to somewhere that can learn about superblocks and give me an idea of what to do next? Most of what I figured out several years ago (and have essentially forgotten since) came from the handbook and something I found by searching the web that gave the layout of blocks and chains. I would have to go back searching again. Failing someone who actually knows what they're talking about re UFS structures chipping in to this discussion, all I can offer in addition is what my own exploration of manuals and a bit of googling turned up .. Firstly, Marty, you should run dumpfs(8) on your ad1s1a. With the -m switch, this produces a single line suitable for feeding into newfs with all parameters, and is probably worth saving for all slices in case of any subsequent emergencies. I've just done that for mine, anyway, along with fdisk and boot0cfg -v output, and bsdlabel output for UFS slices. Yes. Good call. I couldn't think of the dumpfs command the other evening when I was writing, but that is the place to start. Definitely run that output to a file. It will take some learning to understand how to follow it out. There are tables somewhere that tell what each of those things mean and what fields to look in in the raw data to find each thing - and to write it back if that is what you will want to do. Note that it will tell you in the first line if your filesystem if UFS2 or something else. Good luck - maybe if you are successful, you can write a paper on it and post it to a web page somewhere. I probably should have way back when and then I would remember more now. jerry Without the -m switch, feed the output to a file, or less, as it's very voluminous. For a 240GB drive, it'll likely be huge. However the data at the head is probably what's needed, though I can't make much of it. This post by Ian Dowse explains how to compute where the superblocks are, for a quoted example dumpfs: http://noc.caravan.ru/faq/SBLOCK.html Note however that Ian is talking about UFS1 (where the superblock offset was 32) but if you consult fsck_ffs(8) you'll see (under -b) that for UFS2, which you almost certainly would have used, it's at 140 .. I gather that's the offset from the start of each cylinder group? Also assuming my bad sectors really are totally bad, wouldn't fsck allow me to mark them as unusable and move on? No, fsck does not do that. Marking blocks bad happend below the level of the OS - generally in the disk controller itself. It remaps sectors until it runs out of spares and when it runs out, it starts reporting unrecoverable errors. This is not even reported to the OS until it runs out of spares. The only thing you can do with those bad sectors is to try and figure out if any of them are superblocks. If they are, you can probably rebuild it from other superblock clones. If it is not, it is probably lost data. In that case try to overwrite the bad sector. If that works, then the sector itself is OK, but the data that was there is gone. If it doesn't work, then it is bad and there is a good chance that more than data got nuked in the power failure - eg, it damaged the disk or controller in some way. Seeing if fsck_ffs will use any discovered alternate superblocks would be the first step, and if so, whether that helps to get it mounted. I'd certainly be careful to mount it read-only before trying data recovery! Since Marty has already been bravely using dd :) rewriting those sectors should be easy enough, bearing in mind the apparent off-by-one numbering difference between the sectors dd found bad and those fsck reported bad. But, the next thing seems to be learning about how to follow the file chains and how to find and read and write superblocks. Alternatively you can decide it isn't worth the effort to recover and try and write over the drive completely - just totally trash it - and see if those bad sectors will write. If you did that, then you would have to rebuild the slice and partition table and do a newfs before you could again use the drive and everything previously on it would be lost. Well if a dd rewriting those specific contiguous sectors failed, I doubt that newfs would do any better, so the dd is definitely worth a try, but I wouldn't write anything further to the fs until all else has failed. Good luck. I can only echo that,
Re: input/output error on hd
On 2/24/07, Jerry McAllister [EMAIL PROTECTED] wrote: Well, I think you are past any label problems now and on to the bad sectors and/or finding superbocks.Although I am not quite clear from above what resulted in the 'INCOMPLETE LABEL...' message. Ok then, can you point me to somewhere that can learn about superblocks and give me an idea of what to do next? Also assuming my bad sectors really are totally bad, wouldn't fsck allow me to mark them as unusable and move on? Marty -- Web Installed Formmail - http://face2interface.com/formINSTal/ Webmaster's BBS - http://bbs.face2interface.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
On Sun, Feb 25, 2007 at 10:38:01AM -0500, Marty Landman wrote: On 2/24/07, Jerry McAllister [EMAIL PROTECTED] wrote: Well, I think you are past any label problems now and on to the bad sectors and/or finding superbocks.Although I am not quite clear from above what resulted in the 'INCOMPLETE LABEL...' message. Ok then, can you point me to somewhere that can learn about superblocks and give me an idea of what to do next? Most of what I figured out several years ago (and have essentially forgotten since) came from the handbook and something I found by searching the web that gave the layout of blocks and chains. I would have to go back searching again. Also assuming my bad sectors really are totally bad, wouldn't fsck allow me to mark them as unusable and move on? No, fsck does not do that. Marking blocks bad happend below the level of the OS - generally in the disk controller itself. It remaps sectors until it runs out of spares and when it runs out, it starts reporting unrecoverable errors. This is not even reported to the OS until it runs out of spares. The only thing you can do with those bad sectors is to try and figure out if any of them are superblocks. If they are, you can probably rebuild it from other superblock clones. If it is not, it is probably lost data. In that case try to overwrite the bad sector. If that works, then the sector itself is OK, but the data that was there is gone. If it doesn't work, then it is bad and there is a good chance that more than data got nuked in the power failure - eg, it damaged the disk or controller in some way. But, the next thing seems to be learning about how to follow the file chains and how to find and read and write superblocks. Alternatively you can decide it isn't worth the effort to recover and try and write over the drive completely - just totally trash it - and see if those bad sectors will write. If you did that, then you would have to rebuild the slice and partition table and do a newfs before you could again use the drive and everything previously on it would be lost. Good luck. Maybe someone who has some experience in tracking file chains can respond and give you more helpp than can I. jerry Marty -- Web Installed Formmail - http://face2interface.com/formINSTal/ Webmaster's BBS - http://bbs.face2interface.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
On Sun, 25 Feb 2007, Jerry McAllister wrote: On Sun, Feb 25, 2007 at 10:38:01AM -0500, Marty Landman wrote: On 2/24/07, Jerry McAllister [EMAIL PROTECTED] wrote: Well, I think you are past any label problems now and on to the bad sectors and/or finding superbocks.Although I am not quite clear from above what resulted in the 'INCOMPLETE LABEL...' message. Ok then, can you point me to somewhere that can learn about superblocks and give me an idea of what to do next? Most of what I figured out several years ago (and have essentially forgotten since) came from the handbook and something I found by searching the web that gave the layout of blocks and chains. I would have to go back searching again. Failing someone who actually knows what they're talking about re UFS structures chipping in to this discussion, all I can offer in addition is what my own exploration of manuals and a bit of googling turned up .. Firstly, Marty, you should run dumpfs(8) on your ad1s1a. With the -m switch, this produces a single line suitable for feeding into newfs with all parameters, and is probably worth saving for all slices in case of any subsequent emergencies. I've just done that for mine, anyway, along with fdisk and boot0cfg -v output, and bsdlabel output for UFS slices. Without the -m switch, feed the output to a file, or less, as it's very voluminous. For a 240GB drive, it'll likely be huge. However the data at the head is probably what's needed, though I can't make much of it. This post by Ian Dowse explains how to compute where the superblocks are, for a quoted example dumpfs: http://noc.caravan.ru/faq/SBLOCK.html Note however that Ian is talking about UFS1 (where the superblock offset was 32) but if you consult fsck_ffs(8) you'll see (under -b) that for UFS2, which you almost certainly would have used, it's at 140 .. I gather that's the offset from the start of each cylinder group? Also assuming my bad sectors really are totally bad, wouldn't fsck allow me to mark them as unusable and move on? No, fsck does not do that. Marking blocks bad happend below the level of the OS - generally in the disk controller itself. It remaps sectors until it runs out of spares and when it runs out, it starts reporting unrecoverable errors. This is not even reported to the OS until it runs out of spares. The only thing you can do with those bad sectors is to try and figure out if any of them are superblocks. If they are, you can probably rebuild it from other superblock clones. If it is not, it is probably lost data. In that case try to overwrite the bad sector. If that works, then the sector itself is OK, but the data that was there is gone. If it doesn't work, then it is bad and there is a good chance that more than data got nuked in the power failure - eg, it damaged the disk or controller in some way. Seeing if fsck_ffs will use any discovered alternate superblocks would be the first step, and if so, whether that helps to get it mounted. I'd certainly be careful to mount it read-only before trying data recovery! Since Marty has already been bravely using dd :) rewriting those sectors should be easy enough, bearing in mind the apparent off-by-one numbering difference between the sectors dd found bad and those fsck reported bad. But, the next thing seems to be learning about how to follow the file chains and how to find and read and write superblocks. Alternatively you can decide it isn't worth the effort to recover and try and write over the drive completely - just totally trash it - and see if those bad sectors will write. If you did that, then you would have to rebuild the slice and partition table and do a newfs before you could again use the drive and everything previously on it would be lost. Well if a dd rewriting those specific contiguous sectors failed, I doubt that newfs would do any better, so the dd is definitely worth a try, but I wouldn't write anything further to the fs until all else has failed. Good luck. I can only echo that, again. Maybe someone who has some experience in tracking file chains can respond and give you more helpp than can I. Ditto for that .. I'm now very thoroughly out of my depth here, though I've learned a few new things through the exercise. Maybe mailing Ian Dowse with circumstances and the dumpfs head might be worth a try, Marty? See the website committers' page for his address. Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
On Sat, Feb 24, 2007 at 06:12:39PM +1100, Ian Smith wrote: On Fri, 23 Feb 2007, Jerry McAllister wrote: Jerry, just on a couple of points: Me to Marty: Does the above result mean that my boot sector is ok? I think maybe you might be getting some of your terminology shuffled around.Your boot sector is not at question here. It doesn't affect the ability to read the disk partition. I was talking about sector 0 on ad1. If the disk were bootable it would be the 'boot sector', but it's not bootable. It still contains the DOS partition table though. boot0cfg -v drive shows this info too. OK. Yes, he already worked on the sector 0 earlier. The DOS partition table is what is called the slice table in FreeBSD. That seems to be OK - as I noted. jerry Secondly, it looks like the slice table - which is what fdisk mucks with - is OK. Luckily .. though with only one slice on the disk, easily recreatable. What seems to be messed up is either the slice 1 label which contains the partition table. In fact, with one of your postings, it looked like it thinks it is slice 4, but I don't remember what you did to get that. Try 'fdisk ad0sY' where Y is any freebsd slice, and you'll get that (or at least, I do on both my ad0 freebsd slices). Maybe fdisk should barf or at least whinge rather than reporting the first sector of any slice specified as if it were a sector 0 / MBR / boot sector? Probably should barf or make some other error message. Anyway, one shouldn't run fdisk on a slice, but on the device, so that accounts for the weird message I suppose. jerry If none of this helps at all, then the problem is past the label and in to the filesystem structure itself. Then I think you are stuck with tracing superblocks as I pointed out before. That is going to take some study but it might work. Yep, it depends on how precious this data is, but no learning is wasted. Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
On Fri, Feb 23, 2007 at 05:13:37PM -0500, Marty Landman wrote: On 2/23/07, Jerry McAllister [EMAIL PROTECTED] wrote: I would go back to that bsdlabel ad1s1 and edit the 'a' partition Also changed the size and offset to match the 'c' partition. Looks like progress here but still haven't gotten all the way to a mount as you can see: %sudo bsdlabel -e /dev/ad1s1 # /dev/ad1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 49022341204.2BSD0 0 c: 4902234120unused0 0 # raw part, don't edit ~ ~ ~ /tmp/EdDk.YyKf4oHslF: 5 lines, 223 characters. %sudo fsck /dev/ad1s1a ** /dev/ad1s1a CANNOT READ BLK: 128 CONTINUE? [yn] y THE FOLLOWING DISK SECTORS COULD NOT BE READ: 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, /dev/ad1s1a: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 490223412 %sudo mount /dev/ad1s1a /hoss mount: /dev/ad1s1a: Input/output error %sudo fsck -y /dev/ad1s1 fsck: Could not determine filesystem type % Well, I think you are past any label problems now and on to the bad sectors and/or finding superbocks.Although I am not quite clear from above what resulted in the 'INCOMPLETE LABEL...' message. jerry Marty ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
On 2/23/07, Ian Smith [EMAIL PROTECTED] wrote: So just show 'fdisk ad1' to see the disk's partition (slice) table (which may be damaged, but it's the only one you're interested in). %sudo fdisk ad1 *** Working on device /dev/ad1 *** parameters extracted from in-core disklabel are: cylinders=486344 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=486344 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 490223412 (239366 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED % If 'fdisk ad1' isn't showing any sensible data for 'partition 1' (ad1s1) then your boot sector is hosed. Does the above result mean that my boot sector is ok? %sudo fsck /dev/ad1cs1 fsck: Could not determine filesystem type %sudo fsck /dev/ad1c fsck: exec fsck_unused for /dev/ad1c in /sbin:/usr/sbin: No such file or directory You shouldn't be doing any of this with the 'c' partition, which is meant to cover the whole disk, but doesn't describe any of its slices. Unfortunately I had incorrectly been using ad1s1c for this disk, is there anything I can do about it now? Would that help with the effort to recover the data? I gather you think your data should be on ad1s1. Does 'bsdlabel ad1s1' say anything sensible? %sudo bsdlabel ad1s1 # /dev/ad1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 4902234120unused0 0 # raw part, don't edit % If not, does bsdlabel ad1s2, ad1s3 or ad1s4, if fdisk ad1 shows anything in s2, s3 or s4. s2-4 all show No such file or directory for bsdlabel As you mentioned elsewhere, you appear to have a bunch of bad blocks early on this disk. Yes, based on working with the dd cmd on /dev/ad1s1 and playing with the skip parm have found that blocks 129-144 give input/output errors. Does this indicate a hardware error necessarily? This problem came about as the result of a power outage; might there just be hosed data on those sectors? Have you a spare drive you can dd this one to, in its current state? No, it's a 250GB drive, the largest on my LAN. Would have to buy a replacement drive and then dd to that. If it came to that, while a backup hd might be a good idea, I'd possibly just live with recreating the data instead. What does 'ls -l /dev/ad1*' have to say? %ls -al /dev/ad1* crw-r- 1 root operator0, 70 Feb 22 17:56 /dev/ad1 crw-r- 1 root operator0, 74 Feb 22 17:56 /dev/ad1a crw-r- 1 root operator0, 75 Feb 22 17:56 /dev/ad1c crw-r- 1 root operator0, 82 Feb 22 17:56 /dev/ad1cs1 crw-r- 1 root operator0, 94 Feb 22 17:56 /dev/ad1cs1c crw-r- 1 root operator0, 73 Feb 22 17:56 /dev/ad1s1 crw-r- 1 root operator0, 84 Feb 22 17:56 /dev/ad1s1c And please don't top-post .. Sorry about that Ian, appreciate your help. Marty -- Web Installed Formmail - http://face2interface.com/formINSTal/ Webmaster's BBS - http://bbs.face2interface.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
On Fri, Feb 23, 2007 at 11:08:29AM -0500, Marty Landman wrote: On 2/23/07, Ian Smith [EMAIL PROTECTED] wrote: So just show 'fdisk ad1' to see the disk's partition (slice) table (which may be damaged, but it's the only one you're interested in). %sudo fdisk ad1 *** Working on device /dev/ad1 *** parameters extracted from in-core disklabel are: cylinders=486344 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=486344 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 490223412 (239366 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED % If 'fdisk ad1' isn't showing any sensible data for 'partition 1' (ad1s1) then your boot sector is hosed. Does the above result mean that my boot sector is ok? I think maybe you might be getting some of your terminology shuffled around.Your boot sector is not at question here. It doesn't affect the ability to read the disk partition. Secondly, it looks like the slice table - which is what fdisk mucks with - is OK. What seems to be messed up is either the slice 1 label which contains the partition table. In fact, with one of your postings, it looked like it thinks it is slice 4, but I don't remember what you did to get that. The one I do remember recently is the output from a 'bsdlabel ad1s1' command and that showed a partition a and a partition c both containing the entire slice and both marked as 'unused'. I would go back to that bsdlabel ad1s1 and edit the 'a' partition line so that the fstype field is changed from 'unused' to 'BSD4.2' Then write that back just as with a normal 'vi' session (eg ESCwq) See what that does. Then try to do an fsck on /dev/ad1s1a If the bsdlabel does not show a partition 'a' like was mentioned in a previous post, but only a partition 'c', then, as I suggeested one of the times, make a partition 'a' that looks just like the 'c' one but change the 'unused' to BSD4.2. Leave the fstype for 'c' as unusued. If none of this helps at all, then the problem is past the label and in to the filesystem structure itself. Then I think you are stuck with tracing superblocks as I pointed out before. That is going to take some study but it might work. jerry %sudo fsck /dev/ad1cs1 fsck: Could not determine filesystem type %sudo fsck /dev/ad1c fsck: exec fsck_unused for /dev/ad1c in /sbin:/usr/sbin: No such file or directory You shouldn't be doing any of this with the 'c' partition, which is meant to cover the whole disk, but doesn't describe any of its slices. Unfortunately I had incorrectly been using ad1s1c for this disk, is there anything I can do about it now? Would that help with the effort to recover the data? I gather you think your data should be on ad1s1. Does 'bsdlabel ad1s1' say anything sensible? %sudo bsdlabel ad1s1 # /dev/ad1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 4902234120unused0 0 # raw part, don't edit % If not, does bsdlabel ad1s2, ad1s3 or ad1s4, if fdisk ad1 shows anything in s2, s3 or s4. s2-4 all show No such file or directory for bsdlabel As you mentioned elsewhere, you appear to have a bunch of bad blocks early on this disk. Yes, based on working with the dd cmd on /dev/ad1s1 and playing with the skip parm have found that blocks 129-144 give input/output errors. Does this indicate a hardware error necessarily? This problem came about as the result of a power outage; might there just be hosed data on those sectors? Have you a spare drive you can dd this one to, in its current state? No, it's a 250GB drive, the largest on my LAN. Would have to buy a replacement drive and then dd to that. If it came to that, while a backup hd might be a good idea, I'd possibly just live with recreating the data instead. What does 'ls -l /dev/ad1*' have to say? %ls -al /dev/ad1* crw-r- 1 root operator0, 70 Feb 22 17:56 /dev/ad1 crw-r- 1 root operator0, 74 Feb 22 17:56 /dev/ad1a crw-r- 1 root operator0, 75 Feb 22 17:56 /dev/ad1c crw-r- 1 root operator0, 82 Feb 22 17:56 /dev/ad1cs1 crw-r- 1 root operator0, 94 Feb 22 17:56 /dev/ad1cs1c crw-r- 1 root operator0, 73 Feb 22 17:56 /dev/ad1s1 crw-r- 1 root operator0, 84 Feb 22 17:56 /dev/ad1s1c And please don't top-post .. Sorry about that Ian, appreciate your help. Marty -- Web Installed Formmail -
Re: input/output error on hd
On 2/23/07, Jerry McAllister [EMAIL PROTECTED] wrote: I would go back to that bsdlabel ad1s1 and edit the 'a' partition Also changed the size and offset to match the 'c' partition. Looks like progress here but still haven't gotten all the way to a mount as you can see: %sudo bsdlabel -e /dev/ad1s1 # /dev/ad1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 49022341204.2BSD0 0 c: 4902234120unused0 0 # raw part, don't edit ~ ~ ~ /tmp/EdDk.YyKf4oHslF: 5 lines, 223 characters. %sudo fsck /dev/ad1s1a ** /dev/ad1s1a CANNOT READ BLK: 128 CONTINUE? [yn] y THE FOLLOWING DISK SECTORS COULD NOT BE READ: 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, /dev/ad1s1a: INCOMPLETE LABEL: type 4.2BSD fsize 0, frag 0, cpg 0, size 490223412 %sudo mount /dev/ad1s1a /hoss mount: /dev/ad1s1a: Input/output error %sudo fsck -y /dev/ad1s1 fsck: Could not determine filesystem type % Marty ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
On Fri, 23 Feb 2007, Marty Landman wrote: On 2/23/07, Ian Smith [EMAIL PROTECTED] wrote: So just show 'fdisk ad1' to see the disk's partition (slice) table (which may be damaged, but it's the only one you're interested in). %sudo fdisk ad1 *** Working on device /dev/ad1 *** parameters extracted from in-core disklabel are: cylinders=486344 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=486344 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 490223412 (239366 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: UNUSED % Ok, that looks right, doing the maths on cyl x heads x s/tk x 512 bytes. If 'fdisk ad1' isn't showing any sensible data for 'partition 1' (ad1s1) then your boot sector is hosed. Does the above result mean that my boot sector is ok? Looks like. By 'boot sector' here we're talking about sector 0 on ad1, which while it isn't your real boot sector (that's on ad0), it is where the ad1 partition table is stored, and is what fdisk is looking at here. It's also what 'boot0cfg -v ad1' should show you, re the slicing. I should mention here that I've read Jerry's reply, and (digging through the latest freebsd-questions digest) your reply to him, but you left me out of the ccs. I keep hearing that gmail makes doing proper followups difficult; you may have to make an extra effort to keep everybody cc'd. %sudo fsck /dev/ad1cs1 fsck: Could not determine filesystem type %sudo fsck /dev/ad1c fsck: exec fsck_unused for /dev/ad1c in /sbin:/usr/sbin: No such file or directory You shouldn't be doing any of this with the 'c' partition, which is meant to cover the whole disk, but doesn't describe any of its slices. Unfortunately I had incorrectly been using ad1s1c for this disk, is there anything I can do about it now? Would that help with the effort to recover the data? What we seem to be unsure of is how the disk was originally partitioned. Normally if you'd used sysinstall to allocate the entire second disk to a single freebsd slice, it would have showed up as (possibly) ad1s1a or (more likely) as ad1s1d, going on what happens to non-bootable freebsd slices here. In any case, you need to construct a good label for it. I gather you think your data should be on ad1s1. Does 'bsdlabel ad1s1' say anything sensible? %sudo bsdlabel ad1s1 # /dev/ad1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] c: 4902234120unused0 0 # raw part, don't edit Ok, apart from not having an a or d or whatever partition, it looks ok. As you mentioned elsewhere, you appear to have a bunch of bad blocks early on this disk. Yes, based on working with the dd cmd on /dev/ad1s1 and playing with the skip parm have found that blocks 129-144 give input/output errors. Does this indicate a hardware error necessarily? This problem came about as the result of a power outage; might there just be hosed data on those sectors? Not to get your hopes up too high, but yes it's possible to hose a bunch of sectors, especially on a power outage at a bad moment, without there being any physical damage, so yes these might come good when re-written. I had exactly that happen to a 15GB IBM drive, which newfs fixed ok, after I'd spent ages getting what was recoverable off it. However it depends on what was on those sectors, and from the numbers at 63 sectors/track, they could be superblock /or root directory sectors, which likely spells difficulty for recovery. Have you a spare drive you can dd this one to, in its current state? No, it's a 250GB drive, the largest on my LAN. Would have to buy a replacement drive and then dd to that. If it came to that, while a backup hd might be a good idea, I'd possibly just live with recreating the data instead. Well I'd at least try getting a copy of the first few some tens of megs, whatever you can afford to dd elsewhere. I've not used it, but look at 'conv=noerror' in dd(1) which should copy it ok replacing the unreadable sectors with nulls but preserve the rest, hopefully including some other superblocks, which you may have to hunt for, to give to fsck. What does 'ls -l /dev/ad1*' have to say? %ls -al /dev/ad1* crw-r- 1 root operator0, 70 Feb 22 17:56 /dev/ad1 crw-r- 1 root operator0, 74 Feb 22 17:56 /dev/ad1a crw-r- 1 root operator0, 75 Feb 22 17:56 /dev/ad1c crw-r- 1
Re: input/output error on hd
On Fri, 23 Feb 2007, Jerry McAllister wrote: Jerry, just on a couple of points: Me to Marty: Does the above result mean that my boot sector is ok? I think maybe you might be getting some of your terminology shuffled around.Your boot sector is not at question here. It doesn't affect the ability to read the disk partition. I was talking about sector 0 on ad1. If the disk were bootable it would be the 'boot sector', but it's not bootable. It still contains the DOS partition table though. boot0cfg -v drive shows this info too. Secondly, it looks like the slice table - which is what fdisk mucks with - is OK. Luckily .. though with only one slice on the disk, easily recreatable. What seems to be messed up is either the slice 1 label which contains the partition table. In fact, with one of your postings, it looked like it thinks it is slice 4, but I don't remember what you did to get that. Try 'fdisk ad0sY' where Y is any freebsd slice, and you'll get that (or at least, I do on both my ad0 freebsd slices). Maybe fdisk should barf or at least whinge rather than reporting the first sector of any slice specified as if it were a sector 0 / MBR / boot sector? If none of this helps at all, then the problem is past the label and in to the filesystem structure itself. Then I think you are stuck with tracing superblocks as I pointed out before. That is going to take some study but it might work. Yep, it depends on how precious this data is, but no learning is wasted. Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
You may have lost the partition table. You can try repartitioning the drive but do NOT do a newfs. You can easily try it in sysinstall. -Derek At 04:19 PM 2/22/2007, Marty Landman wrote: I wrote about this problem before, still working on recovery. After a power outage I lost my primary slave hd, a 250MB Maxtor. Got rebooted ok by editing it out of the fstab i.e. %cat /etc/fstab # DeviceMountpoint FStype Options Dump Pass# /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 ... #/dev/ad1s1c/hoss ufs rw 2 2 % It's been explained to me that ad1s1c was an inappropriate name for the partition on this drive, will change that after fixing this mess. Here is a problem symptom summary: %sudo mount /dev/ad1s1c /hoss mount: /dev/ad1s1c: Input/output error %sudo mount /dev/ad1s1 /hoss mount: /dev/ad1s1: Input/output error %sudo fsck -f /dev/ad1s1 fsck: Could not determine filesystem type %sudo fsck -f /dev/ad1s1c fsck: exec fsck_unused for /dev/ad1s1c in /sbin:/usr/sbin: No such file or directory % Have determined from dd's that there's data on here, wonder though if the power outage caused some permanent damage. Have isolated the errors to blocks 129 through 144: %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=127 1+0 records in 1+0 records out 512 bytes transferred in 0.008638 secs (59274 bytes/sec) %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=128 dd: /dev/ad1s1: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 1.315347 secs (0 bytes/sec) ... [repeats for skip=129 to skip=142] %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=143 dd: /dev/ad1s1: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 1.336348 secs (0 bytes/sec) %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=144 1+0 records in 1+0 records out 512 bytes transferred in 0.018065 secs (28342 bytes/sec) So, I need to know what to do next. Have been looking for pertinant information to learn how to pick apart whatever's keeping my drive for being mountable and fix manually but either don't know what to look for or haven't found the right explanation yet. For instance, is it possible if I somehow 'eliminated' blocks 129 through 144 that the volume would then mount for me? Any help would be appreciated. Marty -- Web Installed Formmail - http://face2interface.com/formINSTal/ Webmaster's BBS - http://bbs.face2interface.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
On Thu, Feb 22, 2007 at 04:34:24PM -0600, Derek Ragona wrote: You may have lost the partition table. You can try repartitioning the drive but do NOT do a newfs. You can easily try it in sysinstall. Yes, that has been mentioned - I wasn't sure if it would work as desired - without overwriting too much - or not. But, if it is tried , be sure to use the exact partition schema as was done before. I think that was everything in one partition - called c, but I am not sure that is exactly what was done. So, the question is, did the OP use bsdlabel (alone or in sysinstall) when originally creating that filesystem? If so, probably using bsdlabel again on it - WITHOUT doing a newfs - would be worth trying. It probably can't do anything worse than what is already the case. If it was all one partition in a single slice, then run bsdlabel -e on the slice /dev/ad1s1 and take out the unused type from 'c' and make it BSD4.2.Make the offset '*' and the size be everything. Then exit out and hope for the best. jerry -Derek At 04:19 PM 2/22/2007, Marty Landman wrote: I wrote about this problem before, still working on recovery. After a power outage I lost my primary slave hd, a 250MB Maxtor. Got rebooted ok by editing it out of the fstab i.e. %cat /etc/fstab # DeviceMountpoint FStype Options Dump Pass# /dev/ad0s1b noneswapsw 0 0 /dev/ad0s1a / ufs rw 1 1 ... #/dev/ad1s1c/hoss ufs rw 2 2 % It's been explained to me that ad1s1c was an inappropriate name for the partition on this drive, will change that after fixing this mess. Here is a problem symptom summary: %sudo mount /dev/ad1s1c /hoss mount: /dev/ad1s1c: Input/output error %sudo mount /dev/ad1s1 /hoss mount: /dev/ad1s1: Input/output error %sudo fsck -f /dev/ad1s1 fsck: Could not determine filesystem type %sudo fsck -f /dev/ad1s1c fsck: exec fsck_unused for /dev/ad1s1c in /sbin:/usr/sbin: No such file or directory % Have determined from dd's that there's data on here, wonder though if the power outage caused some permanent damage. Have isolated the errors to blocks 129 through 144: %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=127 1+0 records in 1+0 records out 512 bytes transferred in 0.008638 secs (59274 bytes/sec) %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=128 dd: /dev/ad1s1: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 1.315347 secs (0 bytes/sec) ... [repeats for skip=129 to skip=142] %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=143 dd: /dev/ad1s1: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 1.336348 secs (0 bytes/sec) %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=144 1+0 records in 1+0 records out 512 bytes transferred in 0.018065 secs (28342 bytes/sec) So, I need to know what to do next. Have been looking for pertinant information to learn how to pick apart whatever's keeping my drive for being mountable and fix manually but either don't know what to look for or haven't found the right explanation yet. For instance, is it possible if I somehow 'eliminated' blocks 129 through 144 that the volume would then mount for me? Any help would be appreciated. Marty -- Web Installed Formmail - http://face2interface.com/formINSTal/ Webmaster's BBS - http://bbs.face2interface.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks transtec Computers for their support. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
Thanks Derek, I tried deleting and recreating the one slice on that drive in sysinstall, also rewriting the boot label. Didn't seem to help as shown: %sudo fdisk ad1cs1 *** Working on device /dev/ad1cs1 *** parameters extracted from in-core disklabel are: cylinders=486332 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=486332 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: UNUSED The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 0, size 5 (24 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 %sudo fsck /dev/ad1cs1 fsck: Could not determine filesystem type %sudo fsck /dev/ad1c fsck: exec fsck_unused for /dev/ad1c in /sbin:/usr/sbin: No such file or directory %sudo mount /dev/ad1cs1 /hoss mount: /dev/ad1cs1: Input/output error %sudo mount /dev/ad1c /hoss mount: /dev/ad1c on /hoss: incorrect super block %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=131 dd: /dev/ad1s1: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 1.199710 secs (0 bytes/sec) %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=127 1+0 records in 1+0 records out 512 bytes transferred in 0.018295 secs (27986 bytes/sec) %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=144 1+0 records in 1+0 records out 512 bytes transferred in 0.024593 secs (20819 bytes/sec) %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=143 dd: /dev/ad1s1: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 1.319451 secs (0 bytes/sec) % Wonder why it renamed my slice from ad1s1c to ad1cs1, and what I can do from here. Marty On 2/22/07, Derek Ragona [EMAIL PROTECTED] wrote: You may have lost the partition table. You can try repartitioning the drive but do NOT do a newfs. You can easily try it in sysinstall. -Derek ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
Jerry, Below is what I see in response to the cmd; as I'm unfamiliar with it could you please be more explicit about how I may proceed? Marty %sudo bsdlabel -e /dev/ad1s1 Password: # /dev/ad1s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 490234736 16unused0 0 c: 4902234120unused0 0 # raw part, don't edit ~ ~ On 2/22/07, Jerry McAllister [EMAIL PROTECTED] wrote: On Thu, Feb 22, 2007 at 04:34:24PM -0600, Derek Ragona wrote: You may have lost the partition table. You can try repartitioning the drive but do NOT do a newfs. You can easily try it in sysinstall. Yes, that has been mentioned - I wasn't sure if it would work as desired - without overwriting too much - or not. But, if it is tried , be sure to use the exact partition schema as was done before. I think that was everything in one partition - called c, but I am not sure that is exactly what was done. So, the question is, did the OP use bsdlabel (alone or in sysinstall) when originally creating that filesystem? If so, probably using bsdlabel again on it - WITHOUT doing a newfs - would be worth trying. It probably can't do anything worse than what is already the case. If it was all one partition in a single slice, then run bsdlabel -e on the slice /dev/ad1s1 and take out the unused type from 'c' and make it BSD4.2.Make the offset '*' and the size be everything. Then exit out and hope for the best. jerry ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: input/output error on hd
In freebsd-questions Digest, Vol 166, Issue 12 At Message: 15 On Thu, 22 Feb 2007 18:12:48 -0500 Marty Landman [EMAIL PROTECTED] wrote: Thanks Derek, I tried deleting and recreating the one slice on that drive in sysinstall, also rewriting the boot label. Didn't seem to help as shown: It's hard to guess if you don't show us the precise commands you issued, or at least the data you gave to sysinstall, and what you got back. %sudo fdisk ad1cs1 *** Working on device /dev/ad1cs1 *** parameters extracted from in-core disklabel are: cylinders=486332 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=486332 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: UNUSED The data for partition 2 is: UNUSED The data for partition 3 is: UNUSED The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 0, size 5 (24 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 Apart from the fact that 'ad1cs1' is a nonsense, fdisk run on slices always shows garbage, in this case indicating that only slice 4 is in use, with a nonsense size. In fact, I get _exactly_ your above rubbish partition report from running 'fdisk ad0s4' or 'fdisk ad0s2' - both of which are FreeBSD slices - and other types of rubbish on ad0s1 (DOS) and ad0s3 (different DOS) .. fdisk just blindly reports what it finds in binary, scarcely checking for consistency. 'fdisk ad0' (here) shows the Right Stuff. So just show 'fdisk ad1' to see the disk's partition (slice) table (which may be damaged, but it's the only one you're interested in). If 'fdisk ad1' isn't showing any sensible data for 'partition 1' (ad1s1) then your boot sector is hosed. %sudo fsck /dev/ad1cs1 fsck: Could not determine filesystem type %sudo fsck /dev/ad1c fsck: exec fsck_unused for /dev/ad1c in /sbin:/usr/sbin: No such file or directory You shouldn't be doing any of this with the 'c' partition, which is meant to cover the whole disk, but doesn't describe any of its slices. I gather you think your data should be on ad1s1. Does 'bsdlabel ad1s1' say anything sensible? If not, does bsdlabel ad1s2, ad1s3 or ad1s4, if fdisk ad1 shows anything in s2, s3 or s4. I wouldn't be running fsck (without the -n switch) or bsdlabel (with the -e switch) until you're pretty sure of what's going on where - though I gather it's a bit late for that sort of advice :( %sudo mount /dev/ad1cs1 /hoss mount: /dev/ad1cs1: Input/output error %sudo mount /dev/ad1c /hoss mount: /dev/ad1c on /hoss: incorrect super block %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=131 dd: /dev/ad1s1: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 1.199710 secs (0 bytes/sec) As you mentioned elsewhere, you appear to have a bunch of bad blocks early on this disk. They may or may not be critical to recovering the rest of your data, but with all this experimental poking around, things don't look too good. Have you a spare drive you can dd this one to, in its current state? %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=127 1+0 records in 1+0 records out 512 bytes transferred in 0.018295 secs (27986 bytes/sec) %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=144 1+0 records in 1+0 records out 512 bytes transferred in 0.024593 secs (20819 bytes/sec) %sudo dd if=/dev/ad1s1 of=/tmp/scratch bs=512 count=1 skip=143 dd: /dev/ad1s1: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 1.319451 secs (0 bytes/sec) % Wonder why it renamed my slice from ad1s1c to ad1cs1, and what I can do from here. Which 'it' do you mean? ad1cs1 makes no sense at all, and ad1s1c you shouldn't usually be messing with at all (as it says, don't edit). What does 'ls -l /dev/ad1*' have to say? And please don't top-post .. Marty On 2/22/07, Derek Ragona [EMAIL PROTECTED] wrote: You may have lost the partition table. You can try repartitioning the drive but do NOT do a newfs. You can easily try it in sysinstall. -Derek Yes, if you know precisely how the disk was partitioned before, which is perhaps dubious in this case .. hopefully Marty saved a copy of the boot sector for each disk earlier with boot0cfg -f ? Marty, if you don't mind reposting what I suppose you did earlier, show us these (all non-destructive): # fdisk ad1 # bsdlabel ad1s1(or whatever slice 1-4 it may be, or try them all) # boot0cfg -v ad1 Cheers, Ian ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any
