Comments re: SEUL installer (long)

[Erik Walthinsen <omega@omegacs.net>]

Have you gone through a RedHat install?  (the Booting section alludes that
you have)  Many of the issues raised in the document have been taken care
of for a long time, and are only issues still in the Debian install
process, which is IMHO unimaginably lame (at least, bo was).

A secondary idea to installation is a live CD-ROM for trialing, then
installing SEUL.  More on that much further down.


Scope (Notice):

There should be *no* DOS-level work at all.  It has been discussed, and
there are no advantages to requiring any, and plenty of disadvantages (not
all of them technical).  One of the most obvious is the case where the
user just doesn't have anything on the disk but data (say it was a
secondary disk).

If the disk to be installed on has no free space, that should be taken
care of by Linux, not DOS.  It would likely be a week or two project to
write a lame but workable FAT defrag program, another week or two to make
it better than existing DOS ones (considering the Linux disk drivers are
faster than DOS/Windoze).  A couple days to a week would be needed to port
FIPS to Linux (where it belongs, IMO).


Booting:

It's unclear what you mean by 'some basics at LILO prompt'.  Those things
listed here are things that happen once the machine is booted and running
in runlevel X.

Also LILO hasn't been used for installers for many years.  HPA's
ldlinux.sys is used for both RedHat and Debian, and I'd be very tempted to
look into GRUB (used for Hurd) to see if that's got any cool features
besides native access to ext2fs and so on...


CD-ROM (/ethercard):

I like the idea of using /proc to find things.  I haven't scanned through
the rh50 install.c code, maybe that's what it does now, but I know rh42
just looped through hd? and hoped for the best, which flailed and failed
left and right in mustang and tbird (4.8 and 4.9).

As for non-IDE/SCSI drives, I'm wondering where the best place is for the
modules (first or second disk).  It depends on 'who' we want to be nicest
to.  I'd love to cram everything we can on the first disk, for instance
all the common ether and CD-ROM drivers (leaving the uncommon ones for the
second disk), as once we have either ether or a CD-ROM we can load all we
want from there.

I don't think we need an extensive database of possibilities, though,
because that would be self-defeating.  The interfaces for proprietary
CD-ROM drives can be rejumpered all over the place.  OK, a database could
be somewhat useful, if we can determine canonically what choices are
possible, and what kind of conflicts might crop up.  But it wouldn't be
that big, no more than 10K raw text, I think. 

For the case where things might hose out during probing, it'd be nice if
we had some way to make sure the machine rebooted as often as possible
once things are hosed.  One way to do that might be the software watchdog,
which will reboot the machine if a certain device file (/dev/something) is
*not* written to within a certain period of time (configurable).  If the
watchdog is sufficiently embedded deep into the kernel (it's a module, so
I dunno) to *always* be running unless even the processor HALTs, it might
be the way to go.


Partitioning:

Unsure about 'without having to hack the partitioning program'.  What we
really need are tools native to Linux to do the following things:

1) defragment a FAT{12,16,32} filesystem, knowledgable of 'unmovable'
files and so on.
2) shrink (FIPS) a FAT{12,16,32} filesystem
3) *move* a filesystem somewhere else:
  original:  xxxxxxxxxxxxxxxxxxxxxxxxx........................
           GB       .5        1        1.5          2        2.5
       new:  ..xxxxxxxxxxxxxxxxxxxxxxxxx......................
   (lame example where the BIOS *must* load the kernel from the lower
   1024 cylinders, so we have to create a /boot filesystem
4) graphical partitioning using a pie graph

Also, there is no need to reboot once the partition table is rewritten.
Doing so does nothing but confuses users, and besides, it's not a problem.
Looking at the redhat source installer source code, it appears that they
do indeed have a clause where a reboot is necessary, but this is easily
distinguished from the case where everything works.  I've personally
*never* seen this error message, and I've done what the message talks
about possibly causing it (changing extended partitions).


Saving information:

I like this idea!  Keeping track of the current state of an in-progress
install for recovery usage is something none of the existing installers
do, AFAIK.

However, I'd prefer to put the state information on the host machine,
rather than the boot floppy.  Putting it on the floppy would make it
impossible to use the floppy in another machine without either forcing it
to ignore the known settings or having some kind of UID mechanism for the
system being installed (i.e. the installer can build a 32- or 64-bit ID of
the machine from nothing but probing the hardware, impossible IMO).

If it's deemed that a dialog box at the very beginning stating "there is
an in-progress installation recorded on this floppy, do you want to
continue it" is a reasonable solution, then we need to make sure that all
the machine information is recorded there, *and* probed *before* this
dialog comes up.  If they don't match, we can either discard the state
information, ignore it completely, or as the user a different question,
i.e. "there is an in-progress installation recorded on this floppy, but
the machine information recorded doesn't match this machine, do you wish
to continue anyway??".


Mount point and mounting:

There are three basic types of installs:

1) brand-new machine
2) Windoze machine
3) Linux machine

For new machines, things are trivial, obviously.  On Windoze machines,
things get more interesting, but not very much so.  All programs and data
are stored on one partition per disk, unless the user is a 'guru' (I had 4
partitions on my 211MB drive once, using DblSpace and so on [eeew!]), at
which point more complex tools need to take over.

If the machine already has Linux installed, there is a good chance that
there is data on the partitions, as you say.  The question is what to do
with that.  Say the user has two partitions, one for the system and one
for /home.  In that case, it's easy to determine that information, as all
we have to do is mount each partition in turn and look for /etc/fstab.  If
we find one, we can then ID the contents of the other partitions from it.

If we want to get really cute/smart, we could look for a lilo.conf, try to
compare it against what's actually there, and ID mutliple installs of
Linux and/or DOS/Windoze.  However, that's going *way* too far for an
initial hack at this.


Figuring out partition tables, mount points, existing data, etc., is going
to be by far the most complex part of the installer.


Package selection:

This is the most visible part of the install, after the partitioning.  The
trick is to do it right...  I like your suggestions about how to do it,
including:

1) list categories only (initially)
2) *don't* list non-apps, i.e. libraries, etc.
3) take care of dependencies automatically, and *after* selection

I just had a thought on the first one: categories don't have to form a
balanced tree.  If we have something that's multi-level and reasonably
laid out, it makes it easier for the average user to find what they need
without being innundated by all sorts of random cruft, like development
stuff.  (yes, we will include development packages, else how will coders
and developers do anything with SEUL?)

Consider the following:

'( )' means not checked by default
'(X)' means checked by default  ('!' means can't unselect)
'(x)' means checked by default when parent category selected

- Applications		     "User applications"
  - Word processor	(X)  "Free word-processing program(s)"
    - ourfavwp		(x)  "SEUL's choice wp program"
    - anotherwp		( )  .
  - Spreadsheet		( )  "Free spreadsheet program(s)"
    - reallygoodss	(x)  .
    - sososs		( )  .
  - Database		( )  "Free database programs(s)"
    - cooldb		(x)  .
    - lamedb		( )  .
  - Graphics		( )  "Free graphics program(s)"
    - GIMP		(X)  "Photoshop-killer, the best graphics app."
  - Internet suite	(X)  "Common tools for using the Internet"
    - Navigator		(x)  "Netscape Navigator"
    - exmh		(x)  "The emxh mail client"
    - somenewsclient	(x)  "A cool USENET client"
    - ncftp		( )  "Command-line access to FTP sites"
    - lynx		( )  "Text-mode browsing of the WWW"
    - gopher		( )  "Text-mode browsing of gopher sites"
- Cool Tools		(X)  "Tools to make your system cooler"
  - CD Player		(x)  "CD-player deck"
  - Audio suite		(x)  "Sound tools, including playback"
    - Player		(x)  "Play WAVs, MP3s, MODs, ITs, etc., etc."
    - Recorder		(x)  "Record your own audio!"
    - Wave Munge'r	( )  "Tools for complex manipulation of sound"
  - ...			(x)  ...
  - biff		( )  "Legacy tool to notify you of new mail"
- ... (other end-user stuff) ...
- Development		( )  "Programming tools"
  - C development	(x)  "C-language development"
    - libc-devel	(x)  .
    - gcc		(x)  "The GCC compiler"
    - ...		(x)  .
  - C++ development	( )  "C++ development"
    - libc-devel	(x)  .
    - g++		(x)  "The G++ compiler"
    - libg++		(x)  .
    - ...		(x)  .
  - ... (other langs)	( )  "Perl", "Python", "Tcl/Tk", "f77", etc..
- System tools		     "Core SEUL components"
  - REQUIRED		(X!) "Packages that MUST be installed"
    - init		(X!) .
    - bash 		(X!) .
    - ...		(X!) .
  - Daemons		( )  "Internet servers"
    - apache		(x)  "Your own web server"
    - wu-ftpd		(x)  "(Anonymous-)FTP server"
    - gn (gopher)	( )  "Gopher server"
    - ...		( )  .

Obviously I'd have to justify a few of those things, but that's for a
later time.

So, what the user sees initially is something like this:

Capability:		Packs:	Sel:
+ Applications				User applications
  - Word Processor	2	1	Free word-processor program(s)
  - Spreadsheet		2	1	Free spreadsheet program(s)
  - Database		2	1	Free database program(s)
  - Graphics		1	1	Free graphics program(s)
- Cool Tools		5(+)	4(+)	Tools to make your system cooler
- Development		5(+)	0	Programming tools
- System Tools		87	80	Core SEUL components

Disk Space: 120MB of 2.1GB  (xxxx....................................)

The idea is to give certain weights to pieces of the install that ppl care
about.  For end-users, that means the first package selection screen they
see would look like the above.  They are primarily interested in
applications (we *know* this because of the target audience), so that's
what we show them.

Every item listed there is (obviously) an abstraction of what really gets
installed.  Remember, our target user doesn't know what 'vixie-cron' is,
nor does (s)he care.  It's just something a few packages (like logrotate,
another package they don't care about, which is used by sysklogd, another,
and apache, one they might care about) depend on.  Don't give them more
information than they want.

I think the above scheme is better than what RedHat does (the flat
category selection) because it gives the user a clue what they're
selecting.  If they select "Internet suite", they should know what is
installed and what isn't, but they shouldn't have to do so by scanning
through the resulting *raw* package list.

What would still be good is a lower-level browser of packages and
dependencies, so in case something goes funky, someone with a little more
knowledge than average can figure things out.


As far as space checking, I think that should be done in the most live
manner possible.  Any line in the selector should have a couple
percentages next to it, maybe three.  Say have a bar-graph with each end
showing the minimum and maximum percentage of the disk taken, and the
graph shows where you are in between those, with the number shown
reflecting actual usage (rather than 50% meaning halfway between min and
max...).

And of course, the overall space usage should be shown in a large bar
graph on *all* package selection screens.

How to deal with the case where the installer (or the user) is smart
enough to set up multiple partitions could get ugly.  The information *is*
available (at least in an RPM) to allow the system to read the package
header and figure out how much space is used on each filesystem, but it's
not the fastest operation in the world, and requires access to the install
media (which AFAIK we must have by this time anyway).




X server selection:

There are a couple method we can use to figure out which card is
installed.  As stated, /proc/pci can be used to pick out certain cards.
I'm not sure how useful that is, though, because it assumes that the
device is listed in linux/drivers/pci/pci.c, which isn't always the case.

`X -probeonly` can help out, though it does make the screen go nuts and it
can hose out the machine...

However, I'm wondering if the X server selection shouldn't happen at the
same time as configuration.  With configuration left to the end, chosing
which server at this point means duplicating probe efforts.  We should
have access to the install media all through the install process, so I
don't think this should be done right away.


Networking:

This entire section may happen either at this point or while trying to
find the install media, so that has to be taken into account.

One thing we have to keep in mind is the growing number of systems with
both ethernet cards and modems.  There is a tendency in the RedHat install
to assume that you have only one of anything in a given category.  This
bit hard at work when we tried to upgrade a quad PPro box.  It boots from
an IDE disk, has three more SCSI disks on two onboard aic7870's, and has a
aha1542 with the CD-ROM burner and DAT.  Since RedHat only asks for one
SCSI card, you get either the SCSI disks or the CD-ROM drive.

One idea I have, and I'll probably get around to writing it one of these
days, is an uber-probe thing.  It would spew all kinds of
network-discovery information all at once, and try to gather information
as fast as possible.  DHCP to try to allocate an address, RARP to get
networking info, RIP to find a router, BOOTP to find an address and other
info, tcpdump to find subnet, burst-ping to find free addrs, etc.

Once the ethernet device is configured, such a program could be loosed on
the network to try to configure it at the same time the user may be
entering in their own parameters.  As info is found, a second column is
filled in and they become defaults.  Though, that may be unfriendly to the
network.  Perhaps it's best to let the user decide whether to enter the
information manually or let the uber-probe loose.

PPP is a trickier subject, of course.  I have few thoughts about that
right now, so I'll leave that to someone else to comment on.


Kernel config:

I like the idea of having a couple different precompiled kernels to chose
from, but I don't think we should eliminate the ability for the user to
have a custom kernel built.  However, it may be best to stick to the
precompiled kernels during install, and allow custom kernels only once the
full machine is installed.


/proc/cmdline:

The ability to handle modules for multiple kernels of the same version is
a function of the sequence number of the kernel (and support in
conf.modules), not of the kernel commandline.  That's a feature we should
incorporiate in the system just for the covienence of it.  I have had
mucho trouble with mismatched modules, imagine what an end-user would go
through: "reinstall!".

However, we should use cmdline to detect if there is a recovery situation.
The bootloader (LILO, GRUB, whatever) should always have a safe-mode boot,
which would add something to the cmdline to trigger all the bootup scripts
to do recovery mode.

One thing I use on my development machines is the fallback and 'next-boot'
capabilities of LILO.  We could have the default boot always point to the
recovery kernel/mode, and do a `lilo -R linux` on shutdown of the system.
This has some disadvantages, though, and only works when SEUL is the only
thing installed on your machine.  On the next boot, LILO will start the
primary kernel immediately (I'd like to have the delay in there..).  If
something hoses out, i.e. the machine is shut down uncleanly and lilo -R
is never run, the next boot will default to safe mode.

The primary problem is that this rewrites the boot sector constantly.  If
you have more than one OS installed, or System Commander, you just hosed
out something or other.  The other problem (fixable) is that you don't get
a delay to chose whether to start the lilo -R'd entry or some other.  That
means that you always start directly into SEUL.  This could be fixed by
changing lilo -R's behaviour to set the default instead of just booting
directly to that entry.


Phase 2:

I haven't though much about this stuff yet, so I'll leave it to someone
else to comment on.



Hope that's useful information.

TTYL,
    Omega

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user