Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mel.connect.com.au!munnari.OZ.AU!ihnp4.ucsd.edu!agate!violet.berkeley.edu!jkh
From: jkh@violet.berkeley.edu (Jordan K. Hubbard)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: New Install / Observations & Gripes
Date: 8 Jan 1996 15:50:15 GMT
Organization: University of California, Berkeley
Lines: 148
Message-ID: <4crefn$dtk@agate.berkeley.edu>
References: <DKup49.M1t@bnr.ca> <4cqk44$3gt@agate.berkeley.edu> <4cqogd$97e@blob.best.net>
NNTP-Posting-Host: violet.berkeley.edu
In article <4cqogd$97e@blob.best.net>, Matt Dillon <dillon@best.com> wrote:
> Since we are on the subject, I might as well pass on my praise and gripes
> re: installing the distribution.
Thanks - any and all feedback is genuinely appreciated.
I think the next version of sysinstall that you'll see will
address most, if not all, of the concerns you raise here. As to the
current state of affairs, I'll answer some of your points below:
> Problem #1: Even though I very carefully selected sd1 from sysinstall,
> it still blew away sd0. I think this must be the problem you mentioned
> you fixed regarding blowing away the boot sector on sd0.
Yes, I'm pretty sure this one's fixed.
> Problem #2: F12@#$@##$%#$@%$^^% @##@$ @#$#%^$#% Disk @$%$#$%^ Geometry.
> The problem? First it complains that the disk geometry will not work
> with dos. Fine, I'll change the geomtry... 'G'.. blah blah blah...
> commit, exit sysinstall, re-enter. Second, it complains that the
> disk geometry will not work with dos. In fact, it looks like the
I'm not sure that our geometry-guessing code is going to get better
anytime soon. Was DOS actually on this disk, or were you doing an all-disk
install? It's really weird that you've had problems as all-encompassing
as these since I've installed FreeBSD on dozens of SCSI systems with no
problem at all! I'd like to know what's so different about our setups.
> but the boot program would fail to boot from the FreeBSD partition
> I selected. I tried about 50 different combinations and the only
Geometry again?
> Problem #4: sysinstall gets really confused on the VTY's if you
> run it manually from /stand. I mean REALLY confused... you have
Yeah, I know. My attempt to deal with a console switching problem was
to run the user off of vty2. Works great from a floppy, lousy from
single-user mode! :-( Note that this doesn't happen if you run it
multi-user. I'll fix this.
> Last Gripe on installation #1: There is no way to tell sysinstall to
> install a minimal, and I mean *truely* minimal system. It insists on
> installing a bare minimum that includes an incredible pile of material
> not only in root, but also in /usr.
I'm going to add more `minimal configurations' at the low end.
The router/DNS people have similar gripes.
> It would be nice if you could tell it to JUST install the 5-10 MB
> required to populate /... to the point where you can boot the
> thing in single user boot from the HD and continue the process from
> that. It is *really* annoying to have an install fail multiple
> times and have to reboot from floppy every single time!
This will be possible in the next rev, though in a slightly different
way. Every basic operation (reduced to whichever level of atomic structure
most makes sense for it) is now available as a directly callable
primitive, via the command line. If you want to enter the installer, ask
for a command prompt and then say:
mount -root
copy_self
root_install
reboot
You'll be able to do so. [note: that command syntax is subject to change]
> Problem #1: Sometimes it takes a couple of tries to get the link
> working right.. problems from simple routing issues to DNS not being.
> There is NO way to test link integrity without having sysinstall
> try to connect to an FTP site and watching it fail. This only works
Yes, I know. Link integrity checking is entirely missing from the
low level interface setup and this has always sucked. The next rev
will address this issue.
> don't, it often disconnects your working, running PPP link and asks
> for all that information again, requiring you to dial in and get it
> all working... again. I only had to do that half a dozen times :-(
And the essential "flow" of configuration will also be different. Fall-back
on failure will not be so severe, and when you want to manually fall back
a given number of steps ("oops, I actually screwed that up 3 screens ago")
you can also easily do so using a visual display of where you've been
and can back up to (there will basically be an editor screen you can
invoke at any time to edit/navigate the "stacked event queue" you have
trailing behind you between major commit points).
> Problem #2: So you get a connection and you try to install a minimal
> dist. This is about 5 hours on a 28.8 modem. If ANY download dies in
> the middle, you have no choice but to START COMPLETELY OVER FROM
> SCRATCH!!! You are 3 hours into the install and BANG, it dies... guess
The FTP error recovery was really non-existant. Starting in the next
rev I'm going to a somewhat more robust state machine that should deal
with more of the "between the cracks" states that are actually recoverable.
> Problem #3: It is not possible to cancel an operation due to a
> routing or destination failure or modem disconnection. If you hit
> cancel, sysinstall reboots the machine!!!! E-Gad! We really, really,
> really need a 'retry this operation' mechaism.
See my remarks about the "worm trail" editor. The concept of a `retry' will
be very flexible.
> Problem #4: The minimal installation would finish creating a
> bootable, working root disk until multiple HOURS into the install.
I'm not sure I'm going to be able to do a whole lot to speed it up over V.24
links :-)
> * Have sysinstall not only warn you about disk geometries, but also
> give you a 'default' geometry that actually works with DOS and,
> especially, warn you if the root partition is unbootable due to
> being larger then cylinder 1024.
It's just picking that `geometry that actually works' that seems to be so
damn hard. Care to have a look at /usr/src/release/libdisk for us? Perhaps
you can succeed where we failed.. :-) Apparently, if we had access to
the BIOS information it would be easier, but we don't currently have such
mechanisms in place.
> be to make a fully single-user-mode bootable root disk. No /usr,
> just /, and just required programs, and then require that the
> machine be rebooted. The machine would reboot into sysinstall
> from the HD and you would continue your install. This minimal
> install would load up / with perhaps 5 MB of stuff and have
> most of the standard system programs such as ping, ps, rsh, rcp,
> tar, etc... i.e. all of /sbin and most of /bin.
That would sort of mandate two boots instead of one (when it works,
it's really just one reboot and you're up). Hmmmm.. Ugh! Let me
think about it. There are pros and cons.
> * Keep track of what has been installed and don't require that it
> be reinstalled completely from scratch. Preferably on a file by
> file basis. This would make installation over a modem a whole lot
> easier.
Yes, agreed. Better checkpointing definitely needed.
> * Make sysinstall truely disk independant... I want to be able to load
> up sd1 with a fully working distribution so I can move the physical
> disk to another machine and boot from it. Right now, if the disk
> you are installing isn't sd0, you get screwed royally.
Yes, that will be fixed - I promise! :-)
Jordan