FWD: mostly UI issues (Re: redesigning the debian installer)
I just realized this didn't go to debian-boot. Whoops.
----- Forwarded message from Joey Hess <joey@kitenet.net> -----
From: Joey Hess <joey@kitenet.net>
Date: Wed, 13 Sep 2000 19:20:22 -0700
To: "Bernhard R. Link" <brl@pcpool08.mathematik.uni-freiburg.de>
Subject: mostly UI issues (Re: redesigning the debian installer)
Bernhard R. Link wrote:
> > The install begins with a bootloader. It is unlikely that this will change
> > significantly from what is used now.
>
> It would be very much convenient, if there would be a possibility to
> install if from an client over the network without the need of an
> boot-disk.
> I think it would be on of the most bottom parts of the todo-list, and it
> propably will not affect on the way the installation is done, but it would
> be nice to have it on the todo-list and have a short look on it to ensure,
> that it realy would work with the whole system.
I said it would start with a bootloader, didn't specify what type of boot
loader. :-)
If we eventually want to add support for systems that can load by tftp
or whatever, I don't really see how it's going to impact the design.
After all, I haven't messed with the normal kernel boot process at all.
> > After the kernel boots up, the first thing the user will see is whatever UI
> > is being used, configuring itself. This is equivalent to the current
> > installer asking if the screen supports color, and keyboard configuration.
> > It might also include language selection, mouse setup, etc. All up the
> > individual UI.
>
> How is determined which ui to use?
> Could it be (additionaly to other ways) be choosen with an Env-Var on the
> boot-up prompt.
> Or would there be only one ui in the system, and the person making
> the install-floppy/zip/cdrom choses which one to install?
I can think of a few possibilities. As a degenerate case, if there is
one UI, it will be used. If there are multiple UI's, they could
prioritize themselves somehow, and each could be asked in turn to set
itself up. If setup failed, fall back to the next UI. FWIW, perl debconf
uses a similar method to pick between the UI's it can use, and it works
quite well.
I've added some stuff related to this to TODO in cvs.
> I like this way ver much, too, and personally would not like to use
> anything else. But I have seen people beeing disturbed and/or confused by
> that many freedom. It should either be well tested, that you come to an
> running system finally, when you wildly choose randomly. Or some question
> before, if you want an more direct way. (With std-answer no and an
> priority low enough.
I don't think we can guarentee that one can feed random input into the
installer and get a working install. That's a little ridiculous.
On the other hand, there should be enough sanity checking that the
install is not allowed to _complete_ until the random input happens to
work. (Of course, they may just decide to reboot half way through.)
And we can work as hard as we can to ensure that everything has a default
answer that is as good as possible. The current debian installer really
exemplifies this and shows it can be done, IMHO.
Also, remember the little aside I wrote about making the menu be
skippable so the install happens in a linear mode, with whatever would
be the default menu item being picked each time. This will be hard. We
will have to avoid loops that they can't break out of. I'm not sure yet
if it will really be possible to do it robustly.
I've been thinking about this some more, and I have came up with some
places where my design breaks down. For example, suppose the menu
includes:
- partition a hard disk
- format and mount partitions
- install base system
But it is not being displayed, the user is just being taken from step to
step in linear mode.
- The user partitions a hard disk, and makes some really dumb choices.
- Partitions are formatted and mounted.
- The base system fails to unpack, because they have a 1 mb /usr and a
5 gb /usr/local.
Now we're in a situation where the first two steps think they have been
completed satisfactoraly, and the third step knows its failing. We
really need to back the user up. How can we do this?
(I'd like to know how boot-floppies deal with this now, and I'll
probably do some tests tomorrow to see, if nobody knows off the top of
their head.)
> I think the user will get an debconf-frontend there, too, to ask the
> questions. I think it would be nice, if the kind of ui in the
> base-install could be committed to the full-install some kind.
Yes, we will have a mechanism to pass stuff between the two debconf's.
Probably just pass in the entire database we generated in the installer.
This is already done to a very limited degree in the current
boot-floppies, BTW.
> > Each item in the list is provided by an installer module. To create the
> > list item, a module must only drop a control file with a unique name into
> > /usr/lib/debian-installer/menu/. The control file is rfc-822 format, and
> > should have the following fields:
> > Priority: a number, which determines where the item appears on the menu
> > Prog: the program to run if this item is selected
> > TestProg: a program to run to determine if this menu item should be the
> > default item
> > Description: the text to appear on the menu
>
> Perhaps when saying "no" when asked about the menu, there could be a
> question about some script or so to start. (So that you can archive the
> things in the menu also by without local interferance).
I don't understand.
--
see shy jo
----- End forwarded message -----
--
see shy jo
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: