Bug#462396: Multiple disks support for partman-auto-lvm

[Grégory Oestreicher <greg@kamago.net>]

>>   We need to create the envelope only if one is not defined. This is the case
>> when :
>>     - the default device is not part of a PV declaration in the scheme (a PV
>>       is declared when there's a method{ lvm } or method{ crypto } attribute).
>>     - the recipe contains a PV declaration *without* device. For this case the
>>       physical device used will be the default one.
>>
>> If it's OK with you (and clear) I'll integrate this in the next patch.
>
> Yes, that's a lot better.  If you could add an example use case for each
> of these, it would be even better. ;)

This made me realize that I forgot the 'and' between the two points...

> Preseeded encrypted installations are fairly rare: you need to be
> sitting right behind the box to type a meaningful passphrase.  I think
> it does not make a lot of sense to make partman-auto-lvm more complex
> that it already is for such corner cases.

OK then.

>> > > +	# The recipe contains all the necessary informations about eventuals
>> > > +	# extra VGs to create
>> > > +	# The VGs to create are :
>> > > +	#   - the default one if some partitions don't have the invg{ } tag
>> > > +	#   - the ones present in vgname{ } tags of PVs
>> > > +	decode_recipe $recipe lvm
>> > > [â?¦]

> I might have overlooked that decode_recipe() is called twice, but I
> still think this part would be more at its place in auto_lvm_prepare() as
> its extracting informations for the recipe and not yet acting on them.

This is not possible either : $pv_devices is not defined in auto_lvm_prepare() and it
is needed some lines further. The only thing I see to prevent the double call to
decode_recipe() is to save $scheme in a temporary location and reload it here.

I'm fine with all your other points and will integrate them.

Cheers,
Grégory