Date: Thu, 17 Oct 1996 11:22:31 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: kuku@gilberto.physik.rwth-aachen.de (Christoph Kukulies) Cc: freebsd-hackers@freefall.freebsd.org Subject: Re: 2.2-961014-SNAP install problem Message-ID: <199610171822.LAA06174@phaeton.artisoft.com> In-Reply-To: <199610171327.OAA29987@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Oct 17, 96 02:27:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I tried to install (skipping kernel config) 2.2-961014-SNAP on > a PPro-200 (ASUS P6NP5, 32MB, NCR BIOS, Quantum Atlas 2GB,\ > first PCI device IDE, second SCSI) > > The partition editor barfed at my disk geometry and > decided to take 2050/64/32 instead of the > native geometry of 3925/10/107. Trying to enforce > the latter (G option) doesn't seem possible. I'm curious: how do you propose to represent 107 in the 5 bits availble at the DOS INT 13 "raw read" interface which the boot blocks must use to read the data off the disk? How do you propose to represent it in the C/H/S storage area of the DOS partition table entry on the disk itself? A disk with that geometry must be, by definition, translated by the controller if the hardware is capable of supporting DOS at all. > After a first seemingly successful install of the filesystems > and extract from ftp.de.freebsd,org I got this > infamous 'Missing Operating System'. > > I'm clueless at the moment. A send install got hung > eternally at the box 'Copying device files' This is because you multiply the C/H/S value in the partition table by the drive geometry to get an absolute sector offset. This absolute sector offset is used as an input to the protected mode driver, which doesn't know about C/H/S (which is an artifact of the controller BIOS and/or a TSR, like the one installed by OnTrack's DiskManager v6.x or 7.x to handle LBA drives... ie: there is *always* translation to make the INT 13 interface happy. The "Missing Operating System" message comes from the first stage boot on the disk, which uses INT 13 I/O to load the DOS partition table, and then used the C/H/S values from the DOS partition table get the second stage boot track. Clearly, the geomtery that FreeBSD used did not match the actual translated geometry in use by the INT 13 interface (as I said before: because of C/H/S bit limitations, there *MUST* be translation). When the boot code wen to read the second stage boot code, it did not find a valid boot track. This probably means that the install wrote to some unknown area of your disk. This could happen if: 1) The drive uses non-linear BIOS translation to institute software sector sparing. 2) The drive has an LBA TSR tat is an INT 13 reirector, but BSD doesn't recognize the redirector (currently, FreeBSD only undestrands OnTrack's TSR, which is known to be offset 64 sectors into the disk). If this is the case, then the FreeBSD partition won't show up when you boot DOS from the hard drive and runfdisk, because it will have written the partition table in the tSR instead of the relocated partition table which is being used by the first stage boot. 3) The geometry assumptions were wrong. This will typically happen *every* time for ESDI drives and much older hardware that doesn't use the 64 head, 32 sector translation defaults (and the however many cylinders is necessaary to map the disk space). If the geometry assumptions are wrong, and there is not a TSR boot track ont he front of the disk (or it's ONTrack so FreeBSD recognizes it), then you can find out the correct geometry to use by downloading the DOS version of "pfdisk", booting DOS *OFF*THE*HARD*DRIVE* to ensure any INT 13 redirector is installed (a boot floppy won't insteall the hard drive INT 13 redirector, if any), and run pfdisk. It will report the geometry you should tell FreeBSD. Terry Lambert terry@lambert.org --- 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?199610171822.LAA06174>