RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1113681 - fsadm: --resizefs fails for LUKS encrypted LVs
Summary: fsadm: --resizefs fails for LUKS encrypted LVs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: lvm2
Version: 7.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Ondrej Kozina
QA Contact: cluster-qe@redhat.com
Marek Suchánek
URL:
Whiteboard:
Depends On: 1113679
Blocks: 1469559
TreeView+ depends on / blocked
 
Reported: 2014-06-26 15:43 UTC by Bryn M. Reeves
Modified: 2023-03-08 07:26 UTC (History)
18 users (show)

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.
Clone Of: 1113679
Environment:
Last Closed: 2018-04-10 15:16:02 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0853 0 None None None 2018-04-10 15:17:48 UTC

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
Note You need to log in before you can comment on or make changes to this bug.