Lunar encrypted installation only creates a 100GB logical volume

nvme0n1        259:0    0   1.8T  0 disk
├─nvme0n1p1    259:1    0     1G  0 part  /boot/efi
├─nvme0n1p2    259:2    0     2G  0 part  /boot
└─nvme0n1p3    259:3    0   1.8T  0 part
  └─dm_crypt-0 253:0    0   1.8T  0 crypt
    └─ubuntu--vg-ubuntu--lv
               253:1    0   100G  0 lvm   /var/snap/firefox/common/host-hunspell
                                          /

Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-ubuntu--lv   98G   17G   77G  18% /

Current behavior by design. Proposed fixed to add an API flag to choose between the current behavior and full disk, then u-d-i can set that flag.

I couldn't find a GUI-friendly way to resize the logical volume. That's probably an important workaround to document if this bug is still in the final release.

As of at least the 20230406 build of the ubuntu-desktop-installer ISO, this fix is available.

Is there an intention here to make this a default on the desktop installer when installing with encryption? If so, I firmly disagree that this is an appropriate default. Layering LUKS+LVM+ext4 on a disk, but leaving no space on the VG to let the user do anything else with it, is not a sensible default. We use LVM when installing encrypted because *shrinking* an encrypted partition is exceedingly difficult for end-users to accomplish with the existing tools, which makes repartitioning after install a bad solution. If you fill the VG with a single root LV out of the box, then you've made it even HARDER to shrink the root disk if desired, by adding an additional useless layer (don't use LVM if you're never going to manage volumes).

> I couldn't find a GUI-friendly way to resize the logical volume.

gnome-disks should take care of resizing LVs.

Desktop wants encryption and full usage of the disk. LVM is a necessary step in the middle in the current implementation. With RC 3 days away, I'd like to proceed with the current implementation and allow Desktop to opt in to full disk usage.

Server behavior is unchanged.

Can we iterate on this and pursue a LUKS+ext4 implementation after Lunar? There is other stuff in plan that is going to make that simpler, whereas this was a relatively simple else statement and the API infrastructure to support it.

@dbungert, desktop also wants dualboot options, but the Ubuntu 23.04 installer does not list existing LUKS1 or LUKS2 partitions mapped to /dev/mapper/ using cryptsetup open. That was reported as https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1750645 back in Ubuntu 18.04 and is still unresolved.

> Desktop wants encryption and full usage of the disk.

Yes I am on the desktop team but really this is not about "wants". It's just a noticeable regression compared to (all?) previous releases that would fully utilize the disk.

We believe this issue has been resolved in Subiquity 23.04.2.

If you had tested this with a pre-final version of Ubuntu 23.04, it's
recommended to download the final install media.

For testing with Ubuntu Server 22.04.x or 20.04.x, when running
Subiquity, you should offered a new version of the installer. Please
take that update to version 23.04.2 or later to get the fix.

If this is still a problem for you, please make a comment and set the state
back to New. Thank you for the bug report.