Date: Thu, 28 Mar 1996 19:57:14 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-hackers@FreeBSD.org, jerry@border.com Subject: Re: fdisk and partition info Message-ID: <199603290257.TAA04368@phaeton.artisoft.com> In-Reply-To: <199603280839.JAA23576@uriah.heep.sax.de> from "J Wunsch" at Mar 28, 96 09:39:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
> As Terry Lambert wrote: Actually, someone else wrote, and I responded... > > 1) Assume the geometry is translated, and that it is > > 1024/64/256. This is what the current FreeBSD slice > > code does, much to the consternation of those of us > > who own WD1007 or other non-translating controllers. > > This is not right. The FreeBSD kernel gets the BIOS geometry (for the > first N BIOS drives) passed from the bootstrap. This might or might > not be a `translated' one (though it's normally translated for all > modern disks). Bzzt. Which controller is BIOS drive 0x80 on? In BSD, controllers show in probe (config file) order. In BIOS, controllers show in INT 13 hook order. [ ... ] > The consternation does only result out of the usage of ``spare > sectors'' at controller level on the WD1007V. Don't use them, and you > should be going. (You can always use bad144 sector sparing, and if > your drive exceeds 1024 cylinders from a BIOS point of view, you could > handle this by using two BSD slices, where the first one is below 1024 > and contains at least the root f/s.) The default seeting for the WD1007 controller from the manufacturer is "sector sparing enabled". What you are saying is that if you are trying to install along side an existing Os, you are out of luck: you must reformat the drive. Which is the case, since it *is* possible to probe the number of heads and the fact that it's a WD1007 as opposed to some other WD interface drive... the problems are: a) The driver doesn't do it b) If the driver did it, you'd still be screwed because of the controllers not being attributed (drives are attributed, controllers are not). This really should be handled at a controller instance level rather than a drive instance (the settings apply to all drives on the controller). > > 2) Interpolate the geometry from an existing DOS partition > > table, and the known rules of behaviour for the DOS fdisk > > program. Specifically, starting and ending on cylinder > > boundries, etc.. Since it is possible to have multiple > > That's what libdisk does. While this is a good idea for drives that > do already have a DOS partition, it can cause some serious troubles > for uninitialized disks (or disks with non-fdisk-table previous > operating systems). This is what caused the ``You'd best install a > DOS partition first'' attitude for FreeBSD 2.0.5. (And since this > attitude deemed to be unacceptable for people who didn't wanna care > about any DOS partition at all, since all they want is FreeBSD, this > caused me to invent the ``dangerously dedicated'' mode of > installation.) "Dangerously dedidcated" is a misnomer. I've always found it annoying. What it means is that the second stage (BSD) boot is put in place of the MBR. For WD1007 with > 1024 cylinders, this shoots down the "use two partitions to make Bad144 happy with the boot disk" idea you put forth above (note: this should work, there's no technical ambiguity preventing it from working, but the current code doesn't handle that case). > > geometries result in the same values, especially when you > > have a small number of partitions (for instance, one), > > this is not a 100% reliable approach -- in general, it is > > so *unreliable* that the slice code was invented to replace > > it. It's possible to "help" this approach be more accurate > > The slice code was invented to cover multiple fdisk slices at all, > e.g. to handle more than one slice with a 0xa5 signature (though you > can still only boot from the first one), or to handle ``DOS extended > partitions''. That was a nice "while we're in the code", I think. Wasn't it a side effect of the general fixup? > > using the 32 bit absolute sector address, which is also in > > the partition table. The problem with that is that older > > FDISK programs did not generally fill out the 32 bit sector > > offset correctly, so determining this information is usually > > no more reliable if the offset happens to check a valid > > geometry [NB: the FReeBSD FDISK should always fill these > > fields out correctly in any case). > > fdisk did always fill out these parameters correctly (or at least, it > told you about its idea before writing them to the disk, so you've > been able to manually intervent if the idea was wrong). Only a > ``disklabel -B'' installed a bogus fdisk table, see above. No. I know for a fact that at lease some versions of DOS 2.11 and prior did not fill out the 32 bit sector offset field correctly. Leading Edge was one of the offenders here. > > 3) Ask the BIOS. There are several ways to do this: > > > b) Implement a multi-stage boot as opposed to a two > > stage boot, ... > > Funny, our two-stage boot does already ask the BIOS, and pass these > values to the kernel. UTST. (Use the source, Terry. :) Again, the drive identification passed to the kernel fails if the POST order for hooking INT 13 isn't the same as the BSD controller probe order. 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?199603290257.TAA04368>