[debian-devel:12679] Re: i18ned installer

[Taketoshi Sano <kgh12351@xxxxxxxxxxx>]

佐野＠浜松です。

In <20000712233953.6a9f77ed.yosshy@xxxxxxxxx>,
 on "Wed, 12 Jul 2000 23:39:53 +0900",
 with "i18ned installer",
  Akira YOSHIYAMA <yosshy@xxxxxxxxx> さん wrote:

>   potato の boot-floppies で debconf が i18n 対応しないと
> いう事になりましたので、しょうがないから woody ベースで 
> Debian/98 インストーラの開発をしようかと考えています。
>   ただ、woody installer ってのが別にあるみたいなのですが、
> これはいかな物でしょうか？ご存知なら教えてください。	

 http://cvs.debian.org/debian-installer/doc/ 以下を見てください。
 anonymous cvs で入手するなら

   cvs -d :pserver:anonymous@cvs.debian.org:/cvs/debian-boot \
      login
    (just enter)

   cvs -d :pserver:anonymous@cvs.debian.org:/cvs/debian-boot \
      checkout debian-installer

あるいは

   export CVSROOT=:pserver:anonymous@cvs.debian.org:/cvs/debian-boot
   cvs login
    (just enter)
   cvs checkout debian-installer

です。

最近 cvs.debian.org は cvsweb 経由で中身も見えるようになったので
 (以前はダメだった) http 経由で見れます。

で、現状は単に design.txt として構想が出されている段階で、実際に
コードの実装が始まるのはたぶん potato がリリースされた後のことに
なるだろうと思います。

とりあえず現在の design.txt の内容を添付しておきます。(175 lines, 7524 bytes)

--
     ＃ (わたしのおうちは浜松市、「夜のお菓子」で有名さ。)
    <kgh12351@xxxxxxxxxxx> : Taketoshi Sano (佐野　武俊)

Redesigning Debian's boot floppies

Our install and our boot floppies have long been a problem for Debian.
I'm going to try to identify the roots of the problems with the boot
floppies and suggest some soutions, but first let's look at how the boot
floppies work now and what they have to do.

Boot floppies now
-----------------

A few stages can be identified in a debian install now:

1. initial boot off of install media (floppy, cd)
  - Syslinux (or other loader for other arch) is run, and it boots the kernel
2. kernel boot
  - The kernel sets up a ram disk and loads the main install system
3. main install system
  - Many subsections here. Key are:
    - identify local settings (is there color? What lanugage and time zone?)
    - load device drivers from install media
    - identify hardware, configure device drivers
    - set up install disk (partitioning, formatting)
    - install base system (kernel, base tarball, lilo (other loaders for
      other arch's))
  - This also includes a full shell system for rescue and other activities.
4. reboot
  - Several questions asked before the user is dumped into a normal login:
    - root password
    - add another user
    - shadow passwords, pcmcia, etc
    - package selection
    - package install

The root of the problem
-----------------------

I think the core of our problems is in step 3. Everything that happens in
step 3 is done with special-purpose code, that has to deal with all the
possbilites (multiple arches, different install methods and hardware, etc)
and must be crammed into as small a space as possible. Note that these two
needs tend to conflict a lot!

The code isn't reused in other parts of debian, and developers tend to
forget about the installation once they've done it, so only a small team of
people works on it. Contrast with step 4, where little of the code is
special purpose, and space constrianst are no longer a real problem. 

I think that much of what is done in step 3 can be postponed to step 4.
(Things like time zone setup, configuration of hardware not necessary to
boot, etc). Anything that is pushed back to step 4 becomes part of a "real"
debian system, and so I think it will get a lot more attention.

Goals
-----

I would like to reorganize the boot floppies to accomplish the following
goals:

- Bring them back into the core of debian as much as possible, so more
  people work on them as part of normal debian work. This means getting
  a normal debian system up as soon as possible, and continuing the rest of
  the install inside it.
- Make them modular, for increased flexability, and smaller size.
- Make the set of floppies you need to burn to install debian smaller.
  Ideally: 1.
- Simplify the install as much as possible.

New design
----------

Here is an overview of the new design I am proposing. The install process is
modularized, and works like this:

1. initial boot off of install media (floppy, cd)                    
  - Syslinux (or other loader for other arch) is run, and it boots the kernel
2. kernel boot
  - the kernel sets up an initrd, which contains the installer,
    UI, and bootstrap loader, and runs the installer
3. installer
  The installer consists a bit of logic code, and some random tools like tar.
  - figures out what UI to use and starts it in the most portable mode that
    UI has (ie, uncolored text in English).
  - runs the UI's setup program.
  - probes to see if any extra modules are available on the initrd. If so,
    sets them up. (optional)
  - if more than one bootstrap loader is available, asks which to use.
  - runs the bootstrap loader's setup program.
  - asks the bootstrap loader to see if there are any extra modules it can
    download. If so, gets them and sets them up. (optional)
  - tells the bootstrap loader to download the bootstrap partitioner.
  - mounts the bootstrap partitioner on a ram disk, and runs the
    bootstrap partitioner's setup program.
  - tells the bootstrap loader to download the base system.
  - unpacks the base system onto the filesystem the partitioner set up.
    (In an ideal world, the base system would be smaller, just containing dpkg
     and it's dependancies, and the rest would be downloaded and installed
     as .deb's in a chroot.)
  - chroots into the base system and runs the base setup program.
4. base setup program
  - This program runs inside a complete debian base system.
  - Sets up some of:
    - lilo (or other loader)
    - the initrd debian will boot from
    - the timezone
    - additional hardware
    - shadow passwords
    - root's password
    - another user account
    - networking
  - Then it reboots into the full debian system, or perhaps optionally
    just runs init to start it w/o reboot.
5. booting the full debian system
  - Since the system was installed with a minimal kernel that cannot talk to
    the hard drive, an initrd must be used. The initrd has a syslinux file on
    it, and a set of modules. It just loads the modules, in a certian order,
    with certian parameters, and then lets the kernel pass control to init.

The modules follow.

The UI

This is some kind of a modular UI with a simple API so other modules can use
it. It's probably not much more complex than dialog. I want to say
"mini debconf!" here, but I dunno if that's wise. :-)

The UI has a basic setup program that is intended to ask just enough
questions to get the UI setup and working. It might probe instead of asking
questions. The things it needs to find out are probably:

 - what is your language?
   (This could be probed by looking to see if any other languages are
    available and if not, going with the one language that is)
 - If text GUI, does color work?
   (This could be assummed in some cases.)
 - If other GUI, other stuff.
   (Probing possible.)

The bootstrap loader    

The sole purpose of this component is to acquire a file from somewhere.
It might accomplish this by loading it off of floppies, or off a cd,
or by initializing the ethernet, running dhcp, and then tfpting,
nfs loading, or ftp or httping it off a server. Or even by setting up
a modem and ppp, and downloading it.

It is intended to be a modular compnent, with a simple API. There are two
API calls:
  - set yourself up (may be a no-op, may be quite involved)
  - download a specified file to a specified location

This lets one (very simple) loader be put on cd's. Other loaders might be
put on floppies, one per floppy. So there will be a "piles of floppies
install" floppy; an "ethernet install" floppy, a "ppp install" floppy, etc.

The bootstrap partitioner

The sole goal of this component is to set up the install destination
and the swap space. So it will have drivers for various disks, a disk
partitioner(s), formatters, etc, and when it is run it will interact with the
user (or probe) to set up the disk.

One other thing this module does is it stores data about what modules
loaded, and how, plus what device files it made, etc. This data is used
later when the full system is booted via initrd.

Extra modules

It should be possible to include extra modules on the boot media, or in the
initrd (easier). These are almost like debian packages. They can be
installed into the initrd, and provide extra functionality. When installed,
a setup program in them is automatically run.

The main thing I expect this will be used for is a module that provides a
basic shell system and some tty's. I'm sure someone will want to stick doom
in one so we can compete with Caldera's tetris. ;-)