*BSD News Article 43804


Return to BSD News archive

Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!news.mtu.edu!sol.ctr.columbia.edu!howland.reston.ans.net!gatech!news.mathworks.com!news.kei.com!nntp.et.byu.edu!news.byu.edu!hamblin.math.byu.edu!park.uvsc.edu!usenet
From: Terry Lambert <terry@cs.weber.edu>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Cannot mount root during install?
Date: 11 May 1995 20:56:06 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 92
Message-ID: <3ottl6$l7@park.uvsc.edu>
References: <3o4lp2$b2i@nntp1.u.washington.edu> <3orbtt$su9@passion.nosc.mil>
NNTP-Posting-Host: hecate.artisoft.com

lima <lima> wrote:
] tzs@u.washington.edu (Tim Smith) wrote:
] >I'm having some problems trying to install FreeBSD 2.0.  I'm trying to
] >install on my second IDE drive.  I'm deviating slightly from the

[ ... ]

] I had *exactly* the same problem.  The only thing I can think of now is
] that perhaps FreeBSD "will install perfectly fine on a second drive" as
] long as it's a SCSI drive -- unfortunately I have two IDE drives:

One major point: Have you both tried the most recent snap?  It's
impossible to magically make fixed bits appear on a CDROM.  Even
if Jordan had a laser and your missle coordinates, I think
atmospheric distortion would foil him (Jordan can't afford to buy
adaptive optics).

] 	- put each drive on thier own primary IDE channel
] 	 (per instructions for my el cheap-o VLB 4HDD controller card)
] 	 resulting in BSD "seeing" the drives correctly, but same
] 	 cannot mount root problem AND making my other OSs non-bootable.

This should not have resulted in the other OS's being non-bootable,
unless they were on the second drive, and even then, it's a problem
with your boot manager, not the OS's themselves.

] 	- tried to install to BSD slice on first HD -- this slice begins
] 	 after primary DOS partition (504MB).  When it went to reboot, the
] 	 boot manager could not boot off of that partition presumably because
] 	 it began beyond cylinder 1024 (my idea).  I really didn't want to
] 	 repartition the first slice, and I had doubts about my controller
] 	 card, so...

This is correct.  BIOS is stupid, or rather the INT 21 interface
is stupid, in that it uses C/H/S values and therefore can not
address as amny bits as you want it to.

The 500M limit on the IDE is a result of it basically being the AT
bus on a cable; support for better than 500M takes heroic measures
outside the scope of a BIOS based master boot record (which is the
only kind you have available to you).  The only alternative is to
make sure that the BSD partition, the disklabel, the BSD boot code,
and the 'a' slice are all under the bIOS limit.

] 	- bought a *new* VLB I/O Controller.  This one has on-board BIOS, and
] 	 allows driver-less access to >528MB drives.  I thought, "this is just
] 	 what I need."  NOW, DOS fdisk sees both drives in their entirety
] 	 just fine.  BUT...FreeBSD boot floppy will not even proceed with the
] 	 kernel startup -- it just goes right into a system reboot immediatly
] 	 upon system probe sequence.  I only see that '|' -> '/' -> '-' thing
] 	 change once or twice, then...reboot.
] 	 I/O Controller is:
] 		SIDE jr. Pro (jumperless)
] 		Dual IDE Channel (Mode 3/4/5), ANSI ATA 3.1 compatible
] 		2 16550AF UARTS, NS16C550 compatible
] 		ECP/EPP/SPP/Bi-Directional, IEEE 1284 compliant
] 		2.88MB FDC
] 		BIOS version 2.0B 01/95

I can't speak for the exact failure of FreeBSD 2.0; like I said,
it isn't current, and it's not something for which there would be
a workaround without replacing your boot disks.

The "new" controller's capability to address better than 500M
comes from it providing an alternat BIOS interface, that mostly
no software uses to do its I/O (because if it did it couldn't
run on old boxes: the same reason DOS for the 386 wasn't protected
mode, flat address space).  Even if the controller manufacturer
provided you with a replacement master boot record, unless it
hacked the INT 13 and INT 21 interfaces (like the Adaptec BIOS
does) to translate it for logical block addressing (a complex
way of saying UNIX-style absolute sector offsets), you are still
screwed.  If it *did* do the hack for you (OnTrack's disk manager
software has replacement MBR code that will), you still are not
going to be happy, because you won be able to use a replacement
boot manager (like the one in FreeBSD, Linux, or OS/2) because
it doesn't understand LBA (and if it did, it wouldn't run on
older hardware, either).  Finally, assuming you installed their
boot code, and you used fdisk to make partitions active instead
of using a boot manager of some kind, the boot tracks of the
OS's themselves still wouldn't know about using LBA BIOS calls
and you'd still be broken over 500M.

You should really make sure that the bootable code is below 500M
on the drive for the near future at least.


                                        Terry Lambert
                                        terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.