This manual is free software; you may redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version.

This is distributed in the hope that it will be useful, butwithout any warranty; without even the implied warranty of merchantability or ﬁtness for a particular purpose. See the GNU General Public License for more details.

A copy of the GNU General Public License is available as /usr/share/common-licenses/GPLin the Debian GNU/Linux distribution or on the World Wide Web at the GNU website (poc/gro.ung.www/mlhtl.gpt/efyltp:/ht). You can also obtain it by writing to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA

There are many wishlist features that we might desire from any installer of GNU/Linux and that are related to partitioning:

• The partitioner should support different ﬁle systems. Some of them need more care than only libraries and suitable arguments formount. • It should support not only regular partitions but also software RAID and LVM as well as encrypted ﬁle systems. • It should be able to partition disks automatically and allow the user to inspect and cus-tomise the automatical partitioning latter. • It should be able to resize partitions and move their contents from one place to another. • The users should be protected from mistakes — by allowing them to undo their parti-tioning operations. • The partitioner should discover that there is already some installed GNU/Linux system and analise itsfstab,passwd, etc. in order to provide automatic upgrade from the old already installed installed GNU/Linux system to the new one.

One nice feature of the Debian installer is that it is modular. Its components are packaged in separate udebs and they can have relatively independent development process. This document describes how we can solve all mentioned tasks keeping the Debian installer as modular as it is now. Ideally in order to add some new feature only few new udebs must be all that is needed — no changes in the existing udebs and no recompilation. The scriptpartmanfrom the packagepartmanopens the main partitioning menu; it may look like this one:

responsible for pure partitioning operationgs such as creation of new partitions and dele-tion. The packagespartman-targetandtramapdshoetcmsiban-are responsible for the items ‘Choose how this partition should be used’ and ‘Choose a ﬁle system’. The package partman-basicfilesystemsadds support forext2,linux-swap,fat16,fat32and (future version)reiserfs. The packagepartman-ext3adds support forext3.

Chapter

1.

Introduction

4

Chapter 2

Package interrelations

2.1 Basics

5

The GNU Parted disk partitioning library provides high-level, architecture independent func-tions for operations such as creating, deleting, resizing and moving of partitions as well as creating some kinds of ﬁle systems. Most of the functions of libparted work in a non nonde-structive way. The partition table is written in data structures and any change in the partition table happens only in these data structures rather than directly on the disk. This makes possi-ble to implement partitioning tools based onlibpartedthat support undoing of the editing operations. However we have to solve two problems. The ﬁrst is that we want to use as much as possible shell scripts rather than C programs. The second is that different programs have to operate with same instance of libparted structures. For example the user can use some tool for auto-matic partitioning, then correct or customise the automatic partitioning, perform some other arbitrary operations being still allowed to undo everithing. There is one obvious solution of these two problems — we keep the data structures of lib-parted in a daemon process and communicate with it in order to make changes in these data structures. This process is/bin/parted serverfrom the packagepartman. _ The scripts from/d./aptril/bnitiam/nare executed before all partitioning operations. They can be used to initialise the partitioning system. The scripts may be invoked more than once in which case they should behave properly. For example this directory can contain a script to discover the existing hard drives. If invoked for second time the script must either do nothing or check if there is some new kernel module giving access to new still undiscovered device. Any udeb may install a script in this directory. For example the script/lib/partman /init.d/30partedfrom the packagepartmanis responsible to runparted server. No-_ tice that the scripts are preﬁxed by a two-digit number. This number determines the order the scripts are executed. If some of the scripts exits with non-zero exit code the partitioning will be aborted. This means that in almost all cases these scripts must end with exit-code 0.

Chapter 2. Package interrelations

6

While the user is modifying the partitions this happens only in the memory of the computer and not in the edited devices. This is because almost all changes happen either in the data-_n the installers ram-disk. T we can provide hy structures ofparted serveror in ﬁles i hat’s w the user with the option to undo everything. When the user chooses to undo the scripts in the directorydo.d//il/baptram/nnu udeb may install a script in this di- Anyare executed. rectory. For example the script/litear0p/3damtrap/bd.odnu/nis responsible to restore _ pts fromost cases crundo.d the contents of the data structures ofparted server the. In m i s must exit with exit-code 0. If some of the scripts exits with non-zero exit code the partitioning will be aborted. In order to perform the editing operations on the storage devices (and in particular to trans-fer the partitions from the internal data-structures ofparted_serverto the hard disks) the scripts from the directorynamtmoc/bil/rap//dim.t order in which these Theare executed. scripts are executed is determined again by two-digit preﬁxes in the script names. Every script fromcommit.dis guaranteed that the scripts ordered before it have been already executed. However if some of the scripts exits with non-zero exit-code the execution of the scripts in commit.dwill be stopped. In this case the partitioning will continue and the user is expected to ﬁx the problem. If some script exits with non-zero exit code it is supposed to inform the user what went wrong using debconf. There are two cases when the scripts fromcommit.dare executed. The ﬁrst case is when the user wants to commit the changes to the disks but continue partitioning. The second case is when the partitioning ends. In the ﬁrst case if none of the scripts fails the scripts frominit.d will be also executed and the user will be returned to the partitioning dialog. In the second case the scripts fromfinish.dIn both cases if some of the scripts inwill be executed. commit.d fails the user will be returned immediately back to the partitioning dialog. The scripts fromn/martpa.dshnifi/il/b/are responsible for ﬁnal tasks such as to mount partitions on/target, generate offstab, stopparted_serveretc.1If some of these scripts exits with non-zero exit-code the execution of the scripts will be stopped. If the exit-code was 1 then the user will be returned back to the partitioning dialog and is expected to correct the problem. If the exit-code was neither 0 nor 1 then the partitioning will be aborted. For every hard disk in the system the scriptrap03/d.detlib/partman/init/creates a subdirectory invicen/des//ril/avtram/bapand informsparted_serverthat the de-vice is to be edited (‘opens’ the device). All udebs that provide storage device (software RAID, LVM, encrypted partitions) must do the same. This subdirectory must contain at least three ﬁles —device,modelandsize. The ﬁrst contains the name of a device ﬁle (for exam-plec/dis0nul/0tegrat/0su/bt0os/hde/iev/d second contains the name of the). The device (for example ‘Maxtor 6Y120L0’). The third contains the phisical size of the storage device (in bytes, for example ‘122942324736’).2The subdirectories of/var/lib/partman 1What tasks will be performed depends on what udebs are unpacked. If the packages respon-sible to mount partitions and create fstab are not unpacked we have only a simple partitioner pro-vidingpartitioned-harddrives they are unpacked they provide also. Ifmade-filesystemsand mounted-partitions. 2storage ‘devices’ that can not be partitioned (such as net-Please notice that udebs that provide support for worked ﬁle systems) should not create a subdirectory in/var/lib/partman/devicesand certainly can not provide the device to the management ofparted_server.

Chapter 2. Package interrelations

7

/devices/ We call these subdi-can but are not obligated to contain additional information. rectoriesdevice directories. Every partition in a device managed byparted_serveris given an unique name hav-ing the formﬁrst_byte-la _ ytename can be used to determine where the parti-. This st b tion starts and where it ends.3If the device directory contains a subdirectory named _ _pehtitraanyoritsueorboirbdtoecotnhteinesu.iWs first byte-last byteth st informat call this subdirectorydirectory of the partition call the string. Weﬁrst_byte-last_byte‘id’ of the partition.

2.2 Menu-directories

There are several menus involved in partitioning. Inorder to keep the Debian installer modular and extensible we want to allow every udeb to install items in these menus. Let we be more speciﬁc. When the users decide to format some existing partition we need a menu with an item for every supported ﬁle system. Obviously we don’t want to hardwire the list of the supported ﬁle systems in any place of our installer. If we want to add support to the installer say for XFS or UMSDOS ﬁle systems, only few new udebs must be all that is needed. In order to achieve this ﬂexibility the packagepartmanprovides support for the so caled menu-directories. Every such a directory contains ﬁles namedquestionandpriority. They contain the name of a Debconf template and the priority of the question correspondingly. The template must have exactly the following type and choices ﬁelds:

Type: select Choices: ${CHOICES}

All other ﬁles in the menu directory are subdirectories. Any udeb can install such a subdirec-tory in order to add items to the menu. For example the udebs for software RAID volumes can install in the menu of the editing operations an item to resize the choosed partition to have the same size as another. These subdirectories must contain two scripts —choices anddo_optionof the ﬁrst script is to print menu items. purpose . The every menu item For choicesmust print a line having the form

_ _ menu item id<TAB>The text for the user

The scriptchoices Inis allowed to print nothing. this case no item for the menu is created. Here<TAB> The text ‘The text for the user’ will be presented to the users. If theyis ASCII 9. choose this particular menu item the scriptdo optionwill be invoked. _ The scriptchoicesarguments depending on the particular menu-may be given some directory. The ﬁrst argument given todo_optionis always themenu item idof the _ _ 3Unlike one can supposeparted_serverand places in bytes rather than in sectors.always measures sizes Last_bytebyte of the last sector of the partition.is the number of the last