From owner-freebsd-bugs Sun Jun 18 14:32:16 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id OAA04619 for bugs-outgoing; Sun, 18 Jun 1995 14:32:16 -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 OAA04611 for ; Sun, 18 Jun 1995 14:32:15 -0700 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19481; Sun, 18 Jun 95 15:25:11 MDT From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9506182125.AA19481@cs.weber.edu> Subject: Re: 2.05R panics on boot To: hlew@genome.Stanford.EDU (Howard Lew) Date: Sun, 18 Jun 95 15:25:10 MDT Cc: bde@zeta.org.au, bugs@FreeBSD.org In-Reply-To: from "Howard Lew" at Jun 18, 95 01:28:59 pm X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > Okay, if boot from DOS (and with no Ontrack DM installed)... here's the > output from pfdisk 0 (the 850MB Ontrack DM DOS Drive) and pfdisk 1 (540 > MB FreeBSD drive) > > # Partition table on device: 0 > geometry 1024 16 63 (cyls heads sectors) > # ID First(cyl) Last(cyl) Name # start, length (sectors) > 1 84 0 1652 unkno # 1, 1666223 > # note: last(1): phys=(628,15,63) logical=(1652,15,63) > # note: first(1): phys=(0,0,2) should be (0,1,1) > 2 0 0 0 empty # 0, 0 > 3 0 0 0 empty # 0, 0 > 4 0 0 0 empty # 0, 0 This is the OnTrack DM pseudo-partition table; this makes the BIOS POST happy. This drive has OnTrack installed on it. > # Partition table on device: 1 > geometry 1022 16 63 (cyls heads sectors) > # ID First(cyl) Last(cyl) Name # start, length (sectors) > 1 165 0 1052 unkno # 63, 1061361 > # note: last(1): phys=(1023,15,63) logical=(1052,15,63) > 2 0 0 0 empty # 0, 0 > 3 0 0 0 empty # 0, 0 > 4 0 0 0 empty # 0, 0 This is the BSD "pseudo" partition table -- it's "pseudo" because it is correct from a DOS perspective and the information is actually used by BSD in the boot process. > Now if I boot from the hard drive with Ontrack DM's dynamic drive overlay > installed... > > # Partition table on device: 0 > geometry 826 32 63 (cyls heads sectors) > # ID First(cyl) Last(cyl) Name # start, length (sectors) > 1 1 0 825 DOS12 # 63, 1665153 > 2 0 0 0 empty # 0, 0 > 3 0 0 0 empty # 0, 0 > 4 0 0 0 empty # 0, 0 This is the real DOS partition table. This is the table embedded in the DOS MBR (master boot record) that you are using OS-BS to replace. This partition table is being logically offset by the INT 13 redirector installed by the OnTrack DM's MBR. > # Partition table on device: 1 > geometry 1022 16 63 (cyls heads sectors) > # ID First(cyl) Last(cyl) Name # start, length (sectors) > 1 165 0 1052 unkno # 63, 1061361 > # note: last(1): phys=(1023,15,63) logical=(1052,15,63) > 2 0 0 0 empty # 0, 0 > 3 0 0 0 empty # 0, 0 > 4 0 0 0 empty # 0, 0 This is, once again, the BSD "pseudo" partition table. It;s existance here indicates that the OnTrack DM is not translating the second drives start location, nor is it translating the second drives geometry. Probably this is the case because it has not identified itself as existing on the second partition at all. The point of this is that the BIOS geometry seen by the OS-BS is not a translated geometry. > So it appears that nothing changes on the 540MB drive that doesn't use > Ontrack DM. So any ideas? Yes. The information above is sufficient, barring an error in the interpretation of the geometry by BSD, to get you installed correctly and booting BSD off the second drive using OS-BS. What you need to do is: 1) Make sure DM is on the first drive [this is done] 2) Boot the first drive under DOS to activate the DM INT 13 redirector. 3) Use the DOS installation to install OS-BS onto the first drive as a replacement for the displace DOS MBR. The partition table will exist in the OS-BS MBR instead of the DOS MBR. *) At this point, you should be able to boot of the first drive into the OS-BS menu and select "DOS", acusing the DOS to boot correctly. Do not proceed past this point until this is the case. 4) At this point you should be able to ask it to boot of the second drive (assuming you have OS-BS installed correctly. This will fail, but you should make sure that you can attempt to boot off the second drive. Subsequent steps will [potentially] require the reinstallation of BSD. If you are not prepared to do this, you should rely on booting with a floppy. To make it more convenient, you can change the default device in the floppy boot blocks, which will result in the floppy booting the correct device. The method for doing this is well documented in the hackers list archive on freefall.cdrom.com. This archive can also be accessed via www at http://www.freebsd.org. 5) Install OS-BS on the second drive. This may or may not be easy to accomplish. If the partition table on the second drive is a remnant of a DOS install, then this will be easy; otherwise you will have to use the DOS command fdisk/mbr on the second DOS drive. YOU MUST GIVE THE DOS DRIVE LETTER AS A PARAMETER. In addition, the /mbr option is not available in DOS revisions prior to 5.0. At this point you can install OS-BS and reinstall BSD. Now when you boot, you will get an option to choose the DOS partition or the second drive. Tho boot BSD, choose the second drive option in the OS-BS menu. You will get another OS-BS menu (the DOS option in this menus will not work). Choose the FreeBSD option, and it should boot correctly. The single possibility for error at this point is if the FreeBSD install incorrectly selects disklabel contents based on detecting the DM on the first drive. If this happens, you will need to contact the FreeBSD team for an updated installation that does not make this mistake. ====== Cannonically, the BSD should rewrite a boot manager on their own to make this process simpler. Realistically, this probably can not be done sufficiently portably, since the OnTrack DM is not the only program that uses the MBR replacement/INT 13 redirector mechanism to hide BIOS patches at the start of your hard drive. The best that can be achieved is the partial compatabilty. The one issue here is that the OS-BS install on the second drive could probably be avoided, and the non-working menu entries omitted. In that case, it subtracts a step from the boot process. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.