From owner-freebsd-hackers Thu Jun 8 11:48:53 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id LAA23558 for hackers-outgoing; Thu, 8 Jun 1995 11:48:53 -0700 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id LAA23552 for ; Thu, 8 Jun 1995 11:48:52 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA05420; Thu, 8 Jun 95 12:39:43 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506081839.AA05420@cs.weber.edu> Subject: Re: problem To: temp@temptation.interlog.com (Temptation) Date: Thu, 8 Jun 95 12:39:42 MDT Cc: hlew@genome.Stanford.EDU, freebsd-hackers@freebsd.org In-Reply-To: from "Temptation" at Jun 8, 95 05:12:43 am X-Mailer: ELM [version 2.4dev PL52] Sender: hackers-owner@freebsd.org Precedence: bulk [ ... regarding "OnTrack Disk Manager" ... ] > No. it didn't require it. Nor did I use DM. a friend send me disk doctor. > that data was there, but it Norton failed to retrieve it correctly. so > it's history. You should run pfdisk.exe from a DOS disk and report the partition information that exists on the drive. Many manufacturers use DM on your behalf and don't tell you about it. I suspect you will find a single partition (and would like to know what type it says it is), which is the magic indicator that you had an OnTrack Disk Manager partition on the drive. The DM loads code in it's MBR to redirect INT 13/INT 21 by subtracting 64 sectors (to account for itself) and then translating subsequent BIOS calls relative to the area immediately after their MBR. Then immediately following that is the DOS MBR, which thinks it's at 0, containing your partition table written using the DM translated geometry. If this is the case, then all of your data is still there, and you need another copy of the base 64 sectors, and everything will magically work again. The problem is that when you boot off of floppy to install BSD, the DM code is (of course) not loaded, and you don't see the translated geometry or the 64 sector offset. What this would probably mean to you is that the BSD information is offset 64 sectors into the DOS partitions end (usually not a problem unless your drive was full under DOS, but something that should be fixed anyway). For anything above and beyond an explanation (like a dump of the first 64 sectors to replace those blown away, a utility to suck them off another machine or write them to yours from a DOS booted floppy, etc.) you will need to contact someone else who happens to have the stuff on hand (I don't). A fix for BSD may be partially there already (I seem to remember that it is from the list discussions), and probably has to do with the slicer not offseting where it writes the partition table when the DM is detected as present (or it simply not being detected). Note that DM is not the only utility that does this kind of crap, but it is probably the best and most frequently (80-90%) used. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.