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



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

Anton Zinoviev

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,
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

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.


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
$STORAGES/parted/active_partition/30change_name/choices is:


# Some necessary functions provided by partman-parted:
. $STORAGES/parted/partman-parted-functions.sh

# First let we see if this partition label supports partition names
open_dialog  USES_NAMES
read_line x

# 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:


. $STORAGES/parted/partman-parted-functions.sh


cd $DEVICES/$dev

# 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
db_get partman-parted-partitioning/set_name

# Here we set the new name.
open_dialog SET_NAME "$id" "$RET"

Reply to: