Add LVM volume group support if lvm_vg= is specified#45
Conversation
There was a problem hiding this comment.
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.
|
So, by simply adding We do call |
| if [ -b /dev/disk/by-partlabel/super ]; then | ||
| tell_kmsg "trying to parse and dmsetup subpartitions from super partition" | ||
| /sbin/parse-android-dynparts /dev/disk/by-partlabel/super | sh | ||
| fi |
There was a problem hiding this comment.
My understanding is that the partition label for the new LVM PV will still be super. Does parse-android-dynparts handle this gracefully?
There was a problem hiding this comment.
It will fail, which is ok, since we don't exit on errors.
It could be a good idea if we could rely on existing |
|
I would recommend Ratchanan's approach, I've been using it in a custom fork of initramfs-tools-halium in |
|
@peat-psuwit thinking of it, what if we don't rely on fixed LVM volume group name and prefix the partitions instead? E. g. |
|
How ready is this, now that the recovery portion has been merged? |
|
I can say that the current state of this would break non-LVM A/B devices using |
ea41d25 to
743bd96
Compare
Activate LVM early in boot and look for volumes in the groups named by halium_lvm_vg=, comma separated. If a group is found, /dev/$vg/userdata is used for userdata and /dev/$vg/rootfs overrides systempart=.
If the ramdisk lacks LVM support or has an incorrect halium_lvm_vg=, the userdata search falls back to the raw partition. Because pvcreate only wipes the start of the partition, old ext4 backup superblocks survive. If e2fsck runs on the raw partition, it mistakes it for a broken ext4 filesystem and restores it, overwriting LVM metadata at offset 4096 and destroying the VG. To fix this, check for the surviving LVM label at offset 512 via blkid and panic before any write operations occur. In resize_userdata_if_needed(), resolve $path to its kernel name before looking it up in /proc/partitions so LVM volumes report a size.
LVM adds about 900K to the initrd, which devices with a small ramdisk may not be able to spare. Build both variants from the same branch so it can be picked by the device adaptation. lvm2 is only pulled into the chroot when LVM=1, and hooks/halium includes it only when present. Without it, scripts/halium finds no volume group and uses the partitions directly.
Some bootloaders fail to boot images with a large ramdisk, so the recovery ramdisk may be compressed with xz instead of gzip. It is then named ramdisk-recovery.cpio.xz. Also link /sbin/init, which run-init expects, to the recovery /init.
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.