sounds like you have hd jumpered as master on second
 ata controler but have HD on wrong ribbon nipple to match master
jumper.

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Danny
MacMillan
Sent: Friday, March 31, 2006 5:37 PM
To: Bob Johnson
Cc: Danny MacMillan; [EMAIL PROTECTED];
freebsd-questions@freebsd.org
Subject: Re: Can FreeBSD safely use a (un-booted from) drive that is
invisible to the BIOS?


On Fri, Mar 31, 2006 at 03:48:57PM -0500, Bob Johnson wrote:
> On 3/31/06, Danny MacMillan <[EMAIL PROTECTED]> 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
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"

_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to