Comments, another installer project
Hi everybody,
As I already mentioned to some people (but not on this list) I have the
duty to write a Debian installer here at innominate AG in Berlin (Germany).
Therefore I am following the discussion of the new Debian installer and
I had the hope that I could just use it :)
Of course I don't expect it to be ready in time (since I have to complete
my work in this month) but I think I can make some mistakes so they are
avoided when implementing the new Debian installer.
The goal for my project is that is to make it possible to do a manual install
once (which may even be more complicated than our current installer) and
store all the answers from the user onto some media and do automatic
installations with that information afterwards. This has to work for potato
and whatever packages are installed without changes to the packages allowed.
I am currently working on the design of that beast and will make it available
to the net if I am allowed to (I expect I am). Of course my original plan
was to eventually make it the official Debian installer some day.
I hope it is okay to write some of my ideas up here. I expect that it will
not bring me many friends that I want to do some things different but that's
life :(
Sweet dreams (off-topic)
------------------------
First of all my final goal (which is my personal goal and not that of
innominate) is to have a single Debian package which allows you to
construct boot disks/boot cdrom's and perhaps the official cd images
in the distant future.
It would be an GTK-application which comes with the installer code. To make
a bootable CD you would need to
- configure apt (mainly sources.list)
- select one of the supported loaders
- select a kernel package (from apt's sources or from disk)
- select the installer modules to be put on the disk
- select the packages to put on the disk and perhaps additional apt sources
Result would be either a floppy image or an ISO image to burn on CD.
I am sure it will take a while to do something like that. The installer
must be ready before. So I think we should not discuss something like
that now.
The installer
-------------
We seem to have nearly the same goals for the installer. They are
- modular design
- support for different user interfaces
- multi lingual
- kickstart installation
Also we seem to agree that the "main" program of the installer should
control the installation of the individual modules.
Installation steps
..................
What I do not like in your proposal is the idea to use packages for the
different steps of the installation and for ordering the steps. Perhaps
it's just my misunderstanding - I can't really make sense of the use of
udpkg.
If it was only used to overcome base.tgz (which I don't really like) I would
agree that it is a good think. Make the installer install all packages
which have Essential: yes or something. Implementing that looks kind of
complicated for me since the installer needs to seek the packages to install
then. For simplicity I would like to stay with the current scheme of base.tgz.
Now the install steps are Debian packages which are installed using udpkg
into the ramdisk (or where? We can't install the partitioning step into
the harddisk for obvious reasons). Or did I get that wrong and we are
using udpkg to install them into the install image? That would be something
I can agree with and which just occurred to me when I was writing this.
The role of debconf
...................
I do not feel quite well with debconf as installation frontend. First of
all it is currently one part together with the database. I did not see
the problem when it was new but after reading a few scripts which use
it (in base-config for example) it looks quite crazy because it is
sometimes only used as dialog-replacement. I think it should be separated
from the DB.
If we do that the solution to use debconf is technically sound and might
save a lot of effort. Still people will complain that the Debian
installation is unfriendly compared to others. And I have to agree.
So I would like to have a database in the installer (which can be the same
as used for debconf) and the possibility to use the debconf frontend or
any other frontend. But I don't want to go deeper here since that can be
change that later just as well.
Hardware detection
..................
I do not have much knowledge in this area and for my own project it is not
really needed since we know exactly what hardware will be in there. But
I would like to say that I would like the installer to detect ALL hardware
at installation time if possible. Installation with sound support right
from the start would be something one could show off. That would be
possible when installing from CD. I do not care for sound when installing
from a single floppy of course.
Ordering of installation steps
..............................
The current proposal for ordering the installation steps is not fully to
my liking. First, I don't think we need that now. Others do not have such
a modular installer so let's just support a fixed step-by-step install
in the prototype.
We need a communication channel between the installer modules and the
main loop and can use that later for ordering of installation.
I think the optimal thing would be a assistent like installer which just
guides the user through the process step by step. In case something goes
wrong it should tell the user about the problem and jump back. Special
tasks should be selectable by a button "Special" or something.
That menu could depend on the current step (for example when partitioning
the disk that menu could support configuring LVM etc.).
This should be coupled with the configuration database. For example
if the partitioning is done the boolean filesystem/partitioned could
be set. When at installation time insufficient space is detected
the module could tell the installer that filesystem/partitioned is set
but did not serve the purpose in which case the mainloop could jump
back to the step were it was done.
Of course we should add sanity checks which warn the user if / has not enough
space for a typical installation (saying: / should be at least 100MB, are
you absolutely sure that you know what you are doing?).
Again I think we should concentrate on the installation modules first. When
they are working we can chain them in any way we want.
So far for now
Torsten (wow, 2 hours of writing, can't we continue in german? ;)
Reply to: