redesigning the debian installer
I think I said I'd have this design draft done 3 weeks ago. Real life
intervened, and the rest of this month is going to be even worse. So I'm
going to post this rough draft of the design now, with the caveat that
it needs a lot of work. Please help me make it better.
Note that all documents are available in debian-installer cvs in the doc
directory. (cvs -d:pserver:anonymous@cvs.debian.org:/cvs/debian-boot co
debian-installer) I've included the more important ones in this message.
I'll start with the simple stuff and build up...
Modules
-------
The new debian installer is highly modular. Modules are loaded at several
points in the install process to add capabilities to the installer. Modules
are essentially sets of files that get unpacked onto the installation
system, plus some metadata.
Because there is already so much infrastructure to build and manage debian
packages, and because it allows metadata to accompany the files in a module,
we have decided to use debian packages as the modules for the installer.
Unlike regular debian packages, modules for the installer will not be
policy compliant. They will not contain documentation in /usr/share/doc.
They need not comply with the FHS. They may be statically linked. They may
conflict with essential "real" debian packages, and thus be non-installable
on a real debian system, although it is recommended that if possible, this
be avoided.
[ Detail where the modules will go in the debian archive, and any way they
can be distinguised from "real" debs. ]
Modules will not be installed by a full-fledged dpkg implementation, so the
following features of regular debs will not be supported:
[ This is not set in stone, but let's not implement this stuff unless we
need it. ]
- pre-dependancies
- preinst, postrm and prerm
- conflicts
- versioned dependancies
- provides
- essential or required packages
- suggests
- recommends
- `|' in dependancies.
The following will be supported:
- simple dependancies
- postinst
- debconf
Retrievers
----------
Retrievers are modules that can download or otherwise retrieve
files[1], including other modules and Packages files. It is expected that at
least the following types will eventually be implemented:
- cd retriever
Ensures an install cd is mounted, and finds files on it. No real
retrieving done.
- floppy retriever
May or may not need to deal with files split across multiple
floppies. In any case, pulls files off floppies.
- hard disk retriever
Gets a file from a local hard disk (dos, linux, etc).
- http retriever
Downloads a file from a remote http mirror.
- ftp retriever (needed?)
Downloads a file from a remote ftp mirror.
- nfs retriever
Gets a file via nfs.
A retriever must be able to do the following:
- Set itself up so it can access the cdrom, mirror, or whatever.
- Get a list of the modules that are available. This will be done by
retrieving a standard Packages file.
- Retrieve a file.
A separate module will take care of parsing the Packages files, and
checking md5sums of downloaded modules, and a separate program
(udpkg) will handle actually installing modules.
Since retrievers are debian packages, they can have a postinst that is
run to set them up. During setup, they may need to prompt the user for
information (using debconf). For example, a nfs retriever will probably
need to prompt the user for a nfs server name. [ I'm not sure that doing
such setup in the postinst is a good idea. ]
Retrievers may also need to depend on additional modules. For example the
http/ftp/nfs retrievers will need to depend on a module to set up networking,
while the cdrom retriever may need to depend on module(s) that include kernel
modules for the iso9660 filesystem and cd drivers.
Retrievers may also need to interact with the user when they are retrieving
a file. For example, the floppy retriever will need to prompt for disks.
This interaction will also be accomplished via debconf.
Retriever interface
-------------------
All retrievers should support the following interface.
[ This interface is preliminary and depends on the filesystem layout and
ramdisk allocation scheme used by the installer, and so the location may
change. ]
/usr/lib/debian-installer/retriever/<retriever name> is a executable. It
is run with the following parameters:
filename dest-directory
Download the specified file to the specified destination
directory[2]. The filename is the Filename field of a Packages
file.
Thus, retrieving the Packages file itself is something like this:
program Packages /tmp/
While retrieving a deb is something like this:
program retrievers/http-retriever.deb /tmp/
If the destination file already exists, the retriever may want to attempt
to continue a download. Note that the destination file may also be a fifo
or a named pipe.
Once ran, retrievers are free to prompt the user, or do whatever else is
necessary to retrieve the file.
Note that this simple interface requires that retrievers know the location
of the base directory of the archive. This will not be a problem for many
-- the cdrom retriever simply uses whatever is available, in a hard-coded
location. Other retrievers may require more configuration. For example, the
http retriever will need to know what version of Debian is being installed,
what site to install from, and probably what version of the debian-installer
is being used as well. The user will likely have to be prompted for some of
this data during retriever setup.
Footnotes
---------
[1] Conceptually, rather similar to apt's methods, although the interface
is a lot more simplistic and we don't need to support things like
pipelining multiple downloads.
[2] Some retrievers may want to show progress displays while downloading.
Support for this may need to be added to debconf, via a new data type.
It's rather hard to do in the context of debconf -- details to be
determined.
The Installer UI
----------------
Debconf (or rather, a smaller C implementation of the same specification)
is the main UI framework for the installer. Using debconf, it should be
possible to plug in new UI's with a minimum of difficulty.
So this document won't go into detail about how the UI will look. Instead,
it will talk about the structure and flow of the installation experience,
from a user's standpoint, and then from an implementation standpoint.
The user's view
---------------
Note that since debconf allows questions to be prioritized, it is possible
that the install process will skip over any or all of the questions.
The install begins with a bootloader. It is unlikely that this will change
significantly from what is used now.
After the kernel boots up, the first thing the user will see is whatever UI
is being used, configuring itself. This is equivalent to the current
installer asking if the screen supports color, and keyboard configuration.
It might also include language selection, mouse setup, etc. All up the
individual UI.
Once the UI is configured, the user will see a list of every step in the
install process, with a proposed next step, and an alternate next step, at
the top. This is very similar to how the installer works now. We have
observed that this layout gives the user a great deal of flexibility, which
is very useful if something goes wrong and they have to run steps out of
order for some reason, or repeat a step. However, we also anticipate that
people might not want to see this menu, and would rather go through a
rigidly linear install process. Therefore, this menu will be a debconf
question asked at priority "medium", and so it might not actually be
displayed.
Anyway, each time an item is picked, the user will see one or more debconf
questions about it. They'll be able to go back and forward between these
questions -- and can even go all the way back to the menu to abort the
item. Assuming they go through the questions, though, eventually, the
question and answer sequence will end, and they will be returned to the menu,
typically with the next item selected.
At a minimum, the menu will probably contain the following items (and
probably several others):
- Configure installation media (from floppy, cd, network, etc)
- Partition disk
- Format and mount partitions
- Install base system
- Install lilo (or silo, etc)
- Make a rescue floppy
- Reboot the system
Once the last item is picked, the system will boot up into a full debian
install, and the user will be prompted for additional information, much
as base-config does now.
Implementation
--------------
Each item in the list is provided by an installer module. To create the
list item, a module must only drop a control file with a unique name into
/usr/lib/debian-installer/menu/. The control file is rfc-822 format, and
should have the following fields:
Priority: a number, which determines where the item appears on the menu
Prog: the program to run if this item is selected
TestProg: a program to run to determine if this menu item should be the
default item
Description: the text to appear on the menu
So the menu is constructed by ordering the descriptions according to their
priorities. Then, each time the menu is displayed, all of the testprogs are
run in turn. The first to return a 0 exit code becomes the default selected
menu item.
Note that items may be added to the menu during the install itself. The
menu might start off as just:
- Configure installation media
- Reboot the system
When the installation media is configured, other modules are automatically
loaded from it, and more menu items become available.
Walkthrough
-----------
If none of this makes sense, read walkthrough.txt in cvs -- it's a
walkthrough of a sample install using this system.
TODO
----
- It's not very clear how/when retreivers and other modules are
configured. It might be nice if a module (say a cdrom retriever
module) can depend on another module (a cdrom driver module)
and be guarenteed that the latter module will be configured before
the module that depends on it is configured.
- A lot more detail needs to be provided about various types of modules
and how they work.
--
see shy jo
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: