LVM Entire Disk option does not use entire disk

LVM is using the entire disk - it has allocated the 19GiB partition 3 to the LVM Volume Group and 1GiB to the separate /boot/ partition 2.

The reason only 4GiB is allocated to the root file-system is that the remaining space is there to be allocated for other purposes by the system administrator.

E.g. The administrator may want to allocated separate block devices to host virtual machine or container images, and so on.

To view the free space in the parent Volume Group (VG) look at the Free PE: (Physical Extents):

$ sudo vgdisplay

To grow an existing Logical Volume (LV) and the (ext*) file-system within it to use 25% of the Free PE:

$ sudo lvextend -l 25%FREE VG_NAME/LV_NAME
$ sudo resize2fs /dev/mapper/VG_NAME-LV_NAME

See "man lvextend" for more options.

To create additional LVs do e.g:

$ sudo lvcreate -L 6G -n LV_NEW_NAME VG_NAME
$ sudo mkfs.ext /dev/mapper/VG_NAME-LV_NEW_NAME
$ sudo mkdir /mnt/more_storage
$ sudo mount /dev/mapper/VG_NAME-LV_NEW_NAME /mnt/more_storage

See "man lvcreate" for more options.

tj is right, there's not really any point using LVM if you then create a LV that fills your vg completely. I can see how it's surprising but I'm not sure how to make it less so.

> I can see how it's surprising but I'm not sure how to make it less so.

This is a solved problem: follow how the d-i based installer does it and ask the user for the amount of the disk they wish to use.

When choosing the option "Entire Disk" it should, imo, use the "Entire Disk". This is also the behaviour users expect, as the desktop installer and the old "alternative installer" do it this way.

On Mon, 3 Dec 2018 at 02:55, Timlukas Bloch <email address hidden>
wrote:

> When choosing the option "Entire Disk" it should, imo, use the "Entire
> Disk". This is also the behaviour users expect, as the desktop installer
> and the old "alternative installer" do it this way.
>

Well we are using the entire disk as part of the vg. Having your LV take up
100% of the VG would make it mostly pointless to be using LVM at all.

That said, we should do what Josh says and ask how much to use.

Nah this is terrible. Also it doesn't create a swap partition. The behaviour still exists in 20.04 using the "server-live" iso. I did install two 18.04 VMs recently, one with 100GB disk and had this bug, the other with a 50GB disk and it installed as you would expect.

Plenty of other people complaining:
https://askubuntu.com/questions/1106795/ubuntu-server-18-04-lvm-out-of-space-with-improper-default-partitioning
https://askubuntu.com/questions/1179572/why-does-18-04-lvm-default-to-4gb-despite-more-space-available

https://git.launchpad.net/subiquity/tree/subiquity/controllers/filesystem.py#n755 explicitly sets it to 4GB, how lazy is that. Here's how debian-installer does it if you need something sensible to copy https://salsa.debian.org/installer-team/partman-auto-lvm/-/blob/master/perform_recipe_by_lvm

This issue (really both, also the swapfile issue reported by @trs80) also carries on to Ubuntu 20.04 LTS Server. Since we no longer have the option of using the classic installer, this is creating a mess in terms of deployment.

How is this issue considered medium? It should be High, again especially now that there is no other installer available on 20.04.

https://github.com/CanonicalLtd/subiquity/pull/737

Looks like the other server I was talking about was installed with ubuntu-18.04-server-amd64.iso, not live-server, which is why it was sane - /var/log/installer/partman exists and the other logs show debian-installer was used.

The swapfile size is configured in https://github.com/canonical/curtin/blob/master/curtin/swap.py which is a problem since I think the place to add a swap partition would be as an additional self.create_logical_volume after this one https://github.com/mwhudson/subiquity/blob/dc66caa60130dff8420d3161e77d1ef39b3587cf/subiquity/controllers/filesystem.py#L770

This is a follow-up bug:
https://bugs.launchpad.net/subiquity/+bug/1893276