Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Mar 2006 15:37:15 -0700
From:      Danny MacMillan <flowers@users.sourceforge.net>
To:        Bob Johnson <fbsdlists@gmail.com>
Cc:        Danny MacMillan <flowers@users.sourceforge.net>, bobo1009@mailtest2.eng.ufl.edu, freebsd-questions@freebsd.org
Subject:   Re: Can FreeBSD safely use a (un-booted from) drive that is invisible to the BIOS?
Message-ID:  <20060331223715.GB68298@aldebaran.local>
In-Reply-To: <54db43990603311248u5be790d5y91490e73bc9cf185@mail.gmail.com>
References:  <20060331200602.GA68298@aldebaran.local> <54db43990603311248u5be790d5y91490e73bc9cf185@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Mar 31, 2006 at 03:48:57PM -0500, Bob Johnson wrote:
> On 3/31/06, Danny MacMillan <flowers@users.sourceforge.net> wrote:
> > [,,,]
> > ad0 is the boot drive.  It is recognized by the BIOS, obviously, and
> > has been in the machine for some years.  ad2 is a new drive I just
> > added to the machine yesterday.  It is not visible to the BIOS at all.
> > If anyone can posit a reason it would not be visible to the BIOS, I
> > would like to know the answer.  The BIOS supports LBA and ad0 is more
> > than 8GB so it wouldn't appear to be the 8GB limit, and the next limit
> > I am aware of is comfortably larger than 76GB.
> 
> If ad2 were operating as the slave drive without a master on that
> controller, that could explain it, but that doesn't seem to be what's
> happening here.
> 

ad2 is the only device on the second controller and it is definitely
jumpered as master.  I also get the same behaviour when the second drive
is attached as a slave on the first controller (e.g. as ad1).

Interestingly, attaching an ATAPI CD-ROM drive as slave on the first
controller works.

> Are you sure you don't have the second drive disabled in the BIOS
> somehow?

Positive.  It's an old BIOS, the options are limited, but it is set to
"Auto" (choices Auto, User, and None).  I had a thought and changed the
addressing mode from "Auto" to "LBA" but it made no difference.  The
only difference between selecting "Auto" and "None" in the BIOS is that
when the setting is "Auto", the machine hangs at the following and will
not boot:

Secondary Master: Detecting [Press F4 to skip]

At this point, the machine is completely stuck -- pressing F4 does
nothing, neither does pressing <ctrl><alt<>del> if I recall correctly.
I have to power cycle it to get it to do anything.

Now that I'm going through this thought process, I have some vague
recollection that I used to have a second disk in there, but I had to
remove it because it stopped working for some reason -- it exhibited
the same hang when detecting the second drive.  At the time it didn't
occur to me to disable the drive in the BIOS to get the machine to
boot and just let FreeBSD access the drive directly.  Of course, it
doesn't speak favourably to the reliability of the hardware.

> > [...]
> >
> > Since I don't actually know what the BIOS thinks the geometry is,
> > I got cold feet and decided to ask the list.  I don't =think= it
> > should matter, since the BIOS shouldn't ever touch the disk, at least
> > as far as my understanding goes.
> 
> FreeBSD uses BIOS routines to start the boot process, then uses its
> own idea of what's on the disk.  So, as far as I know, you will only
> have a problem if they are different enough to either cause the boot
> process to fail, or on a dual boot system, to cause Windows to think
> the partitions are in different places than does FreeBSD, or if your
> BIOS is picky about the partition table.
> 
> A few years ago I started ignoring that message and it's worked for
> me.  I just let sysinstall do what it wants (I believe I started that
> practice when a bug in sysinstall gave me no choice).  I *think* that
> with modern block addressed, i/o buffered disks, on which the
> "physical geometry" is an illusion anyway, the only real problem you
> can run into is different ideas of the total size of the disk, i.e.
> where the last usable block is.  One "geometry" might give you a few
> megabytes more than another geometry, but the difference is at the end
> of the disk.  That isn't going to have any effect on booting (assuming
> the BIOS is willing to start the boot process), and not likely to even
> be a problem when dual booting.

I generally ignore the warning, too.  My only concern this time is that
in a case where the drive is visible to the BIOS, at least if I get it
spectacularly wrong I will find out right away.  Also the question of
whether different BIOSes will assign the same geometry to the drive.

> 
> >
> > I do have one concern.  This drive was purchased more or less to act
> > as an emergency backup of the drive that's already in there.  If ad0
> > ever fails, ad2 drive will have to be put in a new machine whose BIOS
> > recognizes it in order to boot.  If I accept the mystery geometry for
> > the drive today, will I later face a problem where the BIOS disagrees
> > and the drive will be unbootable?
> >
> 
> If my understanding is correct, it is unlikely to cause a problem, but
> it might.  The BIOS routines will still be able to read the first few
> sectors to start the boot process.  If your BIOS is so picky that it
> notices that the partition table claims to use bytes beyond what it
> thinks is the end of the disk (or some other imagined offense), and
> refuses to boot, then you might have a problem.  I've seen such picky
> BIOSes, but not for several years.  I think (hope) that manufacturers
> are learning that quibbling over such things doesn't make the system
> better.  If you were to change the geometry settings of a disk after
> you put a filesystem on it, you would likely trigger other issues, but
> that's not what you're asking.

If that's the only danger, I think I'm okay.  I can edit the partition
tables after the fact.  Highly unrecommended, but it should work.  Or
maybe I should just find a machine whose IDE subsystem is not "suspect".

> Good luck,

Thanks.

-- 
Danny MacMillan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060331223715.GB68298>