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

Buts about partman [LONG]



Contents
--------

1. Partman and graphical installer
2. Second generation partman-lvm, partman-md and partman-crypto
3. Issues with the boot partitions in partman-auto (Yaboot, Palo, etc.)


1. Partman and graphical installer
----------------------------------

I never tried the graphical installer (only looked at screenshots from
time to time) but I can imagine that partman is looks oughful.

In the main screen of partman, it uses spaces in order to align
columns.  Obviously this doesn't work in g-i since there the font is
proportional.  Partman also trunkates fields when necessary, this
shouldn't be done in g-i.

I have no idea how debconf works, but here is what parman can do
easily in order to improve the situation.

  (1) db_capb align

If debconf answers that it supports 'align' capability, then partman
is going to use the Select template in a different way.

  (2) The first "choice" in 'align' mode is not a real choice, but a
      line of titles of the columns that follow.  The names are
      separated by a special delimiter (such as '$$')

  (3) The next choices are the real choices.  They also use this
      delimiter between fields.

I suppose the users should be allowed to resize the width of the
columns by moving the boundaries between the titles of the columns
with the mouse.

  (4) However not all lines will use these delimiters.  Such lines
      should not be affected by resizing the columns.

  (5) I suppose currently g-i tryes to detect the branches of the
      choices tree (Options, Disks, Partitions).  However I'd prefer
      if g-i does no guessing about such matters.  It will be better
      if partman uses special character combinations in order to tell
      what is what (if cdebconf has 'align' capability).

I found this image: http://people.debian.org/~lunar/disk-widget.png.
If you want to display such graphical representations of the disks and
partitions (this would be great) I'd suggest the following format of
the choices for partitions:

level$1$$size$48903$$firs field$$second field$$third field$$...

Here the special 'field' size$48903 tells the frontend that the
relative size of the partition is 48903.  (And level$1 says that this
is a partition, not a disk. The choices for disks can start with
level$0.)


2. Second generation partman-lvm, partman-md and partman-crypto
---------------------------------------------------------------

In the past I wrote partman-lvm for only 2 days as a demonstration
what partman can do.  At these days partman-lvm relyed on an external
utility (lvmcfg).  Now lvmcfg is integrated in partman-lvm, but it is
known that the implementation suffers from many problems.  (And it is
a pity that later partman-md and partman-crypto reproduced the same
structure so they suffer from the same problems.)

First, this is how the main partitioning meny has to look:

   Volume group #1
        physical volume in VG1
        another physical volume in VG1
        another physical volume in VG1
   Volumen group #2
        physical volume in VG2
        another physical volume in VG2

Currently the user can select a logical volume and remove it as if it
was an usual partition which is stupid.

This is how partman-lvm has to do things:

   1. The user goes to a partition and selects "Use as: logical volume"

   2. In the same meny the user selects an existing or a new volume
      group.  (Notice the analogue between "Use as: ext3" and "Mount
      point: /usr")

   3. If this was a new volume group it appears in the main screen as
      disk.

   4. The user selects it and a dialog appears "This volume group is
      not currently active.  You can choose to activate it but then no
      further changes in the partition table of the disks which
      contain physical volumes for it will be possible.  Or you can
      choose to finish the partitioning first and come here later."

   5. The user chooses "Activate!", the partition tables are written
      to the disks and the volume group is activated.

   6. Now the user sees a menu with information about the logical
      volume and choices "Create new logical volume", "Deactivate the
      volume group" and maybe "Delete this volume group
      (irreversible)".

   7. The user chooses to create a new logical volume, gives it a
      name.

   8. The new volume appears in the main partitioning screen as a
      "partition" inside the volume group.

   9. The user selects a logical volume.  The usual menu for a
      partition appears, only "Delete the partition" is replaced by
      "Delete this logical volume".

   10. The user selects a physical volume and changes its volume
       group.  The partition computes the sizes and responds with
       either "The rest physical volumes are not enough to embrace the
       data of the volume group.  Do you want to delete (irreversible)
       the volume group and all logical volumes in it?" or "The data
       from ... is going to be moved to other physical volumes.  This
       is slow, do you want to start this now?"

I want to try to rewrite from scratch partman-lvm, but I have a
question. I'd like to name the new package partman-lvm2. Is this ok?


3. Issues with the boot partitions in partman-auto (Yaboot, Palo, etc.)
-----------------------------------------------------------------------

Some boot loaders require a special partition. Problems:

1. partman-auto creates a new partition even if there is already one;

2. partman-auto doesn't know anything about the specific requirements
   of this partition (size, placement on the disk)

3. We have too many architecture-specific recipes (IMO unmaintainable)
   and for some of them it is not even obvious why they exist.

Solution: Do not create new architecture-specific recipes. Instead the
boot loaders should install a plugin in partman-auto which causes it
to create the special partition first and only then to perform the
recipe.  I think I am going to describe a method somewhere, maybe
partman-doc.sgml, but I am not going to do any implementation since
this is not a i386 problem. (Well, I could test a solution on i386
too, but I think don't have free time for this.)


And finaly, maybe some of you are going to ask me if I am returning to
the d-i team?  I think I can do only what I wrote in this email,
nothing more.

Anton Zinoviev



Reply to: