Date: Mon, 4 Oct 2010 11:42:49 -0700 From: Robert <traveling08@cox.net> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-questions@freebsd.org Subject: Re: OT: fdisk Message-ID: <20101004114249.738a80fa@asus64> In-Reply-To: <20101005020924.H59829@sola.nimnet.asn.au> References: <20101004120028.1860F10657D0@hub.freebsd.org> <20101005020924.H59829@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Oct 2010 03:53:09 +1100 (EST) Ian Smith <smithi@nimnet.asn.au> wrote: Ian I am in the process of dd the entire disk to a 1TB disk but I wanted to respond to you. You have given a lot of good advice and information and I appreciate it. > > > ~> fdisk /dev/da1 > > > ******* Working on device /dev/da1 ******* > > > parameters extracted from in-core disklabel are: > > > cylinders=60801 heads=255 sectors/track=63 (16065 blks/cyl) > > > > > > Figures below won't work with BIOS for partitions not in cyl 1 > > > parameters to be used for BIOS calculations are: > > > cylinders=60801 heads=255 sectors/track=63 (16065 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 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX) > > > start 63, size 976773105 (476939 Meg), flag 0 > > > beg: cyl 0/ head 1/ sector 1; > > > end: cyl 1023/ head 15/ sector 63 > > > The data for partition 2 is: > > > <UNUSED> > > > The data for partition 3 is: > > > <UNUSED> > > > The data for partition 4 is: > > > <UNUSED> > > > So pausing here for a bit .. starting at 63 (cyl 0/ head 1/ sector1 > in CHS terms), looks correct for s1, one slice, whole disk for NTFS. > That should rule out a damaged MBR in sector 0 - though it doesn't > rule out the boot code in the first 2 or so sectors having been > clobbered. I have tried earlier to explain what might/could have happened but was most likely not specific enough. I will try to do better. This was the wife's computer. It had Xp Pro on the first slice and FreeBSD 7.x on the second. Windows started acting strange and then was rebooting as soon as the desktop rendered. I booted to safe mode and went back one day in the recover option. Same thing happened, i.e. reboot after desktop rendered. I again booted in safe mode and went back two days. Could never get it to boot again even in safe mode. I booted into FreeBSD and copied some critical files off of the Windows slice that she was desperate to have. I put them on a pen drive so she could then access via her laptop. I checked the backup drive and saw that all was fine. I had the D$S stuff backing up nightly. I was able to mount either drive with _ntfs or ntfs-3g. No matter what I tried I could not get windows to boot even in safe mode. I left it running on FreeBSD aver night expecting to have to reinstall windows in the morning. The next day the system had rebooted with the GAG screen up. I ran memtest for about 6 hours and it showed a couple of faults. I pulled one of the three 512M memory chips and it seemed to run OK but still could not boot windows. I reinstalled windows and was doing all of the updates when it started failing to boot. Somewhere in that time the backup (500GB) drive became invisible to windows. FreeBSD showed only ad6 without the s1 partition. I used "sade" to look at it and it did not show as ntfs. I marked it as ntfs thinking that would fix it but it probably caused all of these problems. Whatever is wrong with that computer it now completely messed up. It will not even power on. I strapped out the power connect pins 3 and 4 and the PS runs and the voltages check out. > > You can often poke around the beginning of disks to advantage with > say: # dd if=/dev/da1 bs=512 count=126 | hd | less > to see the first two tracks .. sector 63 should be where NTFS starts, > ie after sectors 0-62 on head 0. hd(1) skips repeated zeroes or 0xff > and such, so you can hunt through quite a lot of early sectors > without huge output in less, usually. > > > > Which looks a lot better. I can mount /dev/da1 and it shows > > Just to be clear, you mean: '# mount_ntfs /dev/da1 /mnt' ? > > (try to be sure to mount NTFS filesystems _explicitly_ read-only, > especially if likely damaged) > > > > ~> ls -l /mnt > > > total 70044 > > > -rwxr-xr-x 1 root wheel 2560 Dec 31 1600 $AttrDef > > > -rwxr-xr-x 1 root wheel 0 Oct 1 09:09 $BadClus > > > -rwxr-xr-x 1 root wheel 4194304 Dec 31 1600 $Bitmap > > > -rwxr-xr-x 1 root wheel 8192 Oct 1 09:09 $Boot > > > drwxr-xr-x 1 root wheel 0 Oct 1 09:09 $Extend > > > -rwxr-xr-x 1 root wheel 67108864 Oct 1 09:09 $LogFile > > > -rwxr-xr-x 1 root wheel 4096 Oct 1 09:09 $MFTMirr > > > -rwxr-xr-x 1 root wheel 0 Dec 31 1600 $Secure > > > -rwxr-xr-x 1 root wheel 131072 Oct 1 09:09 $UpCase > > > -rwxr-xr-x 1 root wheel 0 Oct 1 09:09 $Volume > > > -rwxr-xr-x 1 root wheel 45124 Aug 18 2001 NTDETECT.COM > > > drwxr-xr-x 1 root wheel 0 Oct 1 17:29 System Volume > > > Information > > > -rwxr-xr-x 1 root wheel 193 Oct 1 09:12 boot.ini > > > -rwxr-xr-x 1 root wheel 222368 Aug 18 2001 ntldr > > > > > > But I cannot mount /dev/da1s1 > > > > > > ~> sudo mount_ntfs /dev/da1s1 /mnt > > > mount_ntfs: /dev/da1s1: Invalid argument > > Ok, and its not clear why/how mount_ntfs would be happy mounting da1 > 'raw' but it sure looks like (at least part of) an NTFS root > directory; not necessarily all what you'd see as C:\ in windows > explorer, say; windows plays strange tricks the way it layers > directories for display. Perhaps explained above? > > There's weird dates (1600?) and only you would know if those October > 1st timestamps are of when you mounted it, or when windows last > accessed it? > > The fact that boot.ini is a few minutes later than some is > interesting; that's where entries for multi-booting NT may exist, and > maybe something messed with that, hardware glitch? or (not entirely > unknown :) one of a hundred thousand or so viruses? > > So, can you look at these files when so mounted? Can you do > something like 'du -d2 /mnt' and see anything useful? I'm just > guessing /hoping here that the disk may not be as badly scrambled as > you fear, despite the apparent oddness of it mounting like that. > > > Though it's an old (pre-XP) article, it's good basics. Note > especially that NTFS keeps a copy somewhere near the middle of the > disk of primary metadata, and that your ls above shows what's listed > there, eg $MFTMirr which presumably points to that metadata 'mirror' > somehow. > Thanks for that. > > > This drive was used for a backup of of the Docs&Sets "folders" of > > the XP drive. It also had music and photo files that are also on > > the FreeBSD computer so they are not that critical. The Docs&Sets > > folders are the most important to recover so if I can access the > > data, I can burn it to DVD. > > Well if you can descend into anything beyond the root directory you > got access to above mounting da1 (read-only hopefully!), you may be > in luck. D&S lives quite deep in the tree on windows (ie under the > per-user level) but you'd have to hunt the path from the root to > there on maybe another windows box. You may or may not have damaged > directories above. There in lies the whole nine yards. I have to get s1 mounted if I want to read anything. It is as if da1 is ntfs but da1s1 is not. > > You've received lots of great advice about tools to use _after_ > you've secured a full backup (for which dd is great), but in this > case I can't help suspecting the best tools to salvage / repair a > winXP NTFS disk are most likely found in windows land, probably > bewilderingly plentiful :) > > Put another way .. FreeBSD's NTFS (native or the fuse ports) may or > may not be up to read/write safely by now for normal use, but I'm not > sure they'd likely be up to what windows chkdsk / scandisk can do in > the way of filesystem repair, let alone some of the better > third-party tools. > As I have stated before, I was able to use photorec and move a hell of a lot of files to a spare slice but it will most likely take weeks or months to sort the wheat from the chaff. I am trying everything that is being suggested. If the process I am doing now ( dd ) does not work I will try Windows chkdsk on the copy I am doing. Thanks Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101004114249.738a80fa>