Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1349661

Summary: 'device-mapper: raid: Reshaping arrays not yet supported. (device count change)' error when attempting to create raid with RO tag
Product: Red Hat Enterprise Linux 7 Reporter: Corey Marthaler <cmarthal>
Component: lvm2Assignee: Heinz Mauelshagen <heinzm>
lvm2 sub component: Mirroring and RAID QA Contact: cluster-qe <cluster-qe>
Status: CLOSED ERRATA Docs Contact:
Severity: medium    
Priority: unspecified CC: agk, heinzm, jbrassow, mcsontos, msnitzer, prajnoha, rbednar, rhandlin, zkabelac
Version: 7.3Flags: rhandlin: needinfo+
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: lvm2-2.02.180-7.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-10-30 11:02:16 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: 1594916    
Bug Blocks:    

Description Corey Marthaler 2016-06-23 22:47:01 UTC 
Description of problem:
I rarely see this issue w/o a test case re-configuring the volume group before attempting this. So, there may be an additional step here required to cause this bug that I need to figure out still.

This test case attempts to recreate the scenario in bug 1021051.


[root@host-083 ~]# vgcreate raid_sanity /dev/sd[abcdefgh][12]
  Volume group "raid_sanity" successfully created

[root@host-083 ~]# pvscan
  PV /dev/vda2   VG rhel_host-083   lvm2 [7.51 GiB / 40.00 MiB free]
  PV /dev/sda1   VG raid_sanity     lvm2 [12.50 GiB / 12.50 GiB free]
  PV /dev/sdb1   VG raid_sanity     lvm2 [12.50 GiB / 12.50 GiB free]
  PV /dev/sdb2   VG raid_sanity     lvm2 [12.49 GiB / 12.49 GiB free]
  PV /dev/sdc1   VG raid_sanity     lvm2 [12.50 GiB / 12.50 GiB free]
  PV /dev/sdc2   VG raid_sanity     lvm2 [12.49 GiB / 12.49 GiB free]
  PV /dev/sdd1   VG raid_sanity     lvm2 [12.50 GiB / 12.50 GiB free]
  PV /dev/sdd2   VG raid_sanity     lvm2 [12.49 GiB / 12.49 GiB free]
  PV /dev/sde1   VG raid_sanity     lvm2 [12.50 GiB / 12.50 GiB free]
  PV /dev/sdf1   VG raid_sanity     lvm2 [12.50 GiB / 12.50 GiB free]
  PV /dev/sdf2   VG raid_sanity     lvm2 [12.49 GiB / 12.49 GiB free]
  PV /dev/sdg1   VG raid_sanity     lvm2 [12.50 GiB / 12.50 GiB free]
  PV /dev/sdh1   VG raid_sanity     lvm2 [12.50 GiB / 12.50 GiB free]
  PV /dev/sdh2   VG raid_sanity     lvm2 [12.49 GiB / 12.49 GiB free]
  PV /dev/sda2   VG raid_sanity     lvm2 [12.49 GiB / 12.49 GiB free]
  PV /dev/sde2   VG raid_sanity     lvm2 [12.49 GiB / 12.49 GiB free]
  PV /dev/sdg2   VG raid_sanity     lvm2 [12.49 GiB / 12.49 GiB free]
  Total: 17 [207.45 GiB] / in use: 17 [207.45 GiB] / in no VG: 0 [0   ]

[root@host-083 ~]# grep read_only /etc/lvm/lvm.conf
        # Configuration option global/metadata_read_only.
        metadata_read_only = 0
        # Configuration option activation/read_only_volume_list.
    read_only_volume_list = [ "@RO" ]
        # read_only_volume_list = [ "vg1", "vg2/lvol1", "@tag1", "@*" ]

[root@host-083 ~]# lvcreate  --type raid10 -n kern_perm -L 300M --addtag RO raid_sanity
  Rounding size 300.00 MiB (75 extents) up to stripe boundary size 320.00 MiB (80 extents).
  /dev/raid_sanity/kern_perm_rmeta_0: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_1: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_2: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_3: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_4: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_5: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_6: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_7: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_8: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_9: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_10: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_11: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_12: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_13: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_14: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_15: write failed after 0 of 4096 at 0: Operation not permitted
  device-mapper: reload ioctl on (253:34) failed: Invalid argument
  Failed to activate new LV.

[root@host-083 ~]# lvs
  LV   VG            Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert

Jun 23 17:01:37 host-083 kernel: device-mapper: raid: Reshaping arrays not yet supported. (device count change)
Jun 23 17:01:37 host-083 kernel: device-mapper: table: 253:34: raid: Unable to assemble array: Invalid superblocks
Jun 23 17:01:37 host-083 kernel: device-mapper: ioctl: error adding target to table


root@host-083 ~]# dmsetup ls
raid_sanity-kern_perm_rimage_9  (253:21)
raid_sanity-kern_perm_rmeta_12  (253:26)
raid_sanity-kern_perm_rimage_10 (253:23)
raid_sanity-kern_perm_rmeta_8   (253:18)
raid_sanity-kern_perm_rimage_8  (253:19)
raid_sanity-kern_perm_rmeta_11  (253:24)
raid_sanity-kern_perm_rmeta_7   (253:16)
raid_sanity-kern_perm_rimage_7  (253:17)
raid_sanity-kern_perm_rmeta_10  (253:22)
raid_sanity-kern_perm_rmeta_6   (253:14)
raid_sanity-kern_perm_rimage_6  (253:15)
raid_sanity-kern_perm_rmeta_5   (253:12)
raid_sanity-kern_perm_rimage_5  (253:13)
raid_sanity-kern_perm_rmeta_4   (253:10)
raid_sanity-kern_perm_rimage_4  (253:11)
raid_sanity-kern_perm_rmeta_3   (253:8)
raid_sanity-kern_perm_rimage_3  (253:9)
raid_sanity-kern_perm_rmeta_2   (253:6)
raid_sanity-kern_perm_rimage_2  (253:7)
raid_sanity-kern_perm_rmeta_1   (253:4)
raid_sanity-kern_perm_rimage_1  (253:5)
raid_sanity-kern_perm_rimage_15 (253:33)
raid_sanity-kern_perm_rmeta_0   (253:2)
raid_sanity-kern_perm_rimage_0  (253:3)
raid_sanity-kern_perm_rimage_14 (253:31)
raid_sanity-kern_perm_rmeta_15  (253:32)
raid_sanity-kern_perm_rimage_13 (253:29)
raid_sanity-kern_perm_rmeta_14  (253:30)
raid_sanity-kern_perm_rimage_12 (253:27)
raid_sanity-kern_perm_rmeta_13  (253:28)
raid_sanity-kern_perm_rimage_11 (253:25)
raid_sanity-kern_perm_rmeta_9   (253:20)


Version-Release number of selected component (if applicable):
3.10.0-419.el7.x86_64

lvm2-2.02.156-1.el7    BUILT: Mon Jun 13 03:05:51 CDT 2016
lvm2-libs-2.02.156-1.el7    BUILT: Mon Jun 13 03:05:51 CDT 2016
lvm2-cluster-2.02.156-1.el7    BUILT: Mon Jun 13 03:05:51 CDT 2016
device-mapper-1.02.126-1.el7    BUILT: Mon Jun 13 03:05:51 CDT 2016
device-mapper-libs-1.02.126-1.el7    BUILT: Mon Jun 13 03:05:51 CDT 2016
device-mapper-event-1.02.126-1.el7    BUILT: Mon Jun 13 03:05:51 CDT 2016
device-mapper-event-libs-1.02.126-1.el7    BUILT: Mon Jun 13 03:05:51 CDT 2016
device-mapper-persistent-data-0.6.2-0.1.rc8.el7    BUILT: Wed May  4 02:56:34 CDT 2016
cmirror-2.02.156-1.el7    BUILT: Mon Jun 13 03:05:51 CDT 2016
sanlock-3.3.0-1.el7    BUILT: Wed Feb 24 09:52:30 CST 2016
sanlock-lib-3.3.0-1.el7    BUILT: Wed Feb 24 09:52:30 CST 2016
lvm2-lockd-2.02.156-1.el7    BUILT: Mon Jun 13 03:05:51 CDT 2016
Comment 2 Corey Marthaler 2016-09-02 20:56:30 UTC 
Still hitting this in the latest rpms.

3.10.0-497.el7.x86_64
lvm2-2.02.164-4.el7    BUILT: Wed Aug 31 08:47:09 CDT 2016
lvm2-libs-2.02.164-4.el7    BUILT: Wed Aug 31 08:47:09 CDT 2016
lvm2-cluster-2.02.164-4.el7    BUILT: Wed Aug 31 08:47:09 CDT 2016
device-mapper-1.02.133-4.el7    BUILT: Wed Aug 31 08:47:09 CDT 2016
device-mapper-libs-1.02.133-4.el7    BUILT: Wed Aug 31 08:47:09 CDT 2016
device-mapper-event-1.02.133-4.el7    BUILT: Wed Aug 31 08:47:09 CDT 2016
device-mapper-event-libs-1.02.133-4.el7    BUILT: Wed Aug 31 08:47:09 CDT 2016
device-mapper-persistent-data-0.6.3-1.el7    BUILT: Fri Jul 22 05:29:13 CDT 2016



[root@host-116 ~]# grep read_only /etc/lvm/lvm.conf
        # Configuration option global/metadata_read_only.
        metadata_read_only = 0
        # Configuration option activation/read_only_volume_list.
    read_only_volume_list = [ "@RO" ]



SCENARIO (raid10) - [kern_perm_change_of_raid_to_rw_after_tag_removal]
Verify in-kernel permission changes are possible when the metadata setting is different
** This test case may cause bug 1349661 **
** When this is run in isolation it passes, so if you see this it was most likely due to previous device configuration cases **
Create a raid with tags that match what is present in the read_only_volume_list and then change the in-kernel permissions
lvcreate  --type raid10 -n kern_perm -L 300M --addtag RO raid_sanity
  /dev/raid_sanity/kern_perm_rmeta_0: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_1: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_2: write failed after 0 of 4096 at 0: Operation not permitted
  /dev/raid_sanity/kern_perm_rmeta_3: write failed after 0 of 4096 at 0: Operation not permitted
  device-mapper: reload ioctl on (253:10) failed: Input/output error
  Failed to activate new LV.
couldn't create raid kern_perm



Aug 31 22:50:53 host-116 qarshd[14574]: Running cmdline: lvcreate --type raid10 -n kern_perm -L 300M --addtag RO raid_sanity
Aug 31 22:50:53 host-116 multipathd: dm-2: remove map (uevent)
Aug 31 22:50:53 host-116 multipathd: dm-2: devmap not registered, can't remove
Aug 31 22:50:53 host-116 multipathd: dm-2: remove map (uevent)
Aug 31 22:50:53 host-116 multipathd: dm-2: remove map (uevent)
Aug 31 22:50:53 host-116 multipathd: dm-2: devmap not registered, can't remove
Aug 31 22:50:53 host-116 multipathd: dm-2: remove map (uevent)
Aug 31 22:50:53 host-116 multipathd: dm-2: remove map (uevent)
Aug 31 22:50:53 host-116 multipathd: dm-2: devmap not registered, can't remove
Aug 31 22:50:53 host-116 multipathd: dm-2: remove map (uevent)
Aug 31 22:50:53 host-116 multipathd: dm-2: remove map (uevent)
Aug 31 22:50:53 host-116 multipathd: dm-2: devmap not registered, can't remove
Aug 31 22:50:53 host-116 multipathd: dm-2: remove map (uevent)
Aug 31 22:50:53 host-116 kernel: md/raid10:mdX: not enough operational mirrors.
Aug 31 22:50:53 host-116 kernel: md: pers->run() failed ...
Aug 31 22:50:53 host-116 kernel: device-mapper: table: 253:10: raid: Failed to run raid array
Aug 31 22:50:53 host-116 kernel: device-mapper: ioctl: error adding target to table
Aug 31 22:50:53 host-116 multipathd: dm-10: remove map (uevent)
Aug 31 22:50:53 host-116 multipathd: dm-10: remove map (uevent)
Comment 3 Heinz Mauelshagen 2018-08-30 13:21:35 UTC 
Corey,

this is fixed along with https://bugzilla.redhat.com/show_bug.cgi?id=1594916.

Can you please verify?
Comment 7 Roman Bednář 2018-09-19 13:31:07 UTC 
Verified with latest rpms.

lvm2-2.02.180-8.el7.x86_64
kernel-3.10.0-951.el7.x86_64

SCENARIO (raid10) - [kern_perm_change_of_raid_to_rw_after_tag_removal]
Verify in-kernel permission changes are possible when the metadata setting is different
** This test case may cause bug 1349661 **
** When this is run in isolation it passes, so if you see this it was most likely due to previous device configuration cases **
Create a raid with tags that match what is present in the read_only_volume_list and then change the in-kernel permissions
lvcreate  --type raid10 -n kern_perm -L 300M --addtag RO raid_sanity
  Error writing device /dev/raid_sanity/kern_perm at 0 length 4096.
	kern_perm:rRi-a-r---
[raid_sanity_raid10_kern_perm_change_of_raid_to_rw_after_tag_removal]
Attempting to write to ro raid
dd: writing to ‘/dev/raid_sanity/kern_perm’: Operation not permitted
1+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000198103 s, 0.0 kB/s
Remove the tags from the raid volume, and attempt to change the in kernel RW permissions
lvchange --deltag RO raid_sanity/kern_perm
lvchange -prw raid_sanity/kern_perm
	kern_perm:rwi-a-r---
perform raid scrubbing (lvchange --syncaction check) on raid raid_sanity/kern_perm
Waiting until all mirror|raid volumes become fully syncd...
   1/1 mirror(s) are fully synced: ( 100.00% )
Sleeping 15 sec
Deactivating raid kern_perm... and removing
Comment 9 errata-xmlrpc 2018-10-30 11:02:16 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/RHBA-2018:3193