From owner-freebsd-bugs Sat Jun 17 22:44:51 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA29195 for bugs-outgoing; Sat, 17 Jun 1995 22:44:51 -0700 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA29143 for ; Sat, 17 Jun 1995 22:44:33 -0700 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id PAA15480; Sun, 18 Jun 1995 15:38:55 +1000 Date: Sun, 18 Jun 1995 15:38:55 +1000 From: Bruce Evans Message-Id: <199506180538.PAA15480@godzilla.zeta.org.au> To: bde@zeta.org.au, terry@cs.weber.edu Subject: Re: 2.05R panics on boot Cc: bugs@FreeBSD.org, hlew@genome.Stanford.EDU Sender: bugs-owner@FreeBSD.org Precedence: bulk >> This seems to be the case that I said can't work. Apparently wd1 doesn't >> have Ontrack on it, but Ontrack on the boot disk adjusts for all disks. >YES. >Makes perfect sense, actually. Once you are booting BSD, the disk BSD is >on is hat it thinks the boot disk is. It can't know the INT 13 chaining >used by the BIOS. It's not clear to me whether this is an installation error. Why is Ontrack managling disks that it isn't on? Can the problem be fixed by installing Ontrack on all disks, or configuring it to only manage the disk(s) that it is installed on? >You could manually fix this up. >I hesistate to describe the process (so I won't) since it's rather complex >and requires a deep understanding of the boot process. In broad strokes, >it would involve modifying the second disks partition table, installing, >modifying the installed disk label and partition table, and going from there. This won't work. If there is only one partition table, then the FreeBSD boot loader and FreeBSD proper will see the same one, and FreeBSD proper needs to see a table modified as above. >If you *only* have BSD on the second drive, and are willing to blow it >away, you can get the same effect by making the BSD drive the primary >drive, installing OnTrack (assuming you have it), then installing BSD onto >what is now the first drive. >When you put ehe drive back to the second drive and put the original drive >back on, it should work. Only if Ontrack doesn't doubly manage the second drive after you put it back. I think we're finding complications where none exist. It's hard to debug without seeing the output of boot -v and sysinstall. Bruce