[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments re: SEUL installer (long)
> 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
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
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
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
> 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
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
> Seul and Apache? Boggles my mind. Another reason for this discussion,
> flexibility and refinement, the SEU's seem to have a lot off diverse
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
> 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
> 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
> 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.
> 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 <email@example.com> - SEUL Project system architect
/ \ SEUL: Simple End-User Linux -
| | M E G A Creating a Linux distribution
_\ /_ for the home or office user