AdvancedPartitionerRewrite

Revision 3 as of 2006-06-05 12:36:54

Clear message

Summary

Rewrite Ubiquity's advanced partitioner, concentrating on usability and commonality of code.

Rationale

The use of gparted/qtparted in Dapper's live CD installer (Ubiquity) was expedient in terms of developer time, but it wasn't the long-term right answer. Using an external partition editor has many inherent problems, such as complex communication requirements with the rest of the installer, UI inconsistency between frontends, and behavioural inconsistency with the text-based installer and with autopartitioning. Furthermore, both gparted and qtparted are complex independently-designed C++ programs which require complicated patches to work in both standalone and installer mode; updating them has become a risky and time-consuming business, and fixing bugs can require investigating the design of both programs from the ground up.

To replace this, we will write a simple Python frontend to partman using ubiquity's standard debconffilter framework, with relatively small PyGTK/PyQt shims. The UI will be designed from scratch with an eye to usability, and will be sufficiently similar between the GTK and KDE frontends to offer familiarity.

Use cases

  • Judith has been using Unix for some time, and wants to install Ubuntu using a custom partition layout with separate /, /usr, and /var filesystems. She wants reasonably fine control over the sizes of these partitions, and wants to choose which filesystems to use for each.
  • Eugene has a number of different operating systems installed for experimentation, and wants to add Kubuntu to the list. To make room, he will resize one of his existing partitions and delete another.
  • Chris has been trying out both Ubuntu and Kubuntu, and is confused by the way the advanced partitioners are so different in each. He would like to be able to transfer his experience from one to the other.
  • James has a system with two hard drives that mirror each other using RAID1, to reduce the risk of data loss from drive failures; the hard drives are both much larger than he needs right now, so he uses LVM on these so that he can extend filesystems easily without having to set up the partition table perfectly first time. He would like to use Ubiquity to install Ubuntu on this system.

Scope

A successful implementation will provide a working and reliable advanced partitioner for both Ubiquity's GTK and KDE frontends that behaves similarly to that of the text-based installer but has a more attractive and better-designed UI, properly integrated into Ubiquity. LVM and RAID functionality is not required in a first iteration, but may be added later if time permits.

Design

partman, the partitioner used in the text-based installer, is a debconf application whose main control flow features a basic UI revolving around a select widget with one line per partition ([http://shots.osdir.com/slideshows/slideshow.php?release=658&slide=1&title=debian+installer+etch+beta+2+screenshots screenshot]). On selecting each partition, a submenu of information and operations that can be applied to that partition is presented, including method (format, keep existing data, other specialised uses), filesystem, flags (e.g. boot), create (when selecting free space), resize, delete, and others. Some of these operations cause further prompts to be presented, while others present the submenu anew with updated information and perhaps different operations.

partman's backend has been polished by use in one Debian and three Ubuntu releases, and while it certainly still has bugs they are generally relatively minor. partman's UI, on the other hand, while reasonably effective as far as it goes, is basic and can be confusing. Much of the confusion arises from the fact that it is not possible to cram all the available useful information into a single screen of text, and from limitations in cdebconf and its newt user interface that require partman to present select lists where in some cases buttons or other widgets would be more appropriate. Fortunately, these limitations do not apply to a graphical interface, and we already have the technology required to transform debconf protocol requests into a pretty good graphical user interface.

Driving partman

Any graphical user interface to partman is likely to require presenting information from the partition submenus up-front. As such, the Ubiquity partman component will on occasion (certainly on startup) need to navigate internally through all the available partition submenus and cache information about all of them; this can easily be done with the aid of a state machine. When the user performs an action in the user interface, the partman component will navigate to the proper partition submenu and select the requested action. When partman's update.d scripts are called for a particular partition, as happens following certain operations, the cache of information for that partition will be invalidated, and the partman component will need to reload it as soon as possible; some operations (such as deleting a partition) will update all partitions and so the cache will need to be reloaded from scratch.

While cache updates will take a little time to complete, the author expects that this can be optimised at need, and that the benefits of caching will render update times not generally a problem.

Implementation

Code

Data preservation and migration

Outstanding issues

BoF agenda and discussion

CategorySpec