>> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
