[woody discussion] 3 stage install
I had some thoughts regarding the posible workings of the next boot
floppies.
I havent yet convinced myself its needed, but i ill let my thoughts fly
anyway.
MAIN POINTS
1. For the user, the installation starts when they chooses to install
debian.
Instructions are their first need, this leads them directly or
indirectly to boot-floppies which are their second need. (i guess this
doesnt need to be stated)
2. For boot floppies the installation process begins from there previous
OS.
Maybe the install shouldnt be so quick to abandon the original OS,
there may be valuable information we can gather before we jump into our
realm.
Hardware information is the obvious need at the initial stages, the
less hardware the installer has to cater for the simpler it is.
Initial hardware information cannot be considered a necessity as there
may be no initial OS.
This would require OS specific modules, wether its worth creating these
"foreign" modules would depend on wether the infomation they can gather
(and the timing of that information) gives a clear advantage over doing
it the traditional linux way.
3. Space is a primary limitation on the quality of the installer.
By using available space on the local storage medium using a loopback
device (except NFS install) we can most likely have access to as much
space as we need.
Having much space available for the installation could make an X (GTK)
based install a feasible option.
4. Users shouldnt have to giveup there previous OS in order to try
debian.
Its probably a big ask to try and get new users to abandon there
current OS in which they are familiar, with this gnu linux thing, of
which they know nothing.
Debian could coexist with there native OS without any repartitioning,
from the host OS's point a view a loopback device is just another file.
Windows users could launch debian like any other windows apps using
loadlin.exe, they just have to reboot to get back to windows, rebooting
is something windows users are comfortable with, repartitioning is
something that many windows users wouldnt be confortable with.
Questions
1. Are there loadlin equivalents for other OS's ?
2. Can you dual boot under all architectures ?
HOW CAN THE ABOVE BE ACHIEVED ?
STAGE 1 (mini distro)
GOALS
1. Establish a presence on the local storage media.
2. Act as a rescue/recovery disk.
3. Gather any hardware information posible.
3. Keep a log of relevent information for future use.
4. Customised boot-disk.
5. No user interaction during actual install (user information used to
generate custom boot disk initially)
INSTALLATION STEPS
1. Detect all local mass-storage devices and the filesystems contained
on them.
2. Create a root filesystem on a local storage device and unpack modules
from floppy(s).
3. Modify/Install relevent boot loader to (optionally?) use the new root
filesystem.
4a. If root filesystem on loopback device : Goto Stage 2
(non-destructive install)
4b. If root filesystem on its own partition : Goto Stage 3 (traditional
install)
THE STAGE1 INSTALLER
1. If there is an OS specific module for the original OS then it can
generate some defualt values for the next step.
2. To make the boot floppy the user fills in a form (a wizard?) with
some pre generate defaults. Questions aimed at determining
i) Target architecture (default current)
ii) Required kernel modules e.g. drivers for installed hardware (this
could cut down required size heaps)
iii) Disable/Enable stage 2
iv) Image size, target 1.2, 1.44, 2.88, or other removable media.
1.44MB formatted floppies can pretty safely hold 1.77MB, let the the
user decide if they want one higher format floppy or 2 normal ones if
they need the space.
v) Extra modules to be placed on the floppy, this increases it value as
a rescue/recovery disk and its versatility.
3a. Use a pre-built image that matches requirements.
3b. Generate a custom image specific for the users needs based on
individual pre generated modules.
STAGE 2 (loop-install)
GOALS
1. Present an attractive user friendly install GUI.
2. Dependent on host OS.
3. Expandable to a normal debian system using regular tools whilst
remaining in stage2.
4. Can convert to stage3 maintainging integrety of Debian files.*
5. Non-destructive any minimumly intrusive to host OS.*
6. Dont push users to stage3, wait till they are ready.
* This may not always be possible
If the host OS is using FAT or ext2 then thats ok, we can resize those
parititions
If stage2 resides on a filesystem that cannot be resized then it would
be destructive to the host OS.
If stage2 resides on a filesystem that cannot be resized and it is on
the only partition on the only drive then the debian instalation couldnt
continue to stage3 without external backing up. So you would have to go
back to stage 1 then straight to stage3. You could backup a list of
installed packages, and there configuration, and run cruft to check for
user generated files (im not sure how well this would work)
STAGE 3 (full distro)
GOALS
1. Debian exists independently.
2. Get here via stage2 or direct from stage1
3. Support for specialised install requirements
4. Better support for automated install than stage2
The difference between this stage2 and stage3 installer is the UI and
partitioning.
CRITICISMS
1. Too complex.
If the complexity can be broken down into managable pieces it isnt a
problem
2. Stage 2 could be eliminated and a GTK class UI and a loop install
option could be encompased in the stage3 installer, it would achive the
same thing.
True, but this would add a lot of complexity to situations where a nice
GUI and loop install arent needed.
At stage1 we can determine wether stage2 is feasible (or wanted), if it
isnt the stage1 to stage2 installer isnt needed. The stage1-stage3
installer would be quite small in comparison.
It would be easier to support different levels of user ability,
stage2==newbie stage. And stage1-stage3 could try and encompase
automated isntall and more advanced features that may not be available
if you go the long way, i.e. stage1-2-3
As i say, im not totally convinced myself, it could be a hassle to get
X-windows organised, i think it could be done in a platform independent
way using the framebuffer device ggi and the X-ggi server.
As i see it, the more user friendly the install is the more complex the
install program becomes, and there are lots more considerations required
to keep computer illiterate people happy (if we decide to try). Breaking
it down is a good way to simplify things.
It would be good to have a non destructive install.
Any comments... or have i scared you all off by now ?
Thanks
Glenn McGrath
Reply to: