Help!

Buts about partman [LONG]


Post new topic   General Reply to Topic (not reply to a specific post)    Forums Home -> Booting RSS
Next:  tzsetup_0.18_i386.changes ACCEPTED  
Author Message
Anton Zinoviev
External


Since: Nov 12, 2004
Posts: 163



PostPosted: Thu Jul 26, 2007 12:40 am    Post subject: Buts about partman [LONG]
Archived from groups: linux>debian>maint>boot (more info?)

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


--
To UNSUBSCRIBE, email to debian-boot-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org
Back to top
Otavio Salvador
External


Since: Dec 01, 2004
Posts: 587



PostPosted: Thu Jul 26, 2007 2:30 pm    Post subject: Re: Buts about partman [LONG] [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

Anton Zinoviev <anton.TakeThisOut@lml.bas.bg> writes:

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

Why don't do that in your people branch and then we produce some
images for testing and merge it all when done?

While I don't see any problems in producing this lvm2 udeb I fail to
see any pros for it. I personally thing that the people branch approch
is better if it works for you.

--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio.TakeThisOut@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."


--
To UNSUBSCRIBE, email to debian-boot-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org
Back to top
Otavio Salvador
External


Since: Dec 01, 2004
Posts: 587



PostPosted: Thu Jul 26, 2007 2:40 pm    Post subject: Re: Partman and graphical installer [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

Jérémy Bobbio <lunar.RemoveThis@debian.org> writes:

>> 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 don't see any real issue in implementing such solution from my
> experience in the GTK+ frontend code.
>
> But I wonder if the right way is to hack on select semantics instead
> of maybe adding a new specific question type. The plugin infrastructure
> of cdebconf enable us to do so quite easily, actually.

I personally prefer a new question type. This can be useful to other
places of installer and we should avoid doing hacks where it's
possible.

> One real question though: getting "align" to work in partman might be
> done quickier than what I can imagine right now; should we switch to it
> first before trying to get even better?

When you say: "... get even better?" you mean improve the current
installer widgets and like?

--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio.RemoveThis@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."
Back to top
Goswin von Brederlow
External


Since: Nov 20, 2004
Posts: 924



PostPosted: Thu Jul 26, 2007 4:00 pm    Post subject: Re: Buts about partman [LONG] [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

Otavio Salvador <otavio.TakeThisOut@debian.org> writes:

> Anton Zinoviev <anton.TakeThisOut@lml.bas.bg> writes:
>
>> 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?
>
> Why don't do that in your people branch and then we produce some
> images for testing and merge it all when done?
>
> While I don't see any problems in producing this lvm2 udeb I fail to
> see any pros for it. I personally thing that the people branch approch
> is better if it works for you.

I missed the start of the thread so I'm sorry if I repeat ideas
already mentioned.

It would be nice if each lvm VG would appear as a single disk in
partman and you could use the normal create/delete/resize partition
just as on a normal harddisk. The current way showing each LV as one
disk with one partition is not nice and it seems you can't get back
into configure lvm later to change some LVs.

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-boot-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org
Back to top
Otavio Salvador
External


Since: Dec 01, 2004
Posts: 587



PostPosted: Thu Jul 26, 2007 8:40 pm    Post subject: Re: Partman and graphical installer [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

Jérémy Bobbio <lunar.RemoveThis@debian.org> writes:

> I can't really be more precise as I would like to experiment with
> prototypes first. Smile Probably having something I could imagine as the
> "ideal interface" and then do the required changes to fit it within
> partman...

The align plugin would be useful for others questions like language
and keyboard so I think it's a good tradeof to get it implemented
first.

What others thing about it?

--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio.RemoveThis@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."
Back to top
Anton Zinoviev
External


Since: Nov 12, 2004
Posts: 163



PostPosted: Fri Jul 27, 2007 12:00 am    Post subject: Re: Partman and graphical installer (was: Buts about partman [LONG]) [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On Thu, Jul 26, 2007 at 03:14:41AM +0200, Jйrйmy Bobbio wrote:
>
> > (4) However not all lines will use these delimiters. Such lines
> > should not be affected by resizing the columns.
>
> That is going to be a lot trickier to implement in GTK+, AFAIK.
> Although, really easy in the web frontend. Smile

It is possible that it is very difficult fix (4) in partman. Or maybe
not, I don't know.

Currently the format of the partition lines depends of the type of the
partition tables. The partition table on i386 has primary and logical
partitions, on the other hand almost all non-i386 partition tables
have no such notion. On macintoshes the partition table has partition
labels, on i386 there is no such notion.

I suppose this will be OK if all disks on the system have the same
partition tables but what should we do if one of the disks has msdos
partition table and the other is mac? Things become even more
complicated if we take into account LVM, Raid and encrypted volumes.

> My initial thoughts about implementing a graphical partitioner was
> to use a custom debconf question type. As, IMHO, string manipulation in C
> should be avoided whenever its possible, I would prefer partman to feed
> the plugin values in the easiest format for the later.

On the other hand partman is already very slow...Smile

Each of the plugins of partman provides the core of partman with
information that can be encoded in a way similar to what I described.
This is so to say the protocol between the plugins and the core and
can not be changed. If you need something different, the information
has to be converted either by the core of partman or by the frontend.

What about a code like the following?

The variable 'choice' is supposed to has a value like this (each field
is terminated by '\t' and '\b' marks the special fields):

FIELD1\tFIELD2\t\blevel:N\tFIELD3\t\bsize:N\tFIELD4\tFIELD5\t

char *p, *q, *r;
int n, m;
char *fields[MAXFIELDS];

n = 0;
p = strdup(choice);
while (*p != '\0' && strchr(p, '\t') && n < MAXFIELDS) {
if (2 == sscanf(p, "\blevel:%i\t%as", &m, &q)) {
tag_level = m;
free(p);
p = q;
continue;
}
if (q) free(q);
if (2 == sscanf(p, "\bsize:%i\t%as", &m, &q)) {
tag_size = m;
free(p)
p = q;
continue;
}
if (q) free(q);
if (*p != '\b') {
m = sscanf(p, "%a[^\t]\t%as", &q, &r);
assert((m == 2) && q && r);
fields[n] = q;
n++;
free(p);
p = r;
continue;
}
{
# unknown tag, skip it
m = sscanf(p, "\t%[^\t]%as", &q, &r);
assert((m == 2) && q && r);
free(q);
free(p);
p = r;
}
}
free(p);

> One real question though: getting "align" to work in partman might be
> done quickier than what I can imagine right now; should we switch to it
> first before trying to get even better?

Yes, ofcourse. Do the simpler things first, then the more complex.

On Thu, Jul 26, 2007 at 04:11:10PM +0200, Jérémy Bobbio wrote:
>
> I meant having a dedicated question type specific to the partioning
> stage, maybe covering more questions at once than how it is currently
> done.

Each of the plugins of partman is allowed to modify almost every
question. This means the set of questions is standartized and fixed.
Which questions do you want to cover at once?

Anton Zinoviev


--
To UNSUBSCRIBE, email to debian-boot-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org
Back to top
Colin Watson
External


Since: Nov 11, 2004
Posts: 1039



PostPosted: Fri Jul 27, 2007 3:10 pm    Post subject: Re: Partman and graphical installer [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On Thu, Jul 26, 2007 at 03:32:57PM -0300, Otavio Salvador wrote:
> Jérémy Bobbio <lunar DeleteThis @debian.org> writes:
> > I can't really be more precise as I would like to experiment with
> > prototypes first. Smile Probably having something I could imagine as the
> > "ideal interface" and then do the required changes to fit it within
> > partman...
>
> The align plugin would be useful for others questions like language
> and keyboard so I think it's a good tradeof to get it implemented
> first.
>
> What others thing about it?

I kind of like the idea of align (note that if implemented as a plugin
the capb would be plugin-align). We've talked about column support in
the past, and this is basically the same thing. I think there are enough
different uses for it that it would be worthwhile.

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-boot-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org
Back to top
Colin Watson
External


Since: Nov 11, 2004
Posts: 1039



PostPosted: Fri Jul 27, 2007 3:20 pm    Post subject: Re: Buts about partman [LONG] [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On Thu, Jul 26, 2007 at 01:35:19AM +0300, Anton Zinoviev wrote:
> 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.

Two things. Firstly, I think column support like this is definitely
useful and I'd like to see it done (though we could bikeshed about the
separator details; I'd prefer something we can set up to guaranteeably
avoid ambiguity).

Secondly, partman also uses trailing spaces to disambiguate otherwise
identical-looking lines so that they're different choices in debconf.
This has always been recognised as a hack. The root problem here is that
partman uses complex constructed strings as the choices; this makes
preseeding very difficult in places as well. Obviously the English
choices should largely remain as they are now, but debconf now supports
"Choices-C" which can be used for machine-readable choices. For example,
the choice for a line in the partition tree could just be "/dev/sda1"
(or /var/lib/partman/devices/=dev=sda//0-8589934591, which might be
simpler internally) and the English choice (Choices as opposed to
Choices-C) could be the visual representation as calculated by partman.

I tried to do this myself a little while ago, but failed. I think it
should be possible, though, since partman already passes tab-separated
key/option pairs to debconf_select.

> 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.)

I'd be happy with this; the architecture-specific recipes are a mess.

I'd propose a slight variation on this, though. How about, instead of a
plugin, we allow specifiers like $yaboot{ }, and invent some way for
bootloader installer packages to enable this? That way, all the recipe
data could live in the main recipe files, and just be disabled if it's
not needed.

I don't know if this addresses your first point, though, as partman-auto
has no way to reuse existing partitions at the moment (which BTW I think
it needs to learn about eventually). Maybe your plugin idea would be
easier to implement.

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-boot-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org
Back to top
Display posts from previous:   
Post new topic   General Reply to Topic (not reply to a specific post)    Forums Home -> Booting All times are: Eastern Time (US & Canada) (change)
Page 1 of 1

 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum