[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] New "installer-settings" component - please test and comment!



On Tuesday 13 January 2009, Frans Pop wrote:
> Over the past months I've been working on a new component that allows
> to change "settings" for the installer. Main intention is to improve
> the flexibility of the installer and the user experience.

Not that much feedback, but I guess that was to be expected :-(
So, let me explain what this is all about.

There are several things that I've never really liked about the 
current "expert mode":
* default install offers too few options for quite a few users, but
  expert mode immediately goes to the lowest possible level: there
  is no graceful way to select intermediate levels
* medium priority (which I've personally always preferred over low
  priority) is effectively inaccessible to users and unused in
  practice
* showing the menu is coupled hard to priority levels, even though for
  debugging it would be quite nice if you could run an install at high
  prio but _with_ menu, and for "expert" installs it would be quite nice
  if you could run at medium prio but _without_ menu (as users in
  principle have no need to skip installation steps or change the order
  of installation steps)

Another issue is that we do have some specific options in D-I (PPPoE, 
dmraid, multipath) that I would personally like to see remain as optional 
features, but we currently don't have any user-friendly way to activate 
support for such option.

installer-settings is intended to solve all of these issues.

Flexible and gradual "expert" support
=====================================
In its current implementation installer-settings does *not* change default 
installs: no extra dialogs, no changes in the installation order.
Only if you back up to the main menu you will see a new option "Installer 
settings" that allows to change settings that are relevant at that point 
of the installation. It also allows to change the debconf priority and 
whether or not to display the main menu.

Expert installs are changed. A lot!

* Instead of 'priority=low' the syslinux config will now add
  'expert=true'. In other words: when the installer is started the
  priority is *high*, just as for a default install.
* localechooser checks this expert setting and if set displays its
  "medium prio dialogs" (e.g. locale selection) at high priority.
* After locale and keyboard selection a "early installer settings"
  dialog is displayed. This allows the user to select the "expert
  level" at which he wishes to continue the installation.
* After "anna" a second "installer settings" dialog is displayed.
  This will allow to change settings for components that were not
  available before anna and settings which will never be relevant
  during the early stages of the installation.

All this results in the following "modes" being available to users:
1) automated/preseeded install (critical priority): installer-settings
   is disabled
2) default install
3) expert mode:
   a) "default level": remain at high priority, but with option to
      change settings (for example: to activate dmraid support)
   b) same as a) but with main menu displayed between components
   c) "advanced level": medium priority, without main menu (by default
      it is displayed, but it can now be disabled)
   d) same as c) but with main menu
   e) could be implemented as either "expert level" or as "debug level";
      in either case: low priority (menu will always be displayed)
4) rescue mode

When this is implemented the priority level of some dialogs should 
probably be adjusted. For example: the grub password dialog should be 
displayed at medium priority.
Some existing dialogs could possibly be implemented as a "setting", in 
which case the priority of the dialog itself should be lowered to low 
priority.

Implementation
==============
installer-settings has a drop-in structure to add settings somewhat 
similar to partman. This means that the code that implements an 
individual setting can be part of the relevant component. Example: the 
settings for dmraid and multipath are implemented in disk-detect.

See /usr/lib/settings/*/ in the test images for examples.

installer-settings itself has absolutely no state info: it exclusively 
uses state (debconf values) from the component to which a setting 
belongs. This means that it does not interfere in any way with for 
example preseeding.

installer-settings itself consists of 4 udebs:
- installer-settings: core functionality
- settings-early: provides the settings menu entry after
  locale/kbd-chooser
- settings-anna: provides the settings menu entry after anna
- settings-menu: provides the permanent optional settings menu entry

Settings can be defined very flexibly:
- limit to settings-early/anna/menu
- only show at certain debconf priorities
- only show based on scripted logic ("choices" script)
- warn or don't show if certain installation steps have already been run

Settings can be coded to be changed either by just hitting <enter> on 
them, or by displaying a dialog.

Size impact
-----------
There is some size impact, but it is not huge. Normally all its udebs 
except for installer-anna should be included in the initrd, but 
debconf-priority is no longer needed. For images targeted at e.g. NAS 
devices settings-menu can probably be omitted from the initrd.

There are also some new strings, but most are short and most strings 
related to individual settings will only be loaded during anna. 
Implementing a setting will normally only require quite little code.

How further?
============
Given that the reactions I have had were positive and that I'm really very 
happy with how it's looking ATM, I intend to commit my changes and 
activate installer-settings for daily builds immediately after Lenny.

I will initially commit new strings without translations enabled to allow 
for review.

TODO
----
* Ensure i-s works correctly with auto mode.
  Including NAS installs (arm/armel/...).
* Somehow make kbd-chooser's medium/low prio dialogs accessible.
* i-s does not yet support changing to critical prio; possibly
  we only need an option to resume critical prio if the system was
  booted with it and somehow drops out of it.

Cheers,
FJP

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: