Re: FWD: mostly UI issues (Re: redesigning the debian installer)
On Thu, 14 Sep 2000, Joey Hess wrote:
> 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."
I think a reasonable solution is to devote some time to doing a sanity
check on the debconf DB, instead of blindly doing what is indicated and
trying to catch an error after it has occurred.
e.g., If every package (normal or installation module) has an
Installed-Size, the DB builder can check to make sure everything will
fit in the allocated space. Devices that specify IO ports, IRQs, etc.
can be checked for resource conflicts. etc.
This will not eliminate all the problems, or obviate the need for a
robust installer, but it should catch the really silly errors before
they become a problem.
IMO... A non-integral part of the installation process should be where
the user defines what the system will consist of. The DB generated
should be checked for consistency and the md5sum of the file containing
the DB should be stored someplace, when the installer fires up it should
check the md5sum and re-verify its consistency of the DB if they don't
match. If it is not possible to re-verify the DB (can't load the module
that does the checking or some required external info is unavailable)
the user should be warned of that fact and either the installation
proceed as normal (unless the DB contains a flag that specifies the
installation should not proceed without a verified-for-consistency-DB)
or the user be given a chance to redefine what is in the DB. Since it
may be possible to have the DB spread out over many files in different
locations, the consistency check would need to be performed by debconf
on the results of concatenating and/or overlaying all the pieces.
This scheme is not bulletproof, but I think it is a step in the right
direction.
later,
Bruce
Reply to: