*BSD News Article 44478


Return to BSD News archive

#! rnews 11485 sserve.cc.adfa.oz.au
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!news1.digital.com!nntp-hub2.barrnet.net!news3.near.net!paperboy.wellfleet.com!news-feed-1.peachnet.edu!news.duke.edu!news.mathworks.com!news.kei.com!nntp.et.byu.edu!news.provo.novell.com!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: 16 May 1995 21:44:51 GMT
Organization: Utah Valley State College, Orem, Utah
Lines: 237
Message-ID: <3pb6cj$pkd@park.uvsc.edu>
References: <3o4lp2$b2i@nntp1.u.washington.edu> <3orbtt$su9@passion.nosc.mil> <3ottl6$l7@park.uvsc.edu> <3p5ds3$rc1@passion.nosc.mil>
NNTP-Posting-Host: hecate.artisoft.com

I do not typically use IDE drives; some of the items in the
following posting will probably provide you with keen insight as
to why.  Hopefully, the following information will be useful in
resolving your problem.  Without access to the box itself and to
software that lives in a CS lab about 2000 miles north of my
present location, I can't give you a quick fix.


lima@io.nosc.mil (jd lima) wrote:
] : 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).
] 
] Ok, Terry.  I'll try the latest SNAP -- thanks for all the really
] GOOD observations you made.  I have gone over the events leading
] to my latest problem, and I'm no longer sure  that even the latest
] SNAP will have any effect:

I guess Tim Smith would have us believe that this was sarcasm on
your part, since you omitted most of the actual information from
my other article in followup.  I'm going to assume that it's not,
since it's pretty much general knowledge that the new FreeBSD
disk slice code deals with a number of issues that the 2.0 code
did not, one of them being large IDE drives (like it says in the
release notes and the READ.ME file).

So I'll carry on with an attempt to answer the rest of the issues
raised by this post.

] [snip]
] : ] 	- 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.
] 
] This is the crucial point.  what I now recall happened was that I
] tried to just proceed with the BSD installation off the second drive.
] Up to this point I had the installation going to my second drive,
] than it had that problem with finding the root partition.  I switched
] I/O cards, rebooted, and NOW THAT I RECALL, I had the simple boot
] manager ON BOTH drives, so I saw something like this at bootup:

OK.  This is typically a bad thing.  The POST boot code in the
BIOS that loads the boot track off the first bootable device in
the interrupt chain (0x00 [drive A] if available, 0x80 [drive C]
if available, then hang with "no bootable device") leaves the
device in the DL register.  The boot code know what device to go
to by looking at the DL value and using it in BIOS calls to load
the OS specific boot track from the partition selected.  This
register is corrupted when the first copy of the boot manager is
loaded, and might be corrupted on top of that by BIOS bugs.  Two
boot managers is therefore a bad thing in a general sense, unless
you are very, very sure about how your BIOS works.

Bouncing back and forth between drives is probably not going to
work too well, although I don't think it should result in the
symptoms you describe (below) by and of itself.  Something else
is therefore wrong.

] 	F1	dos
] 	F3	FreeBSD
] 	F5	disk2
] 
] Now I had made that FreeBSD partition on the 1st drive (after cylinder
] 1024) intending to use it as '/extra' or something, so I chose F5,
] which led to the following:
] 	F1	dos
] 	F3	FreeBSD
] 	F5	disk1
] 
] Choosing F3 resulted in my second hard drive SPINNING DOWN.  That's
] right, it actually shutdown as soon as I hit F3.  I had to reboot my
] machine, and EVER SINCE, MY FREEBSD BOOT FLOPPY will not boot, like
] I described before:
] : ] 	 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.

OK, what you did was execute random code at the start of the BSD
partition without the boot code; the '/extra' partition shouldn't
be on your boot menu (neither should the 'dos' on the second drive
if it wasn't formatted /s/v to make it bootable).  It's possible
that one or both drives got written when you did this.  The best
way to recover from this (if it's possible to do so) is to boot
Poul's "BSD fixit floppy".  Since it loads entirely into memory
as a RAMdisk, you will need to have at least 8M on your system
for this to work.  The only other alternative is reinstallation.


Unfortunately there are several possible additional complications
present which are going to result in this being a bitch to figure
out:

a)	New IDE card.  The New IDE card isn't necessarily better;
	for instance, it might not have the buffer chips it needs
	to have between the card and the bus.  This is a potential
	issue for BSD that DOs avoids by having slow-as-mud drivers.

b)	The card shouldn't have been the issue.  If one drive was
	operation with the first card, a second drive wshould be
	as well.  IDE cards in general aren't that smart, mostly
	they are bus converters, since IDE is rather a lot like
	an extended ISA bus.

c)	There are known interactions between certain IDE drive
	types, especially Wester Digital Caviar drives, and it's
	possible that swapping the master/slave relationship will
	fix the problem.  Some drives will not work well no matter
	what.

d)	Your CMOS settings might have been changed by the random
	opcode execution.

] I confirmed that I see '|', '/', '-', then bam! reboot.  I replace
] new I/O card with old -- same prob.  I booted *another* pc with the
] floppy, and it works as it always did before (correctly).  I tried
] to boot from and older NetBSD 1.0 boot floppy which used to work --
] it does the same reboot thing pretty much identically.
] 
] Other things that I tried that didn't work:
] 	- *entirely* reformatted EVERYTHING (both drives,
] 	  repartitioned...)

This is bad.  Without exact information, it's really going to be
difficult to undo this one.

You see, it's flat out impossible from a hardware perspective
for DOS to access a > 500M IDE hard drive.  The *only* alternative
is to screw around with the INT 13 interface used by the INT 21
calls to do the raw disk I/O.  To do this, most > 500M disks come
preinitialized with an OnTrack 6.x MBR (Master Boot Record) or
equivalent.  What this does is load, hook the interrupts, and hide
the front of the disk where it lives by subtracting it out.  For
the OnTrack stuff, it's 64 sectors.  Subsequent INT 13 and INT 21
accesses are translated into absolute secotr references, just like
UNIX/BSD/Linux use instead of C/H/S references.

What you have probably done by reformatting the drive is destroyed
this information (at least).  That's why there's a rumor about
reformatting destroying IDE drives.

If you can remember if you booted off the drive to do the format
or if you booted off a floppy, that'd be helpful.  If you booted
off a floppy, you will probably need the OnTrack stuff to recover.

The same is true if you did an 'fdisk/mbr' to the drive after you
booted from a floppy; either one will overwrite the OnTrack boot
code, which contained a single partition entry in it's false
partition table to make the BIOS happy, and your real partition
table was following the hidden area.

] 	- pulled *every* card out of my machine except video
] 	  and I/O cards.

Harmless; good diagnostic technique.

] 	- disconnected every (external) cable from my machine
] 	  except power and video.

Harmless; good diagnostic technique.

] 	- made each drive the *only* drive, each in turn.

OK, we're back to bad here; the drives are coupled in a master/slave
relationship because of the way interrupt chaining works for the
relativel simple controller electronics.  It's quite possible that
the problems you are having now are the result of jumper settings
you made/didn't make at this stage.  IFF you disn't blow the MBR on
a > 500M drive, then you have a chance.

One issue on mixing > 500M and less than 500M drives on the same
box is that the > 500M drive has to be first to let the OnTrack
code get loaded before attempts to access the drive.  If they are
bot > 500M, then the same code must be on both drives, since the
OnTrack code *can* handle this IFF it detects the same single
(OnTrack specific) partition ID on both drives.

Since the 'master' is generally 'C' and the 'slave' 'D', a mixed
configuration *requires* that the C drive be the big drive.

> 	- used DOS 'fdisk /mbr' to wipe boot manager of both drives.

This could be bad if you booted from floppy to do this instead of
from HD, since you will have killed the OnTrack code rather than
the boot manager.

] 	- installed OS-BS (provided on FBSD2.0 CD-ROM) on 1st drive
] 	  only.
] 
] I can't think of what else to do -- except try the latest SNAP, and 
] right now I don't think that's going to do much, but what else can I
] try?.  I can use my system just fine -- as long as it has nothing to
] do with BSD.  What's going on here?  

I think you are probably right that the latest snap wouldn't help
you any (unless you wanted to go for a "pure BSD" install), since
you will be screwed on DOS until you replace the OnTrack code
(which I think has been blown away from your description of the
steps).

] : 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.

With the additional information provided, I suggest you start by
chacking your CMOS settings and card configurations for correctness,
then get a copy of OnTrack utilities for IDE/EIDE drives, version
6.0 or above.  Most dealers that put together systems will have a
copy of this lying around, even if they don't know about the INT 13
redirector or other issues in the more modern code.

From there, you should be able to get back to an operational state
for DOS, and taking care on master/slave settings on the drives
(all major drive manufacturers have voice responder 1-800 support
for jumper settings), you should be OK.  If you have a WD Cavier
drive, you may need to get a firmware upgrade (it's a software
applicable fix for the drive) from WD so it will work with other
manufacturers IDE drives in a master/slave relationship.

Unfortunately, when something stops working you should stop right
there and avoid "try this/try that" soloutions with potentially
fatal consequences (like replacing the MBR or reformatting the
drive, etc.).

Hope this helps.  If you need more detail than that, you are going
to have to fly out here with the box under your arm, or you are
going to have to take it to your dealer.


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