Red Hat Bugzilla – Bug 1113681
fsadm: --resizefs fails for LUKS encrypted LVs
Last modified: 2018-04-10 11:17:48 EDT
+++ This bug was initially created as a clone of Bug #1113679 +++ Description of problem: Using --resizefs with lvextent / lvresize etc. on a LUKS encrypted LV results in: $ sudo lvextend -L +2g --resizefs vg_hex/lv_home fsck from util-linux 2.24.2 fsck: fsck.crypto_LUKS: not found fsck: error 2 while executing fsck.crypto_LUKS for /dev/mapper/vg_hex-lv_home Filesystem check failed. Version-Release number of selected component (if applicable): $ rpm -q lvm2 lvm2-2.02.106-1.fc20.x86_64 How reproducible: 100% Steps to Reproduce: 1. lvcreate -n $LV_NAME -L 8M $VG_NAME 2. cryptsetup luksFormat /dev/$VG_NAME/$LV_NAME [...] 3. cryptsetup luksOpen /dev/$VG_NAME/$LV_NAME 4. Create a file system supported by fsadm on the LUKS volume 5. Attempt to resize the LV and its contents: # lvextend -L +8M --resizefs $VG_NAME/$LV_NAME Actual results: Tries to treat LUKS as a file system: $ sudo lvextend -L +2g --resizefs vg_hex/lv_home fsck from util-linux 2.24.2 fsck: fsck.crypto_LUKS: not found fsck: error 2 while executing fsck.crypto_LUKS for /dev/mapper/vg_hex-lv_home Filesystem check failed. Expected results: Handles LUKS as a special case and issues the appropriate combination of file system resize and crypsetup resize commands. Additional info:
fsadm is supposed to check and resize filesystem, not a block device. Support for resizing any device stack was not an option with fsadm. Would you agree this should be resolved with more verbose error output?
Well whatever implementation we go for (if you don't think it fits directly in fsadm?), the "one step" functionality needs to be there.
I agree this particular scenario is easy to handle: we have active LV with active luks container and well known fs on top. User required extend operation (shrink is much worse). We can just put cryptsetup --resize command in between... But the moment we allow resizing stacked devices in general (using actual lvm tools) we also open pandora's box sort of: what if luks container: a) is inactive b) is suspended c) contains another (PV/luks/...) I see it as more complex problem than last minute fix for 7.1. Should we make this RFE instead? (I have a feeling I've seen it somewhere already...)
I have a patch almost ready. In the end, it looks like the most complex part was, in fact, the detached header detection. I'm able to support grow and shrink of a filesystem on active LUKS device after all. I'll run some more tests tomorrow
implemented with https://sourceware.org/git/?p=lvm2.git;a=commit;h=30293baaa0f87efeab81f01f9c5d73b26869babf Currently we support following: a) resize (grow and shrink as long as the fs supports it) of an LV containing LUKS header of active device. We do NOT support detached LUKS headers for "lvresize -r" case. In other target LV has to host also ciphertext data for LUKS header at the beginning. b) same as a) but instead of running "lvresize -r" comannd, user may run "fsadm --lvresize resize /dev/vg/lv..." c) resize of any active crypt device (recognised by system cryptsetup utility) after running "fsadm --cryptresize resize /dev/mapper/unlocked_devname". It'll resize filesystem together with active crypt device.
Fix verified in the latest rpms. lvm2-2.02.175-2.el7 BUILT: Fri Oct 13 13:31:22 CEST 2017 lvm2-libs-2.02.175-2.el7 BUILT: Fri Oct 13 13:31:22 CEST 2017 lvm2-cluster-2.02.175-2.el7 BUILT: Fri Oct 13 13:31:22 CEST 2017 device-mapper-1.02.144-2.el7 BUILT: Fri Oct 13 13:31:22 CEST 2017 device-mapper-libs-1.02.144-2.el7 BUILT: Fri Oct 13 13:31:22 CEST 2017 device-mapper-event-1.02.144-2.el7 BUILT: Fri Oct 13 13:31:22 CEST 2017 device-mapper-event-libs-1.02.144-2.el7 BUILT: Fri Oct 13 13:31:22 CEST 2017 device-mapper-persistent-data-0.7.0-0.1.rc6.el7 BUILT: Mon Mar 27 17:15:46 CEST 2017 SCENARIO (raid1) - [open_EXT4_on_LUKS_raid_fsadm_resize_attempt] Create raid, encrypt it, add fs, and then attempt to resize it while it's mounted host-079: lvcreate --nosync --type raid1 -m 1 -n open_LUKS_fsadm_resize -L 4G raid_sanity WARNING: New raid1 won't be synchronised. Don't read what you didn't write! WARNING: crypto_LUKS signature detected on /dev/raid_sanity/open_LUKS_fsadm_resize at offset 0. Wipe it? [y/n]: [n] Aborted wiping of crypto_LUKS. 1 existing signature left on the device. cryptsetup luksFormat /dev/raid_sanity/open_LUKS_fsadm_resize cryptsetup luksOpen /dev/raid_sanity/open_LUKS_fsadm_resize raid_luksvolume Placing an EXT4 on open_LUKS_fsadm_resize volume mke2fs 1.42.9 (28-Dec-2013) Writing files to /mnt/open_LUKS_fsadm_resize/host-079 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 Starting dd io to raid fs to be resized Attempt to resize the open raid filesystem multiple times with lvextend/fsadm on host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 4060864 newsize: 6125120 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 6125120 newsize: 8189368 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 8189368 newsize: 10253588 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 10253588 newsize: 12317832 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 12317832 newsize: 14382088 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 14382088 newsize: 16446332 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 16446332 newsize: 18510544 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 18510544 newsize: 20574800 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 20574800 newsize: 22639056 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 (lvextend -L +2G -r /dev/raid_sanity/open_LUKS_fsadm_resize) resize2fs 1.42.9 (28-Dec-2013) /mnt/open_LUKS_fsadm_resize oldsize: 22639056 newsize: 24703312 Checking files on /mnt/open_LUKS_fsadm_resize/host-079 cryptsetup luksClose raid_luksvolume perform raid scrubbing (lvchange --syncaction repair) on raid raid_sanity/open_LUKS_fsadm_resize Deactivating raid open_LUKS_fsadm_resize... and removing
Marian, I've edited your draft doc text. Please let me know if any changes to it are required.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2018:0853