Re: [mingp@COREL.CA: How we can with your Setup Engine?]
On Sun, Mar 21, 1999 at 08:48:50PM -0500, Ming Poon wrote:
> Adam Di Carlo wrote:
> > Actually, we already have this, but rather than making it X based,
> > we're using the FrameBuffer devices from the 2.2 kernels. This
> > actually *can* fit on a 1440KB floppy.
>
> We would like to break up the setup into engine components and UI components
> and the two should be independent of each other as much as possible. This
> way, people can use the power of the setup engine to create whatever UI they
> prefer to drive the setup engine to suit their needs. In my mind, the FB
> code is still very important for the 1st stage install before the VGA16 X
> Server is installed and loaded for the 2nd stage, more user-friendly setup
> UI.
Currently the UI code is just a single file, 460 lines of C code, with
some functions like:
int problemBox(const char *text, const char *title);
or
int twoButtonBox(const char *text, const char *title, const char
*button1, const char* button2);
Those may be implemented using any libraries one wish, and that's been
done with newt+SLang (character mode windowing libraries, used on
Debian and RedHat current boot floppies) and Ben Pfaff's
framebuffer-based windowing library.
About the 1st and 2nd stages, let me elaborate a little on how our
current system is implemented:
- a boot loader starts a kernel with a root disk image as an initial ram
disk.
- a program called dbootstrap is run from that root disk image.
A shell may also be run on the second virtual console, and the root
disk image contains a full set of tools for an expert to be able to do
the installation "the hard way". That's why the boot disk is called the
"rescue" disk.
- dbootstrap is used for the following:
+ partition the disks (using another program: cfdisk or fdisk)
+ initialize and activate swap and target partitions (using a set of
tools linked into a sort of swiss-knife tool called busybox)
+ install kernel and modules:
They may be installed from floppies (2 1.44MB), CD, local harddisk or
network.
+ Activate needed modules (ethernet card driver, PCMCIA subsystem...)
+ Configure the network
+ install the base system:
The base system is a <10MB tgz file that contains the essential
packages that any Debian system needs to be able to boot and install
other packages. It may also be installed from floppies (7 1.44MB),
CD, local harddisk or network.
+ Make the harddisk bootable and/or make a boot floppy
+ reboot
- After the system reboots a shell script is run automatically. It does a
few other "simple tasks" like setting root's passwd, activating shadow
passwords, creating a non-root user... (those tasks may be done by
dbootstrap before the first reboot, and I'll probably implement them
that way for the next boot-floppies version).
After that, the script calls pkgsel and dselect.
- pkgsel is a little shell script that let the user choose one of the
preselected sets of packages to install. Options are things like:
"Dialup: Home machine (graphics, sound, X, ...)", "Server_std: Std.
Server (Ftp, Web, DNS, NIS, POP)" or "Work_std: Standard Workstation
(TeX, graphics, Internet, X, ...)". The user may skip this step and
select the packages one by one using dselect "Select" menu.
- dselect is our current front-end to the package installation tool,
dpkg. It's not just a tool for first installations, but it may be used
later anytime the user wan't to update/install/remove some packages.
It's used to:
+ select a source media which will be used to install the packages from
(CD, network, mounted filesystem, floppies, ...)
+ update the list of available packages
+ select packages to install/remove (this step may be skipped the first
time, if the user has gone through pkgsel).
+ install/remove selected packages
- After leaving dselect the common "login:" prompt will be shown. The
installation is finished.
Now about the stages. With our current implementation we may divide the
installation in two stages:
- In the first stage a basic system is installed and configured
(dbootstrap + "simple tasks").
- The second stage (pkgsel+dselect) is done using the standard front-end
for package selection/installation/deinstallation, the same one the
user will start anytime he wishes to install a new package.
(Currently that's true just for dselect, as pkgsel is not keep after
the first installation, but that's a bug, and will be fixed).
The "boot-floppies team" works just on the "1st stage" tools (and pkgsel,
again that bug). The "2nd stage" tools are maintained by other team, and
work is in progress to improve them with the new "apt" package, that
provides better command line tools and will provide an easier-to-use
front-end. There's currently a version of that frontend using X and the
GNOME libraries, named "gnome-apt".
> I don't think a plain floppy
> installation is that much suitable these days. (Remember, how painful it was
> to install OS/2 with floppies?).
Debian users usually do network-based installations or CD-based
installations (altough some of them use the other methods, even the
all-in floppies one). For network-based installations they'll need a boot
floppy to start the installation, unless they have another OS on the same
machine. Even for CD-based installations a boot-floppy may be needed if
the BIOS doesn't support booting from a CD. And bootable CDs use a floppy
image file on a special place of the CD to boot (although they may use
bigger image files).
That means we'll probably have to keep building one or two floppies for
booting and a few additional modules. OTOH, the basic system and the
packages are not designed to be distributed on floppies (although there
are tools to split them to fit on floppies, and they may be installed
from floppies if needed).
> I think once we have a chance to study your setup source code, things will
> become much clearer for us. We can then suggest to you which area we can
> contribute to the most. We would still welcome a To-Do list from you so we
> can pick out the things we are good at for the moment or try to hunt for
> potential candidates who are good at those areas. Thanks.
There's a "todo" file on the top-level directory of the sources, but the
main items for the next version are:
- automatic hardware detection (that probably implies building a tiny
kernel with "everything" built as modules, and providing that modules
on an initrd file along with the automatic hardware detection tools).
- a "new-user friendly" system for partitioning disks and initializing
partitions. (a different approach to "Disk Druid").
- Support for reading the answers from a file (locally or through the
network), to be able to do automatic installations. DHCP and BOOTP
support on the boot disk would help too.
- graphical UI
Thanks,
--
Enrique Zanardi ezanardi@ull.es
Reply to: