Bug 1113681

Summary:	fsadm: --resizefs fails for LUKS encrypted LVs
Product:	Red Hat Enterprise Linux 7	Reporter:	Bryn M. Reeves <bmr>
Component:	lvm2	Assignee:	Ondrej Kozina <okozina>
lvm2 sub component:	Scripts / lvmdump / vgimportclone	QA Contact:	cluster-qe <cluster-qe>
Status:	CLOSED ERRATA	Docs Contact:	Marek Suchánek <msuchane>
Severity:	high
Priority:	high	CC:	agk, bmarzins, bmr, cmarthal, dwysocha, heinzm, jbrassow, jonathan, lersek, lmiksik, lvm-team, mailinglists35, mcsontos, msnitzer, nperic, prajnoha, prockai, zkabelac
Version:	7.0	Keywords:	Triaged
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	lvm2-2.02.175-2.el7	Doc Type:	Enhancement
Doc Text:	fsadm can now grow and shrink LUKS-encrypted LVM volumes The fsadm utility is now able to grow and shrink Logical Volume Manager (LVM) volumes that are encrypted with Linux Unified Key Setup (LUKS). This applies both to using fsadm directly with the "fsadm --lvresize" command and to using it indirectly through the "lvresize --resizefs" command. Note that due to technical limitations, resizing of encrypted devices with a detached header is not supported.	Story Points:	---
Clone Of:	1113679	Environment:
Last Closed:	2018-04-10 15:16:02 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1113679
Bug Blocks:	1469559

Description Bryn M. Reeves 2014-06-26 15:43:15 UTC

+++ 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:

Comment 2 Ondrej Kozina 2014-12-03 16:33:23 UTC

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?

Comment 3 Alasdair Kergon 2014-12-05 03:37:45 UTC

Well whatever implementation we go for (if you don't think it fits directly in fsadm?), the "one step" functionality needs to be there.

Comment 4 Ondrej Kozina 2014-12-05 09:09:47 UTC

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...)

Comment 9 Ondrej Kozina 2017-10-04 15:06:17 UTC

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

Comment 10 Ondrej Kozina 2017-10-10 14:33:41 UTC

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.

Comment 12 Corey Marthaler 2017-10-16 22:20:04 UTC

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

Comment 14 Marek Suchánek 2018-03-14 21:54:03 UTC

Marian, I've edited your draft doc text. Please let me know if any changes to it are required.

Comment 16 errata-xmlrpc 2018-04-10 15:16:02 UTC

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

Comment 17 Laszlo Ersek 2019-02-08 00:04:39 UTC

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 :) )

Comment 18 Laszlo Ersek 2019-02-08 00:06:50 UTC

(I mean I specified "--verbose" *in addition* to "--resizefs", of course.)

Comment 19 Mai Ling 2021-06-02 19:14:08 UTC

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