Date: Wed, 25 Jan 95 9:07:11 MST From: terry@cs.weber.edu (Terry Lambert) To: phk@ref.tfs.com (Poul-Henning Kamp) Cc: bde@zeta.org.au, freebsd-hackers@FreeBSD.org, rgrimes@gndrsh.aac.dev.com Subject: Re: More serial console stuff... Message-ID: <9501251607.AA18405@cs.weber.edu> In-Reply-To: <199501251543.HAA25244@ref.tfs.com> from "Poul-Henning Kamp" at Jan 25, 95 07:43:14 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > There is no standard way to decide how the drives are mapped. We're > > not going to be able to decide without asking the user. > > Only the bruteforce mode: > > In bootblock: > make table of > drive-id > geometry > checksum of sector #200 > checksum of sector #400 > checksum of sector #600 > > In kernel > find entry in table where checksums match... I'd actually (and have done so) suggest determining both the translated and untranslated geometry in the boot blocks (see pfdisk.exe sources to see how this is done -- it *is* done). Then you can traverse the drives on each controller looking for matching non-translated geometries. The drive order on a particular controller ought to be invariant in moving to protected mode. A CRC (or checksum - bletch) would probably be necessary if identical devices were used on multiple controllers, or if drive chaining had occurred on the 0x80/0x81 boottable device boundry such that two bootable devices were not on the same controller. Yes, I'm ignoring the (possible) case of 0x82 ... as a boot device, since the boot blocks themselves would have to examine a potential 128 devices (0x80 - 0xff) if we were attempting to be comprehensive. Perhaps asking the number of devices via INT 13 would make this not a problem. This puts us in the territory of needing to load a much larger boot block that is still BIOS based. As an interim measure, we probably want to only consider the BSD partitions of drives, since the BSD boot blocks do not apply to anything else anyway. Ensuring a unique volume ID is not guranteed by a checksum of anything less than the 'a' slice of a BSD disk, since the DOS MBR and partition code, as well as IBMIO.SYS, and the BSD boot code should all be the same, especially in the case of identical devices. One potential soloution here is to add a random volume ID number and a time stamp to the disklabel and use these fields by themselves. I note "interim" here, since it is likely that BSD will want to support installing to non-UFS root volumes, and non-BSD managed geometries of file systems. One example would be a Linux-style umsdos install, where the BSD is non-destructively installed in a DOS directory heirarchy; this is conceptually very easy to accomplish, and destroys most of the road signs we have discussed using so far. Maybe the ultimate soloution is simply extending the search list on boot to include all drives as well as the 3 or 4 kernel names it likes to try? This would mean that it may need to try several times to do the boot, but that it would eventually succeed. Perhaps a simple timing change, such that the boot process only pauses for user override for the first kernel name attempt, instead of pausing on each attempt, would make this more palletable. 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?9501251607.AA18405>