Re: Comments re: SEUL installer (long)

[Erik Walthinsen <omega@omegacs.net>]

> Never installed Debian.
I have, and let me tell you, it's a pain.  That's why I use RedHat.

> The install specification was written with this capability in mind.  One
> issue that RH gave for abandoning this is that there must be some
> writeable files. 
The writable files problem can be dealt with by creating a ramdisk, then 
copying files to an available partition.  Systems with Linux installed have 
space, systems with Windoze have space, and those with unallocated space on 
the disk (a toshiba laptop at work with a 4GB drive came installed with a
2GB partition for w95 [because of clusters] and the other 2GB *completely* 
unallocated) can be hacked to find a decent place for it.

However the non-volatile space problem is solved (undoubtedly with some 
user interaction), I think it'd be *exceedingly* cool to be able to put a 
CD-ROM in someone's drive, reboot to Linux (ala El Torrito), show them what 
it can do, then click one button and have the machine installed.  That'd 
wreak havoc with the timeline proposed here, but all the steps are the same 
in and of themselves, so all you have to do is glue them together 
differently.

That'd be one heck of a Windoze-killer, though, if we could get PCMag to 
distrib a bootable/installable SEUL CD with the magazine... ;-)

> The big reason I see for DOS-level work is that we may be able to get
> hardware information that is unavailable in protected mode. I can see
> abandonning DOS anytime the Linux tools become dependable.
IMO there's nothing we can get in DOS that Linux can't figure out.  If 
there is, it should be a relatively simple task to fix that (even if it 
involves patching the kernel used for the installer), and I think it'd be 
sad if we had to resort to DOS to install Linux.  An end-user with even the 
slightest of clues would seriously wonder at this new thing called Linux if 
it relied to DOS for even the smallest thing.

> I don't follow this reasoning.  The data that was never backed up?
No, I mean if they had a second drive with only data, but the drive isn't 
full, so they decide to try Linux.

> > If the disk to be installed on has no free space, that should be taken
> > care of by Linux, not DOS.  
> If we don't have free sapce why put Linux on?
Sorry, I meant unallocated space, i.e. holes in the partitioning.

> Erik, You may be right but I think that you are stretching your
> credibility a little here.  I suspect that all the effort that has gone
> into defraggers amounts to more than something that could be replace in
> three weeks.
True, I'm eternally optimistic, I guess.  But consider that the FIPS code 
is available, and reasonably split between logic and disk code, there is a 
ext2fs defrag program (IMO much tougher a problem than a FAT defrag), and 
we have full access to working sources that read and write all the 
varieties of FAT (filesystem code).

> Besides if there is no room for Linux? What is the defragger written in? Is
> this another diskette?
I'm guessing that a well-written defrag program would be quite small.  I'm 
not sure I know what you mean by 'no room for Linux', though.  The intent 
is to *make* room by defragmenting the FAT filesystem, shrinking it via 
FIPS, and adding a Linux partition.

> I think RH42 installer to has a copy of LILO.
Yes, but the install disks all use ldlinux.sys.  It provides multiple help 
screens and such.

> I hope that SEG can give us some guidance on what arrangement makes us
> the most useful.
I think as long as we make it easiest for the most common case (i.e. IDE or 
SCSI CD-ROM drives, most ether cards, and some proprietary CD-ROM drives 
supported with the first disk), we'll win.  The RedHat setup requires the 
second disk for enough cases that it can get annoying, but they did a good 
job.  Debian on the other hand put *all* the modules on the second disk.

> This sounds like a terrific idea.  I was thinking about how annoying this
> would be interrupting an unsaved edit session, then I realized it only
> needs to run durring the probing. 
I assume you're referring to the watchdog timer...?

> > 3) *move* a filesystem somewhere else:
> I don't follow what you are trying to explain here
If there is a case where for one (likely *extremely* case) reason or 
another we must move an existing partition, we need tools to do that 
safely.  The only reason I can think of would be if the BIOS can't boot 
something past 1024 cylinders, and we can't use loadlin (say the other OS 
is NT).  Then we'd have to slide the NT partition over a couple megabytes 
to put a small /boot partition at the beginning of the disk to let Linux 
boot.

Note: I'm guessing there are even ways around the above scenario.  I just 
added #3 for completeness, and I'm not advocating in the slightest that we 
actually do that.  IMO if someone has that funky of a machine, they should 
already have some experience with dealing with stuff like that.

> Personally I think that pie charts are not as good as a barchart in the
> style of a memory map. 
Depends on the person, I guess.  Probably either would work, but if we can 
make it into a reasonable high-resolution X display during install (if we 
try to do that eventually), we should probably provide both on the screen 
at the same time.

> I contested this with Jean-Francois too.  In the end I simply had no
> answer for his kernel hacking experience and gut feel.
RedHat's been over it already, and I'd feel safe doing it exactly they way 
they do.  Run fdisk, check to see if the partition map shows up, and if not,
reboot the system.  In almost every case the partition map updates 
currently right away, so you just continue on.

> I was just thinking: what if two different machines generate the same ID?
> Do we really care?  The hardware is already the same. I am stuck on the
> idea of probing the hardware.  I do not expect users to know there
> hardware.
Good point.  If we come up with a way to ID certain components before the 
install gets very far (ideally before the user hits the first key) and the 
ID matches, we can safely assume that what we have so far is correct.  The 
trick is to explicitly *not* trust the information, and double-check it.

If we can get the probing done well enough, we may not need any of this 
anyway.  But, I don't think we can probe effectively enough to eliminate 
any user interaction.  The question is, how often will that be the case, 
and is it worth providing this mechanism in the cases where it's a problem?
This should probably be a feature added much later on.

> I sure would like a diskette that would retain the profiles for all of my
> favorite machines. Nice way to collect data on a zillion machines out
> there too.
If we can appropriately ID the machines, it's a possibility.  But like I 
said above, chances are we can't get enough data to come up with any kind 
of ID on a machine.

> Good criterion for prioritization, the function required for the rare
> complex case can be postponed.
We should be careful to identify which features are in place for guru's or 
the complex case, and either ignore them initially, or constrain any work 
for them to simply placing hooks in the installer.

> RH recommends 4 partitions.  Does your idea still work?  Maybe we may
> need to cover something slightly more complicated.
For the case where someone has installed RedHat with 4 partitions, yes, and 
no.  That's probably one of the least likely cases of all.  We do need to 
make sure that our tools can be overridden by those with a clue.

> I could not install RH over slackware without wiping out all of my old
> partitions.  I hear that RH 5 fixes this.
Some simply checks could be put in place as a fail-safe to keep this from 
happening.

> I still think its figuring out the hardware. 
Probably about equal, actually...

> You bring up some really good ideas for discussion.  Please keep your
> list handy, it is as good as anything I've seen yet.. I did not intend to
> be very specific in this section.  I was hoping to spin this discussion
> off and get SEG involved.
Yes, this is something that the SEG should be involved in.  However, 
-install has to drive it.

> Your approach still shares some of the same weakness that I have seen in
> other installers.  It involves selecting from a lengthy list of unfamiliar
> options.
Nope.  The above tree is one that's completely expanded.  The screenshot 
below is what the user would see.  Everything they don't care about is 
hidden away in multiple levels of menus, hence the unbalanced tree idea.

> We may not be able to get around it, but we may be able to make
> considerable improvements. In any case I assume that we will need to be
> flexible and do a lot of refining.
At least package selection of this type is reasonably simple.  Doing 
something like Deity is not, because it caters to the uber-hacker who's 
installing Linux because they have nothing better to do (IMO).  We're 
aiming at those people who want to install Linux and get on with their 
work, which means we can make many more decisions for them without having 
to bother them with interaction.  If the user says they want a word 
processor, we can't bother them with details like handling dependencies, so 
our job is much simplified by virtue of the fact that all way have to do is 
precalculate the dependencies, and just install the stuff.  Reasonably 
simple.

> Seul and Apache? Boggles my mind.  Another reason for this discussion,
> flexibility and refinement, the SEU's seem to have a lot off diverse
> needs.
Well, consider the case where someone's in an office and wants to share 
information with their handicapped (i.e. Windoze-running) co-workers.  The 
answer: install apache.

Yes, there are quite a few wildly different sets of needs out there, and 
that's what the SEG is for...  ;-)

> I'm not sure what an internet suite is.  I know the difference between 
> Netscape Communicator and Navigator though. I wonder why we would not
> just assume Netscape Communicator 5 if they have network or modem. 
> We could always put other options in less intrusive places.
I define an "Internet suite" as a nebulous thing that provides all the 
basic client functionality a user would want, i.e. web, ftp, mail, gopher, 
telnet, etc.  Communicator is a good example of something that fulfills 
that requirement in one single package.

The fact that there are alternatives, yet most people will go for 
Communicator, is why I have the (x) in the installer, so that *if* you 
select a category, some defaults are placed automatically, thus once you 
select Internet Suite, you have what you asked for without having to pick 
one or decide what's what.  A default is available and already chosen, 
making the choice simpler.

> Another good idea.
> Hey Erik you sound like you should be in the
> dev-install-package-selection subgroup.
Naw, this is why I'm a sysarch.... <g>

> We should at least be able to handle the RH 4 partition example. 
Hrm.  As I mention above, that's likely to be the rarest case we'll ever 
find.  And if there is someone out there crazy enough to put 4 partitions
on one disk for an end-user machine while running RedHat, then IMO they
know a heck of a lot more than is necessary to figure out the partitioning
on their own.

> What about your watchdog timer?
That's a good idea throughout the entire install process, I think, not just 
during probing.  Besides, turning it on and off is a good way to hit a race 
condition and spew gratuitous reboots at the poor user.

> How are you going to configure my machine?  RH couldn't handle it.
Are you talking about X?  That's one of the bigger challenges the -ui and 
-install groups have to work on (together).  I'm not sure how best to deal 
with it, as I haven't thought too much about it yet (it makes my head 
hurt... :)

> Leaving it to the end or beginning makes sense to me.  You want to know
> you are done or you can't do it.
Well, a machine is usable even without X, though admittedly much less 
useful than we'd like.  Where we do the X configuration depends on whether 
or not we want to try to do an X-based installer.  Even then, we should 
keep the real configuration to the very end.  I was just arguing against 
having the machine probe once to find out which card, install it, reboot, 
do other config stuff, then go off and do the same probing *again* to 
create xf86config.

> Good points, Erik.  Maybe it is worthwhile to break it up then.
If we can probe things well enough, we should be able to determine if a 
user has a funky set of hardware ourselves.  Otherwise we should provide 
the user with a full menu of all their hardware (like Win 3.1 does in the 
DOS-level setup), rather than push them through a serialized "do you have 
this" sequence like RedHat does.  That makes it user-driven (though we need 
to come up with some decent UI design to make it simple), allowing them to 
go back and select SCSI again to add the other card they have one of their 
disks on (for instance).

> Hey your out of my league.  Wish I had an ehternet connection to the net.
I have a laptop with an ether card that roams around a bit.  Right now I 
have to plug it in at work and go off and manually ifconfig the stupid 
thing.  A decent mobility suite is one of those many large projects I 
intend to work on eventually.

> You test it at work a few times.  If they decide to keep you,...
Actually, it wouldn't be that bad.  The vast majority of all subnets are 
24bit, so that's 254 requests, maybe 508 for good measure.  All the other 
requests are maybe a few packets each, and listening via tcpdump doesn't 
host the net at all.  And it's all kept behind whichever routers are on the 
net, so really all you're looking at is about 50KB of network traffic in 
total.  Since there are data dependencies anyway, this wouldn't just be 
dumped onto the network all at once, either.

> > 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.
> Don't be shy.
No, really, I haven't though very much about it...

> I went around with Jean-Francois many times on this.  Of course
> Jean-Francois is right Seul does not do kernel compiles.  But who can
> stop you from compiling a kernel if Linux is installed?
I think we should provide tools to make it easy to compile kernels.  In 
reality there isn't much to it.  The same logic applied to package 
selection can be used in configuring a kernel.  Many thing are required, 
there are only a few fundamental choices you need to make, and everything 
else follows from those.  We already know what hardware is on the machine, 
so select that and modularize everything else in case they add hardware 
later.  Ouptut a .config file, `make dep;make clean;make zImage modules`.  
Piece of cake.  I'm trying to get a friend of mine to build something to do 
that.

> Can you say MicroSoft Registry?
You're referring to the "Your registry is corrupted, please call support 
and ask them to tell you to reinstall your machine" prompt? :)

> We have a fallback model in the specification.
Yes, there is a fallback model to allow for the safe kernel to remain in 
place and boot with compatible modules.  I'm talking about a much more 
advanced fallback, that's in the -admin realm.  A kernel parameter passed 
on the LILO prompt that isn't used by the kernel ends up in both /proc/
cmdline and in the *environment* of /sbin/init, and thus all the rc 
scripts.  A fallback would trigger all the rc scripts to go into safe mode, 
which likely would not start any daemons, stay in single-user, maybe not 
even mount the root filesystem read-write.  It'd start a custom recovery 
app to determine what went wrong before continuing with anything else.

The case where someone just turns off the computer and triggers fallback 
mode can be detected relatively easily with a combination of the fallback 
parameter, a hosed filesystem, and possibly a missing lock file (say you 
create this lockfile *only* at the end of a clean shutdown).  You put up a 
dialog saying "hey bozo, try shutting down your machine *properly* next 
time, it'll boot faster and you won't be called 'bozo' again."  Or 
something a little less confrontational, I dunno...

> I really expect that the safe mode is going to be windows though.
Ergh...

> I am not sure that I follow you here.  Say linux is not shut down
> cleanly, then the user wants to start windows.  Is the boot record hosed?
The boot record is fine, but the case that's the problem is when the 
machine *is* correctly shut down.  lilo -R tells the machine to boot 
immediately into the named entry, leaving no time to chose something else.  
So that locks out all other OS's (not a bad idea...) unless you force a bad 
shutdown.  The solution is to make lilo -R set a default and still give you 
a prompt, etc..


     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