Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 02 Dec 1999 19:54:45 -0800
From:      Mike Smith <msmith@freebsd.org>
To:        mjacob@feral.com
Cc:        current@FreeBSD.ORG
Subject:   Re: FOLLOWUP: Re: HEADS-UP: bdevs have been assimilated. 
Message-ID:  <199912030354.TAA04033@mass.cdrom.com>
In-Reply-To: Your message of "Thu, 02 Dec 1999 19:16:18 PST." <Pine.BSF.4.05.9912021904090.6279-100000@semuta.feral.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
> 
> Sorry- maybe more of an edge case. It really has to do with 'ad' support
> seemingly vanishing from the alpha. Or, rather, it's hard to say exactly
> what has happened:
> 
> 
> Mounting root from ufs:/dev/rad0a
> no such device 'rad'

You never mount 'r' devices.  That should be '/dev/ad0a', and you can 
override the default with either:

 set vfs.root.mountfrom="ufs:/dev/ad0a"

in the loader at the 'ok' prompt, or by entering 'ufs:/dev/ad0a' at the 
emergency recovery prompt that you get after the error messages you've 
quoted above.

> But then, there's an older system on da0:
> 
> Mounting root from ufs:da0a
> WARNING: clock gained 14 days -- CHECK AND RESET THE DATE!
> swapon: adding /dev/da0b as swap device
> 
> which makes it less of a bad bad but still very very annoying. It's hard
> to find out what's going on because even though there is some vague
> attempts to stop the loader (whereupon you get a phony 'ok' prompt), no
> passing of variables set there occurs (so no 'bootverbose').

The variable's name is boot_verbose, but the Alpha has never supported it
(a combination of oversight and overbusiness on both my part and Doug's). 
You'll find that 'boot -v' and 'load kernel -v' will achieve the desired 
results in the meantime, and I'll try to get it working "right" soon now 
that I have a 'real' alpha to work on.

I'm also curious as to what's "phony" about the 'ok' prompt?  Is it just 
that things aren't 'ok'?  8)

> So, it's conceivable that this is just edge case alpha breakage. With < 2
> weeks to feature freeze for 4.0 it is very hard for some of us who attempt
> to make sure things we deliver actually work on both platforms if the
> second platform is broken. I'm plenty pissed off, but, c'est la vie...

So we should, like, feature freeze before we feature freeze?  That's not 
so good.  I don't mean to be insulting or anything, but so far most of 
your problems appear to be pilot error.  If you take them out of the 
picture, it's not _really_ that bad. 8)
-- 
\\ Give a man a fish, and you feed him for a day. \\  Mike Smith
\\ Tell him he should learn how to fish himself,  \\  msmith@freebsd.org
\\ and he'll hate you for a lifetime.             \\  msmith@cdrom.com




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




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