Bug 1391090
| Summary: | able to mount vg-lv after successful vgexport of vg | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Nathaniel Weddle <nweddle> |
| Component: | lvm2 | Assignee: | David Teigland <teigland> |
| lvm2 sub component: | LVM Metadata / lvmetad | QA Contact: | cluster-qe <cluster-qe> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | high | ||
| Priority: | high | CC: | agk, cmarthal, coughlan, heinzm, jbrassow, jpittman, loberman, msnitzer, nweddle, prajnoha, prockai, rbednar, teigland, zkabelac |
| Version: | 7.2 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | lvm2-2.02.169-1.el7 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-08-01 21:49:49 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: | |||
| Bug Blocks: | 1385242 | ||
|
Description
Nathaniel Weddle
2016-11-02 14:27:31 UTC
(In reply to Nathaniel Weddle from comment #0) > Description of problem: > following successful vgexport of vg, vg-lv may be mounted manually, or will > be mounted by fstab after reboot > > Version-Release number of selected component (if applicable): > RHEL7.0 to current release > > How reproducible: > 100% > > Steps to Reproduce: > 1.vgchange -an myvg > 2.vgexport myvg > 3.mount myvg-lv /mnt/test Was the deactivation successfully finish (return code 0) ? No error reported. Can you capture 'dmsetup table' before vgexport ? It's for now unclear how you would be able to mount 'inactive' LV ? It works correctly for me with 7.2 and the latest code. In addition to the commands that Zdenek suggested, I'd also run the following to ensure they are all reporting what we expect: before vgexport: vgchange -an myvg vgs myvg lvs myvg ls /dev/myvg dmsetup table after vgexport: ls /dev/myvg dmsetup table vgs myvg lvs myvg lvchange -ay myvg/lv Zdenek, David,
I've attached my reproduction on this. And here is the cli output:
Reproduction; use_lvmetad must be set to 1:
===========================================
[root@localhost ~]# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home rhel -wi-ao---- 1.00g
root rhel -wi-ao---- 5.02g
swap rhel -wi-ao---- 1000.00m
testlv testvg -wi-ao---- 1020.00m
[root@localhost ~]# umount /test1
[root@localhost ~]# vgchange -an testvg
0 logical volume(s) in volume group "testvg" now active
[root@localhost ~]# vgexport testvg
Volume group "testvg" successfully exported
......reboot.....
[root@localhost ~]# lvs
Volume group testvg is exported
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
home rhel -wi-ao---- 1.00g
root rhel -wi-ao---- 5.02g
swap rhel -wi-ao---- 1000.00m
[root@localhost ~]# ls /dev/mapper | grep test
testvg-testlv
[root@localhost ~]# mount | grep test
/dev/mapper/testvg-testlv on /test1 type ext4 (rw,relatime,seclabel,data=ordered)
I will look further in the morning and provide the info you've requested.
Zdenek, David,
Had some extra time... Here is the info requested.
[root@localhost ~]# umount /test1/
[root@localhost ~]# vgchange -an testvg
0 logical volume(s) in volume group "testvg" now active
[root@localhost ~]# vgs testvg
VG #PV #LV #SN Attr VSize VFree
testvg 1 1 0 wz--n- 1020.00m 0
[root@localhost ~]# lvs testvg
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
testlv testvg -wi------- 1020.00m
[root@localhost ~]# ls /dev/testvg
ls: cannot access /dev/testvg: No such file or directory
[root@localhost ~]# dmsetup table
rhel-home: 0 2097152 linear 252:2 10520576
testvg-testlv: 0 2088960 linear 8:1 2048
rhel-swap: 0 2048000 linear 252:2 12617728
rhel-root: 0 10518528 linear 252:2 2048
[root@localhost ~]# vgexport testvg
Volume group "testvg" successfully exported
[root@localhost ~]# echo $?
0
[root@localhost ~]# ls /dev/testvg
ls: cannot access /dev/testvg: No such file or directory
[root@localhost ~]# dmsetup table
rhel-home: 0 2097152 linear 252:2 10520576
rhel-swap: 0 2048000 linear 252:2 12617728
rhel-root: 0 10518528 linear 252:2 2048
[root@localhost ~]# vgs testvg
VG #PV #LV #SN Attr VSize VFree
testvg 1 1 0 wzx-n- 1020.00m 0
[root@localhost ~]# lvs testvg
Volume group testvg is exported
[root@localhost ~]# lvchange -ay testvg/testlv
Volume group testvg is exported
[root@localhost ~]# rpm -qa | egrep 'lvm*|udev*|device-mapper*|kernel*'
device-mapper-multipath-0.4.9-85.el7_2.6.x86_64
device-mapper-libs-1.02.107-5.el7_2.5.x86_64
lvm2-libs-2.02.130-5.el7_2.5.x86_64
device-mapper-persistent-data-0.6.2-1.el7_2.x86_64
kernel-3.10.0-327.el7.x86_64
device-mapper-multipath-libs-0.4.9-85.el7_2.6.x86_64
libgudev1-219-19.el7_2.13.x86_64
python-gudev-147.2-7.el7.x86_64
device-mapper-1.02.107-5.el7_2.5.x86_64
device-mapper-event-1.02.107-5.el7_2.5.x86_64
kernel-tools-libs-3.10.0-327.36.3.el7.x86_64
lvm2-2.02.130-5.el7_2.5.x86_64
kernel-3.10.0-327.36.3.el7.x86_64
python-pyudev-0.15-7.el7_2.1.noarch
device-mapper-event-libs-1.02.107-5.el7_2.5.x86_64
kernel-tools-3.10.0-327.36.3.el7.x86_64
Thanks, you're correct, I see the same here. The 'pvscan --cache -aay' activation path is failing to respect the exported state of the VG. fixed here https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=68e7d3496517a70e50edaceff906ad1da23821a6 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-2017:2222 |