lilo: "not the first disk"

[Robert G. Brown]

On Tue, 8 Sep 1998, Jim Thompson wrote:

> Thanks for the explanation, but I don't think you understand the
> problem.  It's not a problem booting, but a problem using lilo to
> install the boot record.  My system will boot off the SCSI disk just
> fine, even with the IDE drive present.  The BIOS can be told whether to
> boot SCSI-first or IDE-first in a mixed system.
> 
> The problem occurs in running lilo to write the boot record to the SCSI
> drive.  If the IDE disk is enabled, lilo will report "/dev/sda not the
> first disk" when in fact it is.  A workaround, but an inconvenient one,
> is to disable or unplug the IDE disk, then boot into linux.  With the
> IDE drive/controller disabled, lilo will install the boot record without
> complaint.  The IDE drive can then be reenabled, and linux will still
> boot off the SCSI system just fine.
> 
> Lilo seems to assume that if an IDE drive is present, then it *must* be
> the boot drive.

This is not correct.  I've built several systems with both IDE and SCSI
drives and booted off of either one; the real issue is what is found in
the MBR of the drive marked in the BIOS as the primary boot drive, since
this is what the BIOS firmware will load to start the boot process.
This drive could be a floppy, a CD-ROM, an IDE drive, or a SCSI drive --
it doesn't matter.

The problem you encounter PROBABLY has something to do with one of three
things.

 a) The BIOS on your particular motherboard is, uhhm, strange, and
automatically puts IDE drives present (if any) ahead of SCSI drives (if
any) in the boot list.  You "should" still be able to explicitly set the
boot drive to be, e.g. -- D: (the second, SCSI disk) even if C: (the
first, IDE disk) is present in the system.  But maybe not, I dunno.

 b) ALL Intel boot processes have this nasty leftover limit from the
very earliest days of DOS/IBM PC's.  It was unfortunately assumed that
10 bits was enough to describe the number of cylinders of any sane hard
disk back in the days when bits (in main memory or on disk) were roughly
4000 times more expensive than they are today.  My first PC hard disk
was 10 MB (1/10 the size of a $100 zip floppy) and cost what, $3000?
Can't remember exactly.  It might have had 60 cylinders.  1024 looked
like infinity.  UNFORTUNATELY, this is no longer true; many disks have
far more than 1024 cylinders.  Linux can cope with this (usually) by
remapping the cylinders (dividing by two, for example, until the number
falls into range) but MS products often cannot.  If your disk was
partitioned by MS fdisk, and you are trying to boot a partition
containing the MBR that is larger than 1024 cylinders, lilo will barf
just as fast as WinX because the cylinder limit is really a
firmware-level problem and very difficult to remove.  I think that this
is documented in the lilo howto or man page.  It also doesn't "sound"
like your problem, but I thought you ought to be aware of the
possibility.

 c) You could be screwing up lilo.conf, or the like.  Again, it doesn't
sound like this is likely (you sound like you know what you are doing)
but you never know. Be sure you've thoroughly read the man page, the
howto, and heck, grab the lilo sources and read over any documentation
you can find therein.  lilo has a lot of options and most of us (at
least myself) tend to find a combination that works for us and only
change or add one under duress.  Maybe this is duress -- there might be
a little used option or configuration note that can help you out.

Hope this helps.  I think a) is the most likely -- not all BIOS's are as
sane as one would like them to be.  A lot of them, I think, are still
strongly influenced by their PC origins and not really suitable for a
workstation.  The good news is that if your BIOS/motherboard ARE the
problem, hey, decent motherboards cost less than $100 from lots of
manufacturers.  Throw your old one away (salvaging CPU and memory) and
start over -- the money is almost certainly less valuable than the time
you've already wasted messing with the problem.

   rgb

Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu




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