new sysinstall

Robert Garrett rg70 at
Sat Aug 30 04:14:28 PDT 2003

0$269$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <slrnbkvm7b.oig.weingart at xxxxxxxxxxxxxxxxxxxxxxx> <20030829184829.2fedd129.cpressey at xxxxxxxxxxxxxxx> <200308300659.h7U6xOM0059135 at xxxxxxxxxxxxxxxxxxxx>
User-Agent: KNode/0.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 58
X-Trace: 1062242077 269
Xref: dragonfly.kernel:742

Matthew Dillon wrote:

>     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.
> -Matt
Basically this is what I'm working on currently. the first step was to
get the existing code working. 

next is to seperate the disk partition/format utility 
write somthing to be used as init that calls the disk utility
then copies the neccessary parts of the system to the newly formatted,
then it would install an init, that is the second stage of the 
installation proccess. 
after system configuration is complete it would then replace itself as 
being init with the real one.

Robert Garrett

P.S. if theres no objections in  a couple of days i'm going to create
a release2 directory for the modified scripts.

More information about the Kernel mailing list