[debian-devel:11555] Re: [vague discussion] woody boot-floppies plans

[Taketoshi Sano <kgh12351@xxxxxxxxxxx>]

佐野＠浜松です。

参考のために debian-boot list のメールから引用しておきます

In article <20000207174538.E25437@xxxxxxxxxxx>,
  at Mon, 7 Feb 2000 17:45:38 -0800,
   on Re: [vague discussion] woody boot-floppies plans,
 Joey Hess <joeyh@debian.org> さん writes:

> Glenn McGrath wrote:
> > This is the way i see it.
> 
> You see it very, very much the way I do. :-)
> 
> > The primary limitation on the quality of boot floppies is the limited
> > space we have to work with.
> > To make maximum use of space in the boot floppy, you only want things
> > you specifically need for your circumstance on the floppy.
> > The more flavours of hardware that debian supports the more complex its
> > instalation becomes.
> > There are some parts of the install that are generic, other parts are
> > specific to a particular instalation.
> > 
> > A solution to the above could be to have a singular core module (like
> > dbootstrap) that is used by all installs, have everything else as a
> > seperate module. e.g. a network install module, install from local
> > storage module, install from CD module, install to local HD module,
> > install to NFS module, install to loopback device module, serial_console
> > module, newt module. Also architecture specific modules, like each
> > architecture would have its own kernel_arch module, and possible
> > partitioning_arch module. <Ok im waffling on a bit, im sure you get the
> > point>.
> > 
> > If you have a loose collection of modules you could give the end user
> > control of the functionality they get in there boot disk. So they could
> > choose to use a generically generated boot disk, or choose to build
> > there own customised isntaller specific to there needs.
> > 
> > By building a customised installer it should be possible for some people
> > to have a single install disk.
> 
> Yep. Ok, let me send a brain dump to this list. This is a plan for a
> redesign of the boot floppies that I have been refining for about 3 months.
> Still pretty rough, but it lays out some specifics that match your ideas
> above.
> 
> -----------------------------------------------------------------------------
> 
> 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, and also
>   so people "own" various parts of the install process, and are thus
>   responsible for it, just like people are responsible for packages nowadays
>   (this scales better).
> - 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
>   - 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 downloader is available, asks which to use.
>   - runs the downloader's setup program.
>   - asks the downloader to see if there are any extra modules it can
>     download. If so, gets them and sets them up. (optional)
>   - tells the downloader to download the partitioner.
> ***** note that everything from here on is not on the initial boot floppy *****
>   - mounts the partitioner on a ram disk, and runs the
>     partitioner's setup program.
>   - tells the downloader 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 but probably not all 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 downloader
> 
> 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) downloader 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 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 (busybox). I'm sure someone will want to
> stick doom in one so we can compete with Caldera's tetris. ;-)
> 
> -----------------------------------------------------------------------------
> 
> -- 
> see shy jo

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