LVM support in initramfs

[jpap]

Feature Request

Environment

Bare metal.

Desired Feature

Please add support for LVM into the initramfs. This would enable us to take LVM snapshots of the ROOT partition to assist with backups.

Right now we can create separate partitions on LVM for the above, but then it becomes more complex to ensure all relevant files for backup exist on that secondary partition. Having the ROOT on LVM would afford the greatest flexibility and system configuration.

I am not requesting LVM support be included into ignition at this time. This request is for those of us who manually partition the ROOT.

[DrMurx]

I stumbled over a similar issue. It would already help to provide a way to manipulate the GPT after coreos-install finished and not relying on the automated expansion of ROOT during boot.

Before rebooting after coreos-install, I fixed the upper sector boundary, manually resized the ROOT partition to an acceptable size, and created an LVM partition as /dev/sda10, but that already the former prevented grub from booting the OS properly.

[bgilbert]

@DrMurx You should be able to use LVM now, as long as you're not putting the ROOT partition on it. You can do something similar to your manual steps with a Container Linux Config like the one in coreos/docs#1125 (comment), though since Ignition doesn't currently support LVM, you'll need to create the LVM PV on sda10 by hand after boot (or write a systemd unit to do it). Your current approach should also work, however. Could you provide more details on the boot failure you were seeing?

[DrMurx]

coreos-install leaves the GPT with an invalid "last useable" sector barely greater than the small ROOT stub. Obviously this is fixed during the boot sequence before ROOT is resized.

root@ubuntu-xenial:~# sgdisk -p /dev/sda
Disk /dev/sdc: 12582912 sectors, 6.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 00000000-0000-0000-0000-000000000001
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 9289694
Partitions will be aligned on 2048-sector boundaries
Total free space is 8125 sectors (4.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            4096          266239   128.0 MiB   EF00  EFI-SYSTEM
   2          266240          270335   2.0 MiB     EF02  BIOS-BOOT
   3          270336         2367487   1024.0 MiB  FFFF  USR-A
   4         2367488         4464639   1024.0 MiB  FFFF  USR-B
   6         4464640         4726783   128.0 MiB   8300  OEM
   7         4726784         4857855   64.0 MiB    FFFF  OEM-CONFIG
   9         4857856         9285631   2.1 GiB     FFFF  ROOT

At this point, this prevents creating useful partitions with sgdisk. However, parted asks

Warning: Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra xxxxxxxx blocks) or continue with the current setting?

and offers to fix this. Afterwards, sgdisk shows the proper last usable sector. Even with no further partition added, a reboot fails with this grub error:

  Booting `CoreOS default'

error: no such partition.

Reading or updating GPT failed!
Please file a bug with any messages above to CoreOS:

[bgilbert]

@DrMurx It seems Parted clears the PartitionTypeGUID-specific partition attribute bits, in contravention of the UEFI spec, so you can't use it to modify a Container Linux boot disk. You can use gdisk to add partitions (and it will fix the GPT when you write out your changes), or if you're running coreos-install from Container Linux (e.g. via PXE or ISO boot), you can use cgpt repair followed by sgdisk.

[DrMurx]

@bgilbert Good hint, the gdisk worked for me (run once and just write the GPT to fix the last usable sector, run a second time to create the partition).

But since I need sgdisk to properly automate, and apparently it doesn't provide an option to just write the fixed GPT, so I helped myself with first creating a small partition sda10, deleting it immediately and then creating the real partition.

For the records: cgpt available for Xenial (cgpt 0-20121212) doesn't properly repair the GPT.

[jzampieron]

Any progress being made here? The ability to use Ignition to provision LVM volumes is very desirable.

[ajeddeloh]

We're working on expanding the GPT partitioning logic to be more useful first. We want to be able to support semantics similar to the filesystem refuse semantics to better support people PXE booting with a persistant root. It's tricky and there's lots of gotchas so we're ironing those out with GPT partitioning first. I'm hoping to get back to finishing that up soon.

LVM support will probably face a number of the same issues, so we want to figure them out with GPT partitioning first. It will also need support from udev for root-on-LVM support similar to how we handle root-on-RAID.