ubiquity lvm/luks

[Dmitrijs Ledkovs]

On 15/06/12 15:54, Matthew Paul Thomas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dmitrijs Ledkovs wrote on 14/06/12 10:29:
>> ...
>>
>> On 12/06/12 11:36, Matthew Paul Thomas wrote:
>>
>> ...
>>> Dmitrijs Ledkovs wrote on 08/06/12 12:13:
>> ...
>>>>
>>>> - checkboxes for LVM & Encrypted LVM
>> ...
>>>
>>> If either of these were mentioned in the automatic partitioning 
>>> process, they couldn't be understandable without being explained 
>>> in so much detail that it would be distracting.
>>
>> =/ yeah those checkboxes are not the best. One of the requirements 
>> is feature parity with the alternative/server installer. Those
>> CD's offer LVM2 or LVM2+LUKS installations with a one click
>> difference, plus password setup for encryption.
>>
>> cjwatson, did say on IRC, that if LVM2 or LVM2+LUKS are offered, it
>> should be on automatic partitioning page. As I understand it, this
>> is because most of the automatic options (e.g. use whole disk, 
>> resize windows and use the rest of the disk, etc.), can optionally 
>> have LVM2 or LVM2+LUKS.
> 
> For those not following along on #ubuntu-installer: The current plan
> is that we will start with LVM just in the advanced partitioner. That
> will bring us to feature parity, opting for completeness over ease of
> use. Later, once any kinks are worked out, we can offer LVM2+LUKS for
> the various automatic partitioning options.
> 

There is also a solution to have these playground/experimental
manual/automatic partition options changes be enabled only when running
ubiquity with a special command line flag, until suitable for wider
testing for release. Similarly, how the current style manual partitioner
was initially introduced.

>>> We could add encryption to the automatic partitioning process in
>>>  future, but it would need to be a nicer sort -- with the option 
>>> to use your login password as the password, and multiple
>>> recovery keys, and things like that.
>>
>> It's insecure in my opinion to use login password same as 
>> encryption password. In larger deployments your password will be 
>> centrally managed via LDAP, while the machine encryption
>> passphrase will be different. The machine passphrase should be
>> generally very long.
> 
> Understood.
> 
>> ...
>>
>>> I have started on the LVM design in the installer specification.
>>>  
>>> <https://docs.google.com/a/canonical.com/document/d/1bZ4yQIVgGaUGSYu3qiUHnQt3ieBZoqunP_DcleHCr3I/edit#heading=h.v8wi3omt1z0>
>>>
>>>
>>>
>>>  As I understand it, the tasks we need to present are:
>>>
>>> *   creating an LVM volume from two or more physical volumes
>>>
>>> *   adding a physical volume to an existing LVM volume
>>>
>>> *   removing a physical volume from an LVM volume
>>>
>>> *   dismantling an LVM volume altogether.
>>>
>>> Is that right?
>>
>> LVM can be created from a single physcial volume.
> 
> I've corrected the specification accordingly.
> 
>> So the tasks seem correct.
>>
>> * creating an LVM Physical Group from _one_ or more physical
>> volume(s)
>>
>> * adding/removing physical volumes to an LVM Group
>>
>> * removing an LVM Physical Group all together
> 
> I have now completed the above specification for those tasks, as well
> as for renaming a volume group. Please let me know what mistakes I've
> made.
> 

Looks very, very, very good.

>> (this can be done by presenting LVM as a block device and use 
>> existing partitioning functionality) "partitioning" the LVM Group:
>>  * adding/removing/resizing logical volumes
> 
> "Partitioning" a volume group can, almost certainly, be handled with
> the existing UI for partitioning a physical disk -- possibly with
> minor dynamic wording changes. However, I don't yet understand the
> details of how these two types of partitioning differ.
> 
> What things can you do, with volumes in a volume group, that you can't
> do with partitions in a physical disk? And vice versa?
> 

Looking at the 'Create Partition' Dialog:
https://picasaweb.google.com/105922848292507689403/Ubiquity#5746465762407224146

For Logical Volumes:
* type of partition is not needed
* location for the new partition is not needed

Edit dialog stays the same.

The "biggest" difference between volume group & disk drive will be on
this screen:
https://picasaweb.google.com/105922848292507689403/Ubiquity#5746465758885158098

For disks if you have say have 4 partitions, and you remove 2nd and 4th
partitions, you will have two lines which will say 'free':
/dev/vda
 /dev/vda1
 free
 /dev/vda2
 free

With a Volume Group, all free space would simply collapse into a single
entry 'free':
VolGroup
  /dev/VolGroup-root
  /dev/VolGroup-home
  free

It is simple enough to change the wording to LVM terms within the
dialogs dynamically depending if a partitions or a volume is being
edited/created.

We will need scary warnings if you try to kill your data, which can
happen during:
 * removing volume group
 * reducing volume group total size, below usage by logical volumes
 * removing logical volume
 * reducing logical volume below total space take by the data

Volume groups do not have MBR, so bootloader cannot be installed onto
them. (bootloader can be installed onto physical disks or partitions)

If root filesystem ('/' mount point) is on Logical Volume, we will
recommend to have a '/boot' partition on a physical disk completely
outside of LVM.

maybe something else as well. Need to ponder a bit more.

-- 
Regards,
Dmitrijs.