I use LVM a lot & help to develop and maintain an OS installer (Anaconda, used in Fedora & RHEL) that always installs to LVM by default. Over the years I don't remember a single case where users would report their storage being hosed due to the LVM layout/metadata being corrupted. It has always been either hardware failure or storage configuration tools (including the ones we have in the installer :P) doing something the wrong way.

Therefore I think Jolla is being overly defensive in this case when the insist on re-creating the LVM layout every time during factory reset.

Having two physical volumes (PVs) on the two big partitions, putting them into a volume group (VG) and then creating all the logical volumes (LVs) from the VG should be safe.

For example on my Xperia X, there is a 20.7 GB partition used for LVM and a 7.3 GB partition used for the firmware images (with about 300 GB space used, wasting almost full 7 GB of space).

Say we create two PVs, one on the 20.7 GB partition and one on the 7.3 GB one, giving us 28 GB of space in the VG. From that we create a 1 GB firmware image LV, a 5 GB root LV and 22 GB home LV. That should give plenty of space for all uses when we are no longer wasting a full 7 GB for nothing.

Then when you do a factory reset, simply run mkfs.ext4 on the root & home LVs and dump content of the respective firmware restore tarballs. If you want to be really through you might want to call wipefs on the LVs first or even re-create the root and home LVs in the VG. But really, there is no good reason to drop the full LVM layout and re-create it every time.

From what I've heard so far (and anyone more knowledgeable is free to correct me), touching the partition layout on an Android device is very dangerous. Apparently some of the early boot and baseband stuff is fetching it's firmware and configs from specific byte offset. Changing the partition layout then could change those offsets, breaking these sub systems or possibly even bricking the device.