dillon at apollo.backplane.com
Sat Aug 30 00:01:14 PDT 2003
Hmm. Well, this is what I would recommend... break the problem down into
a number of incremental pieces which allows the problem to be attacked
from several angles at once.
(1) Strip out the current sysinstall and convert it to be the 'stage 1'
installer only. It would be responsible for fdisk, basic
partitioning ("/", swap, and "/usr" only), and installing the base
system onto the hard drive.
(2) Create an infrastructure for the 'stage 2' install which is run
from the HD on reboot.
(3) Allow the infrastructure to be specified at 'make release' time
or concactenated onto the CD using 'growisofs' or something similar
(remember, CD-R's can be multi-sessioned and our iso9660 filesystem
already supports that, so we can concactenate files onto the CD
(4) The various people arguing can then start working up examples of
their own stage-2 infrastructures without intfering with the basic
work that needs to be done to 'make release' :-)
Each stage-2 infrastructure would be a subdirectory in
/usr/src/release/installer. e.g. /usr/src/release/installer/<BLAH>.
The stage-2 infrastructure would be responsible for whatever
sophistication the author deems necessary. For example, I can see
a number of potential infrastructures here including one that does a
fully automated stage-2 install by retrieving data over the LAN. The
hand-off to stage-2 should be simple enough that any sysadmin can write
his own stage-2 for specialized purposes... basically run a program or
a script. The stage-2 infrastructure would be responsible for removing
itself from the boot sequence when it (or the sysop) no longer wants the
system to boot into it.
More information about the Kernel