Re: [vague discussion] woody boot-floppies plans
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
Reply to: