SUMMARY When a disk has "lvm2 pv [Encrypted]" which gets resized to be bigger, the partition does get resized but the "physical volume" doesn't get resized and I had to run "pvresize /dev/mapper/luks-123-123-my-uuid" manually for the physical volume size to increase. Afterwards I could increase the ext4 partitions inside of my lvm volume. STEPS TO REPRODUCE $ fallocate -l 100MB test.img $ sudo losetup /dev/loop5 test.img # scan devices with KDE Partition Manager # Create "New Partition Table" (GPT) on loop5 # Create "unformatted" partition with half the space -> Apply $ sudo partprobe /dev/loop5 # for /dev/loop5p1 to appear # Right click on partition -> Properties -> File system = lvm2 pv -> Apply # Tools -> New Volume Group -> Apply # Create new partition in new volume group with e.g. half the space # Resize "lvm2 pv" partition to be bigger # Observe, that the volume group didn't grow # If the same was to be tried without luks encryption, the volume group does grow to the new size. OBSERVED RESULT The lvm2 pv is not bigger EXPECTED RESULT The lvm2 pv should be bigger
Sorry, wrong "STEPS TO REPRODUCE". Here's the ones I wanted to send: $ fallocate -l 100MB test.img $ sudo losetup /dev/loop5 test.img # Scan devices with KDE Partition Manager # Create "New Partition Table" (GPT) on loop5 -> Apply # Create "lvm2 pv" and check the "Encrypt with LUKS" checkbox -> Apply # (this might fail now because it can't find /dev/loop5p1, just run "sudo partprobe /dev/loop5" and retry) # Tools -> New Volume Group -> Apply # Create new partition in new volume group with e.g. half the space # Resize "lvm2 pv" partition to be bigger # Observe, that the volume group didn't grow # If the same was to be tried without luks encryption, the volume group does grow to the new size.
Hmm, for some reason when resizing LVM PV partition, the information about new partition table is not passed to kernel (can be seen in /sys/block/*/size), so when cryptsetup resize runs, it sees the old size of LVM PV partition and does not do resizing.
blockdev --rereadpt /dev/sd# seem to be failing when there is an open luks partition. So I guess this is a regression in KPMcore 4.0 (when switching to sfdisk backend.)
Hmm, there seems to be two problems. The one mentioned above can be fixed by replacing blockdev with partx (both part of util-linux). However, there seems to be some bug in luks resizing code too (incorrect payload sized is passed to resize function of inner file system).
Git commit 13beb9931951cf5972e341a871263146d2bdafbe by Andrius Štikonas. Committed on 18/11/2019 at 18:42. Pushed by stikonas into branch 'master'. Use partx instead of blockdev to update partition table in the kernel. M +1 -1 src/plugins/sfdisk/sfdiskpartitiontable.cpp M +1 -0 src/util/externalcommand_whitelist.h https://invent.kde.org/kde/kpmcore/commit/13beb9931951cf5972e341a871263146d2bdafbe
Git commit 2c7b3f2bfa944f071c830a8192638d5c7a138331 by Andrius Štikonas. Committed on 18/11/2019 at 19:16. Pushed by stikonas into branch 'master'. Fix resizing of encrypted partitions. M +6 -4 src/fs/luks.cpp M +6 -4 src/fs/luks2.cpp https://invent.kde.org/kde/kpmcore/commit/2c7b3f2bfa944f071c830a8192638d5c7a138331
Any chance you can test these changes? At the moment they are in master, but maybe it's worth adding them to 4.0 branch too.
*** Bug 417139 has been marked as a duplicate of this bug. ***