A few week ago I wrote about my intentions to write a Debconf frontend
for parted. The result is a program that can serve not only as a
partitioner but for many other purposes. I expect to have less time
for coding this month so maybe it is time to publish what I have
done. It is at http://people.debian.org/~zinoviev.
I wasn't able to test these udebs because I don't know how to satisfy
the library requirements of partman-parted. Maybe I have missed
something in the documentation of d-i or this is not documented. I
have dane tests mostly as non-root -- look at the directory test. I
discovered that parted has several bugs when it partitiones regular
files instead of disks, so you may find some problems if you try
partman as non-root. It seams however that there are no such problems
when parted partitiones real hard disks.
The Debconf templates contain rather terse messages. They contain
dots instead of spaces because Debconf deletes spaces (and it does
this also for the non-break spaces U+00A0). I don't know what is the
behaviour of cdebconf. All priorities are set to high but most of
them have to be critical. There is no internationalization in this
version. On the other hand the software is already able to partition
the hard disks.
The documentation is very incomplete, but I will work on this. It is
in the README file. For your convenience I have attached it to this
The main task of partman is to allow the user to perform various
`editing' operations on things that can store file systems.
The available editing operations are different depending on the
installed plugins. For example a plugin can provide partman with
operations for creating and deletion of partitions in which case
partman is simply a partitioner. But it is possible also to create a
plugin that provides operations to create file systems or assign
mount points. These filesystems don't need to be on phisical
devices -- it is possible to create plugins for LVM or software RAID
Because of this flexibility the udebs for partman and its plugins
don't provide any menu items for main-menu and don't provide any of
the virtual packages created-fstab, mounted-partitions,
made-filesystems, partitioned-harddrives by themselves. They do this
indirectly by empty meta-packages. For example the udeb
`partman-partitioner' provides partitioned-harddrives and menu item to
partition the hard drives. The postinst of this meta-package simply
invokes partman and it depends on partman, partman-parted and
partman-parted-partitioning -- the last two udebs are plugins for
partman that allow to partition the hard drives.
Now a short review of how partman works follows.
Its first task is to initialize the environment variables PARTMAN,
STORAGES, OSES, TEMP, MNT, DEVICES and PARTITIONS. The values of all
these variables are directories.
PARTMAN. This value of this variable is the directory that contains
all components of partman. Currently this is /lib/partman.
STORAGES. This directory contains all storage plugins. Currently
this is /lib/partman/storages. The main storage plugin is
partman-parted which discovers the existing hard drives
and allows the user edit them.
OSES. This directory contains all OS-plugins, i.e. plugins for
operating systems. One of the tasks for such plugins is to
give expressive names of the partitions (such as `Debian
GNU/Linux (/dos), FreeDos (C:)). The more advanced plugins of
this kind can analize files such as /etc/fstab and /etc/passwd
and use this information in order to allow automatical upgrade
of some existing Unix-like system to Debian.
TEMP. This is a directory where partman and its plugins are expected
to create theirs temporary files. Currently this is
MNT. Currently this is $TEMP/mnt.
DEVICES. This directory contains the `devices' that the user will
edit. For each such a `device' there is a subdirectory in
$DEVICES. These subdirectories are created by the storage
plugins during their initialization. Usualy each storage
plugin creates one subdirectory of $DEVICES. A notable
exception is partman-parted that creates one subdirectory
for every hard drive in the system. On the other hand a
plugin that allows installation on remote filesystems will
create no subdirectory of $DEVICES if the connection to
other computers is impossible for some reason. Currently
PARTITIONS. Currently PARTITIONS=$TEMP/partitions. This is a sort of
database of the things that can contain filesystems.
Usualy these `things' are partitions but they can be also
LVM or RAID volumes.
The second task of partman after it initializes beforementioned
variables is to initialize its plugins. Firstly it invokes the init
script of each storage plugin. The init script creates subdirectories
in $DEVICES and $PARTITIONS:
for drv in $STORAGES/*; do
[ -d $drv ] || continue
The OS-plugins have two initialization scripts. The first of them
($OSES/*/test1) is invoked several times. Each time some of the
partitions will be mounted on $MNT and the test1 script will have the
chance to analize if this partition contains the corresponding to the
plugin operating system. Afterwards the script $OSES/*/test2 is
invoked. No partition is mounted at its invocation, but this script
is able to mount temporary whatever it likes.
At this stage the initialization of partman is completed. The last
thing to do is to display the main menu of partman. For each device
in $DEVICES there is one item. There are also two special items
`Undo all changes' and `Commit changes and exit'. All editing
operations are supposed to be reversible. The user can delete
partitions, create filesystems, etc. but all this actualy happens
only when partman exits and before that time the user is always able
to undo all changes in which case no data will be lost.
THE DIRECTORIES UNDER $DEVICES
Every subdirectory of $DEVICES is created by the init script of some
storage plugin. Every such a subdirectory must contain the following
abort. Partman invokes this script when the user aborts it. All
editing operations are invalid and should be abandoned. This
script has only two tasks: to clear the temporary files and
to kill the spawned processes (if any).
commit. Partman invokes this script when it exits normaly. It has to
make actual the performed by the user editing operations --
delete partitions, created new partitions and file systems,
resize partitions, etc. Afterwards this script deletes the
temporary files and kills the spawned processes.
edit. Partman invokes this script when the uses chooses the
corresponding menu item.
name. This file contains the name of the menu item. For example
this could be `IDE1 master (120 GB; Maxtor 94098U8)'.
undo. Partman invokes this script when the user wants to undo all
operations. This script doesn't have to restore the original
contents of the subdirectories of $PARTITIONS because partman
has made a backup copy of them.
This is the most important storage plugin. It is responsible for all
devices that parted can detect, namely the hard drives. For each hard
drive this plugin creates a subdirectory in $DEVICES. This
subdirectory contains tho FIFOs -- infifo and outfifo. The scripts of
partman and its plugins use these FIFOs to communicate with a special
server process. This server serves as a mediator between the shell
scripts and libparted.
When the user chooses a hard drive in the main menu of partman,
partman invokes the edit script of this hard drive
($DEVICES/..../edit). This script displays a menu. For each
partition and each free space in the disk there is a menu item. There
is also a special menu item `Create new empty label (partition table)
on this device'.
Because the partman-parted storage plugin is so general, the editing
operations the user can perform are packaged in other udebs. For
example partman-parted-partitioning provides the following editing
operations: create new partition, delete partition, change the flags
of partition and change the name of partition (the last is only for
Macintosh disk labels).
In order to achieve this, partman and its plugins often use the so
caled menu-directories for theirs menus. One such a directory is
$STORAGES/parted/active_partition. It represents the menu that
partman-parted displays when the user chooses some partition in the
menu of partman-parted. The file question in this directory contains
the name of the Debconf template (in this case this is
partman-parted/active_partition). All other files in the
menu-directory are subdirectories. Any udeb can install such a
subdirectory. (For example the storage plugin for software RAID
volumes can install an item to resize the choosed partition to have
the same size as another.) These subdirectories contain two scripts
-- choices and do_option. The first script prints menu items. The
second is invoked if the user chooses an item printed by the first
script. For example the contents of
# Some necessary functions provided by partman-parted:
# First let we see if this partition label supports partition names
# If yes, then output the menu item `Set the name of the partition'
if [ "$x" = yes ]; then
printf "setname\tSet the name of the partition\n"
# Otherwise output no menu item.
The contents of the corresponding dp_option script is:
# First let we see what was is the current name of the partition
open_dialog PARTITION_INFO $id
read_line x1 id x2 x3 x2 x3 x4 old_name
# Then we ask the user for a new name
db_fset partman-parted-partitioning/set_name seen false
db_set partman-parted-partitioning/set_name "$old_name"
db_input high partman-parted-partitioning/set_name || true
db_go || exit 1
# Here we set the new name.
open_dialog SET_NAME "$id" "$RET"