Date: Sun, 18 Jun 95 13:16:29 MDT From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, bugs@FreeBSD.org, hlew@genome.Stanford.EDU Subject: Re: 2.05R panics on boot Message-ID: <9506181916.AA18337@cs.weber.edu> In-Reply-To: <199506180538.PAA15480@godzilla.zeta.org.au> from "Bruce Evans" at Jun 18, 95 03:38:55 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> 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? Consider the case of two identical drives that need OnTrack, one as the master and one as the slave. The OnTrack, dealing as it does with only bootable devices, must apply to all. > Can the problem be fixed by installing Ontrack on all disks, I believe so, though not for any good reason. The reason it would work is that BSD would see the ontrack on the boot device and act appropriately for a boot device not root. The geometry management of the second device by OnTrack, being correct, is still acceptable. > or configuring it to only manage the disk(s) that it is installed on? I find it questionable to believe that OnTrack adjusts the starting sector and not simply the geometry for the secondary disks. If it does the former, then I would say it is a bug in OnTrack, since it is generating unusable area on the second disk. The difference, of course, to the user is that the BSD install to the second disk should either be by way of an OnTrack boot of the BSD floppy, or into a 63 sector ofsset partition table, respectively. As I said before, you *could* work around this with an install order dance if you were aware of the behaviour beforehand. The main issue will be the main partition table entry location for the BSD partition (in an Ontrack adjusted table or not) and the offset locations in the BSD disklabel (or not). I believe one or both of these to be the case because of the demonstrated failures. > >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. I was under the impression that the FreeBSD proper view was abstracted from the disklabel seperate from the C/H/S area within the disklabel for the BIOS boot. If this is still the case, then you could hack the absolute offsets with relative impunity. If it's not the case, well, then that's a problem. > >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. It shouldn't be possible for this to happen according to the OnTrack people. Also this soloution assumes the offsets are applied to non-bootable drives, which may not be the case (it could be the BSD disklabel screwup above). > I think we're finding complications where none exist. It's hard to debug > without seeing the output of boot -v and sysinstall. Yes. In this case, though, I'd like to see the pfdisk output for both drives given a DOS boot from floppy followed by a DOS boot from the HD. It would identify the problem precisely once the BSD code was examined to see what it would do with the resulting case. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9506181916.AA18337>