Add LVM volume group support if lvm_vg= is specified

[NotKit]

Support LVM-backed userdata and rootfs partitions via lvm_vg= cmdline parameter. Activate LVM early in boot process and check for volumes in the specified volume group. If found, /dev/$vg/userdata is used for userdata and /dev/$vg/rootfs overrides any systempart= setting.

[fredldotme]

I'm wondering if instead of making LVM an optional thing via kernel cmdline, whether we should default to LVM instead. That is, if we really want to remove preexisting partition detection.

EDIT: I remember now, that won't work with our multiple recovery ramdisk copies across ports.

[fredldotme]

This if can probably go away due to previous duplicate.

[fredldotme]

Do we really want those removed? Looks like it would cripple existing setups.

[peat-psuwit]

It's moved to line 468 below. Raw userdata partition lookup has to happen after LVM activation, because under new scheme the raw userdata partition can also be a part of LVM volume group.

[peat-psuwit]

It's moved to line 468 below. Raw userdata partition lookup has to happen after LVM activation, because under new scheme the raw userdata partition can also be a part of LVM volume group.

[peat-psuwit]

• I think the grep ... is not really needed, as if there isn't this parameter then the loop below won't find it anyway.
• Maybe simply lvm_vg is too generic. Maybe halium_lvm_vg, but I don't know...

[peat-psuwit]

So, by simply adding lvm2 package into the building rootfs, we automatically get an initramfs-tools hook for it automatically. What if we simply rely on that and specify on kernel cmdline systempart=/dev/mapper/${lv}-rootfs datapart=/dev/mapper/${lv}-userdata?

We do call udevadm settle before looking for systempart and datapart; my understanding is that LVM PV scan should be triggered by that; if we're unsure I guess we can try triggering it manually if specified paths doesn't exists as well.

[peat-psuwit]

My understanding is that the partition label for the new LVM PV will still be super. Does parse-android-dynparts handle this gracefully?

[NotKit]

It will fail, which is ok, since we don't exit on errors.

[NotKit]

So, by simply adding lvm2 package into the building rootfs, we automatically get an initramfs-tools hook for it automatically. What if we simply rely on that and specify on kernel cmdline systempart=/dev/mapper/${lv}-rootfs datapart=/dev/mapper/${lv}-userdata?

We do call udevadm settle before looking for systempart and datapart; my understanding is that LVM PV scan should be triggered by that; if we're unsure I guess we can try triggering it manually if specified paths doesn't exists as well.

It could be a good idea if we could rely on existing lvm2 hook. However, we need to be to boot both old and new setups with a single build, so then there should be multiple systempart specified somehow? That could be handled gracefully by script, but I'm afraid we might run out of kernel cmdline length on some devices. The reason is, first we introduce LVM boot support and update the recovery through OTA, then on next update, it actually does the conversion.

[fredldotme]

I would recommend Ratchanan's approach, I've been using it in a custom fork of initramfs-tools-halium in $PREVIOUS_DAYJOB as well, but note that there are two changes required to make it work properly:

• https://git.launchpad.net/~mattig-schauer/+git/initramfs-tools-halium/commit/?h=noble-mattigschauer&id=17a32a8fd3fcbfa99dab8e341f526094dd8f3e90
• https://git.launchpad.net/~mattig-schauer/+git/initramfs-tools-halium/commit/?h=noble-mattigschauer&id=8206acbf0c189ff032bc632a16208ae0f6617c11