Return to BSD News archive
Newsgroups: comp.os.386bsd.questions Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!howland.reston.ans.net!gatech!destroyer!cs.ubc.ca!newsserver.sfu.ca!sfu.ca!vanepp From: vanepp@fraser.sfu.ca (Peter Van Epp) Subject: Re: NetBSD and DOS coexistence ? Message-ID: <vanepp.737612701@sfu.ca> Sender: news@sfu.ca Organization: Simon Fraser University, Burnaby, B.C., Canada References: <1993May15.164807.15131@alf.uib.no> <1t5kqp$mh4@lucy.ee.und.ac.za> <1993May16.212102.6346@fcom.cc.utah.edu> Date: Mon, 17 May 1993 04:25:01 GMT Lines: 30 terry@cs.weber.edu (A Wizard of Earth C) writes: >2) If the drive doesn't use translated geometry (the translated and > unstranslated geometries are the same), you simply need to multiply > the number of DOS cylinders (1c) by the number of heads and sectors > to get the offset of the 386bsd partition from the start of the > disk. Actually the comment field on the end of the line of pfdisk tells you this. The "start" number is the offset in sectors from the start of the disk and can be fed straight to the install program (at least it worked for me). >4) How to smarten up install so this BS isn't necessary. > Basically, the second stage boot needs to record the translated > geometry information in a memory area not tromped by the kernel > on startup. The kernel needs to record the information in a > local area during init and make it available through a special > ioctl() to all disk devices. Fortunately, there is a convenient > block of memory not already in use to do this: the unused bounce > buffer hunk. Does this indicate that the DIOCGDINFO ioctl that returns the disklabel structure that Julian's SCSI driver has filled in is sometimes not correct? I have a set of patches for pfdisk that use this to get the geometry under 386BSD and it appears to work on my Adaptec. Several other people have been given copies (hopefully to test with other disk types) but I haven't heard any results yet.