Date: Wed, 11 Oct 2000 19:22:13 -0700 (PDT) From: Matthew Jacob <mjacob@feral.com> To: Terry Lambert <tlambert@primenet.com> Cc: Andrew Gallatin <gallatin@cs.duke.edu>, Pawel Nogas <pnogas@amu.edu.pl>, freebsd-alpha@FreeBSD.ORG Subject: Re: Problem with FreeBSD on AlphaStation 255/233 Message-ID: <Pine.BSF.4.21.0010111908510.52023-100000@beppo.feral.com> In-Reply-To: <200010120144.SAA12166@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > How is this possible, using the system tools, if Alpha cannot boot > > > from it? Are they broken? > > > > SRM doesn't grok MSDOS partitions, and SRM is the only supported boot montor. > > So doing closure on this: > > IF the Alpha distribution can create something that can't > be booted by the only supported boot monitor > THEN yes, the tools are broken. Yes, I've maintained they've been lacking for a while. The other issue here is that 'dangerously dedicated' for Alpha and 'dangerously dedicated' for i386 are not interoperable for FreeBSD- despite the fact that the disklabel program says the types and sizes of partititions are identical. I fail to see how two little endian machines that see a disk (from the point of view of a user application) can't make a FFS filesystem that can be read by the other guy. There's been a lot of talk back and forth about this and yit-yat about slice code and on and on and on with a lot of opinions being expressed and not much being done. I sure haven't taken the time to delve into the problem- being of the opinion that the original code designers ought to shoot their own mutt- but this are sure could have somebody with brains and multiplatform experience looking into it. I shudder to think what a Sparc port would do. *groan* > > > > - You accidentally managed to install with i386 and not alpha > > > > distribution sets --- there are separate CDs for x86 and alpha > > > > > > How is this possible? Same question: is the install process broken, > > > in that it actually permits this to happen, ever? > > > > You're talking to the wrong folks on this one. Take it up with JKH && Mike > > Smith.... > > Identifying what needs to be done is half the battle. I have an > old, slow Alpha box off of OnSale, which I may be willing to get > a new scratch disk for, to work on the problem, if the soloution > is known, just not yet implemented. > > I'm burning my think-cycles on other stuff right now, but this > seems to be reducible to a "strong back, weak mind" coding problem, > where the fixer won't really have to think to much about the fix, > if it's know why this is possible. > > Worst case, we poop a file named "arch-ok" into all the tarballs, > and put in the architectures it can be used on, one per line. Oh, well, if you're going to go this far, one might as well use RPMs or SVr4 packages which do all this dependency crap for one. FWIW, my opinion is that the install tools are both under and overengineered. The (older) NetBSD && OpenBSD installers have it right in that installation is simply partitionable into: select the root disk of all available disks label it (as *appropriate* for the platform involved)- with minimal choices as to layout set up initial networking extract the right tarball set (no choices as to content) Disks are cheap enough to make fooling around pointless and annoying and very error prone w/o a helluva lot more engineering than has been devoted so far. A simple "How much swap? Do you prefer one root filesystem or a separate /, /usr and /var? Which disk?" should be it. Similarily, Slackware and the earlier RedHat distributions also were fine things because they more or less followed this approach. Everyone seems to then fall into "We gotta have a fancy GUI installer". I'm sure it looks good to reviewers and some folks- but if it makes it a major gamble to install reasonable h/w, what's the point? -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010111908510.52023-100000>