Hide Forgot
+++ 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
Thank you all for delivering this feature; I've put it to use today on my RHEL-7.5.z Workstation laptop, and it worked just great. It was a relief that I didn't have to manually resize the LUKS blockdev between the LV and the filesystem -- lvresize handled the whole stack. The manual pages for lvresize and fsadm looked promising (especially "--cryptresize" in the latter). A web search lead me here. After checking the Fixed-in-Version and the Doc Text fields on the BZ, I was confident it would work on my laptop. I ran lvresize with "--verbose", and indeed it worked flawlessly. Thank you all again! (I guess we can also clear the needinfo from comment 14 now :) )
(I mean I specified "--verbose" *in addition* to "--resizefs", of course.)
this does not work for layout luks on top of lvm, and instead it must be done manually: with separate runs of lvresize, e2fsck and fsadm [root@localhost-live ~]# lvs -a -o+devices LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert Devices root plj Vwi-aotz-- 8.00g thin 49.65 swap plj Vwi-aotz-- 4.00g thin 0.39 thin plj twi-aotz-- 4.84g 88.23 35.94 thin_tdata(0) [thin_tdata] plj Twi-ao---- 4.84g /dev/sdb2(1) [thin_tdata] plj Twi-ao---- 4.84g /dev/sdb2(1028) [thin_tmeta] plj ewi-ao---- 8.00m /dev/sdb2(1025) tmp plj Vwi-aotz-- 4.00g thin 3.58 lsblk -iM sdb 8:16 1 111.8G 0 disk |-sdb1 8:17 1 1G 0 part /run/media/liveuser/048c7c5a-03c5-42d8-b0dc-e2d8368a34b0 `-sdb2 8:18 1 54.9G 0 part ,-> |-plj-thin_tmeta 253:0 0 8M 0 lvm '-> `-plj-thin_tdata 253:1 0 4.8G 0 lvm `--plj-thin-tpool 253:2 0 4.8G 0 lvm |-plj-thin 253:3 0 4.8G 1 lvm |-plj-root 253:4 0 8G 0 lvm | `-root 253:19 0 8G 0 crypt this failed: [root@localhost-live ~]# lvresize -v -r -L 8g plj/root Executing: /usr/sbin/fsadm --verbose check /dev/plj/root fsadm: "crypto_LUKS" filesystem found on "/dev/mapper/plj-root". fsadm: cryptsetup utility required. /usr/sbin/fsadm failed: 1 Filesystem check failed. this worked: [root@localhost-live ~]# lvresize -v -L 8g plj/root Archiving volume group "plj" metadata (seqno 53). Extending logical volume plj/root to 8.00 GiB Size of logical volume plj/root changed from 4.00 GiB (1024 extents) to 8.00 GiB (2048 extents). Loading table for plj-thin_tdata (253:1). Suppressed plj-thin_tdata (253:1) identical table reload. Loading table for plj-thin_tmeta (253:0). Suppressed plj-thin_tmeta (253:0) identical table reload. Loading table for plj-thin-tpool (253:2). Suppressed plj-thin-tpool (253:2) identical table reload. Loading table for plj-root (253:4). Not monitoring plj/thin with libdevmapper-event-lvm2thin.so Unmonitored LVM-RBtHRI3ycYli5z0m11T2SNfiwxYcmJk3rLTVdPP5rSCctdeWdaU3SIqef3QrgpN5-tpool for events Suspending plj-root (253:4) Suspending plj-thin-tpool (253:2) Suspending plj-thin_tdata (253:1) Suspending plj-thin_tmeta (253:0) Loading table for plj-thin_tdata (253:1). Suppressed plj-thin_tdata (253:1) identical table reload. Loading table for plj-thin_tmeta (253:0). Suppressed plj-thin_tmeta (253:0) identical table reload. Loading table for plj-thin-tpool (253:2). Suppressed plj-thin-tpool (253:2) identical table reload. Resuming plj-thin_tdata (253:1). Resuming plj-thin_tmeta (253:0). Resuming plj-thin-tpool (253:2). Resuming plj-root (253:4). Monitored LVM-RBtHRI3ycYli5z0m11T2SNfiwxYcmJk3rLTVdPP5rSCctdeWdaU3SIqef3QrgpN5-tpool for events Creating volume group backup "/etc/lvm/backup/plj" (seqno 54). Logical volume plj/root successfully resized. [root@localhost-live ~]# e2fsck -f /dev/mapper/root e2fsck 1.45.6 (20-Mar-2020) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information root: 73799/261120 files (0.2% non-contiguous), 1040384/1044480 blocks [root@localhost-live ~]# fsadm -v resize /dev/mapper/root fsadm: "ext4" filesystem found on "/dev/mapper/root". fsadm: Device "/dev/mapper/root" size is 8573157376 bytes fsadm: Parsing tune2fs -l "/dev/mapper/root" fsadm: Resizing filesystem on device "/dev/mapper/root" to 8573157376 bytes (1044480 -> 2093056 blocks of 4096 bytes) fsadm: Executing resize2fs /dev/mapper/root 2093056 resize2fs 1.45.6 (20-Mar-2020) Resizing the filesystem on /dev/mapper/root to 2093056 (4k) blocks. The filesystem on /dev/mapper/root is now 2093056 (4k) blocks long. lvm2-2.03.11-1.fc34.x86_64 kernel-5.11.12-300.fc34.x86_64