Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 24 Jul 2000 15:38:51 -0700
From:      Kent Stewart <kstewart@urx.com>
To:        John Baldwin <jhb@pike.osd.bsdi.com>
Cc:        chad@DCFinc.com, stable@FreeBSD.ORG
Subject:   Re: No /boot/loader (dangerously dedicated)
Message-ID:  <397CC57B.8BD1086F@urx.com>
References:  <200007241949.MAA60720@pike.osd.bsdi.com>

next in thread | previous in thread | raw e-mail | index | archive | help


John Baldwin wrote:
> 
> Chad R. Larson wrote:
> > As I recall, John Baldwin wrote:
> > >> Folks, gemoetries are for brain damaged PC operating systems.
> > >> All the box needs to boot is a proper MBR. BIOSes that
> > >> don't boot from a dedicated disk are _broken_.
> > >
> > > No, they are actually smart in that they attempt to use a geometry
> > > that matches the MBR so that you can move disks around.  As a result,
> > > when we try to fake it, it confuses them.
> >
> > No, they are for brain-damaged operating systems that are trying to
> > stay compatable with drives built in the Jurassic era when geometry
> > meant something.  You and I both know that my Quantum Fireball
> > doesn't have 63 heads, which would imply 32 platters.  And never mind
> > that there are a variable number of sectors on a track, depending on
> > if we're talking an outer track or an inner track.
> 
> No.  They are a mandated part of the _PC_ _archictecture_.  This is
> _not_ an OS issue.  We are writing the "FreeBSD OS" that runs on the
> "PC architecture".  We are _not_ designing the "FreeBSD PC architecture"
> and writing our own BIOS.  *sigh*

What was worse on the SuperMicro P5STE system, that I first installed
FreeBSD 2.2.8 on, was once I installed the DD mode, the system
wouldn't boot. There is an moment when the bios appears to query the
hard drive and the system would hang at that point. It never got to
the point that I could boot from a floppy and repair the mbr.

There are probably ways around it now but back then the only thing I
new how to do was use the Manufacturer's low level formater. They did
the llf via port I/O and didn't need the drive added to the bios HD
drive table. No mbr was better than one that would totally hang the
system.

Kent
> 
> > Disks should be treated as a linear list of blocks.  The rest is
> > just overhead, chicken-waving, backward-compatability magic.
> 
> In theory, yes, and that is how my latest EDD commits to the toolchain
> work, but they still use the MBR.  The MBR has both LBA and cylinder
> addresses.
> 
> > The confusion results when two different O/Ss (or the device
> > drivers, or the drive firmware) apply different mapping algorithms
> > to turn a logical block address into a cyl/trk/sec value.
> 
> No.  The confusion arises when the BIOS and the OS disagree on the
> geometry.  DOS doesn't have this problem since it uses the BIOS to
> do its I/O and has a mapping of drive letters to BIOS drive numbers.
> We, on the other hand, don't use the BIOS for I/O once the kernel is
> started, nor do we have a reliable method of mapping BIOS drive numbers
> to our own adX or daX unit numbers.
> 
> > What you're saying is that we should follow the existing convention
> > of using values stored in the MBR because it will work with very old
> > hardware, and you could move a drive from a new machine to an old
> > one without leaving the data apparently scrambled.
> 
> MBR's are not only used for old hardware, they are mandated for EFI
> (the firmware used by the IA-64 and possibly PC's in the not too
> distant future) because EFI uses a FAT-32 slice as a boot slice.
> Using a valid MBR with valid slices (respect cylinder boundaries, don't
> use the first cylinder) are a _mandated_ part of the PC architecture.
> In the case where a drive does not include an existing MBR and the
> drive's geometry reported by the ATA INQUIRY (or DRIVE IDENTIFY)
> command do not match the geometry used by the BIOS, we have no way to
> detect that this is happening or to determine what geometery the BIOS
> uses for this drive.  Dangerously dedicated mode is just a hack to
> work around this problem that happens to violate the PC architecture
> in a couple of ways.  As a result, when smarter (not broken) BIOS's
> attempt to match the geometry in the MBR as their workaround to the problem
> so that they can boot off of any valid MBR by adjusting to the geometry
> within it, their workaround collides with our workaround and boom.
> 
> > What some of us are saying is we don't care about moving drives
> > around, or legacy hardware.  And we know enough to recognize when
> > that can be a problem, and are willing to deal with it.
> 
> Well, right now dedicated modes are not scheduled to be axed any time
> soon if at all.  Some things I do plan on doing are:
> 
> 1) Fix dangerously dedicated mode to match truly dedicated mode and
>    use the actual slice length rather than outright lying about the
>    slice length.
> 2) Add some heuristics between the loader and libdisk/fdisk that can
>    hopefully make some better guesses at what geometry the BIOS is
>    using for a given drive.
> 3) Axe the dangerously dedicated mode question box and make it a
>    seperate key in the fdisk menu.  This way newbies are not asked
>    if they would like to shoot themselves in the foot.  However, people
>    may still use it if they so choose.
> 
> >       -crl
> 
> --
> 
> John Baldwin <jhb@bsdi.com> -- http://www.FreeBSD.org/~jhb/
> PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc
> "Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message

-- 
Kent Stewart
Richland, WA

mailto:kbstew99@hotmail.com
http://kstewart.urx.com/kstewart/index.html
FreeBSD News http://daily.daemonnews.org/

Bomber dropping fire retardant in front of Hanford Wild fire.
http://kstewart.urx.com/kstewart/bomber.jpg


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?397CC57B.8BD1086F>