Re: FWD: mostly UI issues (Re: redesigning the debian installer)
I wrote:
> 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.)
Just tried this. It is indeed possible to make dbootstrap have "install
os kernel and modules" as the next step in the menu, and nothing
helpful as previous and alternate steps, and each time you pick the
default it loops[1]. There's also no error message, so you have to guess
that your partitioning is screwed up. I don't think this is a big
problem in dinstall, though it could handle it better.
If the new installer has the same problem, the effects will be:
- In a normal install like dbootstrap's menu now, no different than with
dbootstrap.
- In an install in "linear mode", where there is no menu, an infinite
loop, as the step keeps being run and failing. Yuck.
- In a noninteractive install, the same thing as in linear mode.
Although it would take some real effort to get through a normal
install successfully, feed the recorded debconf data back into a new
install, and have the new one fail. It could happen though.
The linear mode case bothers me. Trying to think about how the installer
could detect and fix it..
It could detect looping items[1]. The fix is always going to be to back the
install process up to some previous item that went wrong, and let the
user correct it. (If this isn't the fix, we're pretty well screwed.)
The problem is figuring out what step to back up to. We could add a lot
of code to each failure case of each step that figures out why it
failed, and what step to go back to (ran out of disk space, go back to
partitioning, etc). We could just jump all the way back to the very
first step every time something goes wrong.
Well it looks solvable but I don't like either of the solutions.
Oh, if we're in linear mode and something goes wrong, we could simply
leave linear mode. "You broke it, you fix it."
--
see shy jo
[1] I can do it by really messing up the disk partitions. I can also do
it by configuring the network, unplugging my ethernet cable, and
telling it to do a network install.
[2] Would probably have to detect cycles of more than one item as well.
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: