HF: Hubert Feyrer <feyrer@rfhs8012.fh-regensburg.de>

HF>i386:	configuring X
HF>pmax:	note X11R5 X server (refers to /usr/X11R6/bin/README.pmax)
HF>I've got currently no idea on where to accomodate that. Ideas?

sysinst already handles extracting the X11 binary tarballs on some arch's.
What remains could be rolled into your post-install step:

    - add /usr/X11R6.3/bin to default PATH (how best to do this ??)
    - add /usr/X11R6.3/lib to ld.so.config
    - try to figure out which Xserver to link as "X"
    - provide sample "sane" /etc/XF86Config file they can replace w/ XF86Setup

For the latter two, I want a reliable way of querying the device tree or
dmesg output or SOMETHING. I see no reason why we cannot eventually auto-
detect every PCI video board and provide a sane setup for it. Of course it
will rely on a "living" database of board personalities, but I think that
is a worthy project in its own right, and useful to others.

SB: Simon Burge <simonb@telstra.com.au>

SB> I believe you should be able to configure your system before the
SB> reboot.  This would mean either that sysinst does all the work, or that
SB> a separate program called by sysinst before the reboot would do the
SB> /etc/rc.conf work (maybe a /sbin/sysconf or similar).  Having either
SB> sysinst or a separate program that can do this at any time the system
SB> needs reconfiguration needs should also be a goal too.

Agreed. It is an interesting question just how much of this should be done
by sysinst versus normal administrative utilities. The natural conflict is
that with sysinst we want to run in a minimal-resource environment,
whereas with the admin-utils there is a constant temptation to build in
assumptions that a full system tree exists, the GUI is available, etc.

SB> I've not been a great user of the package system yet, but is it possible
SB> to load binary packages into a new system mounted at (say) /mnt, and all
SB> the right "bits" get updated?  If this is the case, then even packages
SB> could be loading in the one installation step.

Yes, if this does not already work then I am prepared to do what can be done
to fix it. I want sysinst to help me size my partitions based on what I plan
to install, and how much extra 'headroom' I say I want to have on each disk.

SB> Taking this another step (as has been mentioned somewhere that I can't
SB> remember), you could have all of this ("this" being system config info,
SB> which packages to load, anything else we can think of) driven by some
SB> sort of config file (whether it be NIS, bind/hesiod, dhcp?, something
SB> tftp/ftp'd, etc) means that you can for example start sysinst on each
SB> machine in a lab, and come back however long later and have all the
SB> machines at the login prompt.

Scenarios like this are why I consider it important to develop "pre-install"
intelligence within sysinst, so that when you do walk back into the lab,
there aren't five machines sitting there with overflowed root partitions.

Ultimately I think sysinst should allow you to prepare a complete filesystem
for another architecture so that the other machine can run diskless from you.
We have lots of people working on new ports who have to do this all the time,
and I think it should be integrated into sysinst, so we can use the same
interface whether we are installing or "cross-installing".

HF: Hubert Feyrer <feyrer@rfhs8012.fh-regensburg.de>

HF> If there's such a program (sysconf - nice name :) then it's easily
HF> possible to do the configuration before the first reboot. As we don't have
HF> this program yet and I doubt it will pop up soon, other measures have to
HF> be taken. I.e. manual configuration for now. And for that, having the
HF> system in a known state is necessary, which again we only have after the
HF> first reboot when root's == /. 

Don't bet any money on 'sysconf' not showing up soon -- I will be posting to
tech-install soon now that I have a spare PC set up. However your efforts to
improve the installation notes are much appreciated -- it helps users grok
the boot process better, and it provides an excellent 'to do' list for anyone
working on 'sysconf'.

HF> Anyways, IMHO doing this reboot shouldn't hurt too much - or am I missing
HF> something? (I know of some other OS that boots ~3 times during it's
HF> installation until it's done)

This is a very valid observation. I think the biggest problem with M$ reboots
is that you don't know how many there are going to be; you can't even assume
one reboot per system change, because sometimes it "discovers" new stuff on
the next reboot and decides you have to reboot again. Try installing win95
with a serial mouse, trade it to someone for a PS/2 mouse, and then see how
many times win95 reboots while discovering new hardware.

It has occurred to me that perhaps we could kill a few birds with the same
stone by developing tuned install floppies for each major class of install
media, to handle small-memory machines better and also to free up space on
the install floppies for more pre- and post- install intelligence.

One evil idea I just had is to make install floppies that serve as diskless
boot roms. This would avoid the resource crunch altogether, and all it takes
is a friend with a NetBSD system and "pkg_add install-server-1.0.tgz". Other
possibilities would be: mount a parallel port ZIP drive (for installing in
real battlefield conditions); NFS mount over a USB "buddy net" (don't laugh,
point your browser at http://www.belkin.com/cgi-bin/catalog.pl?request=7008);
and, for the truly masochistic, NFS mount over PPP on COM1 !!

okay, maybe not that last one. we do have some scruples here.

Todd Whitesel
toddpw @ best.com