new sysinstall

Matthew Dillon dillon at
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
	very easily).

    (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 mailing list