Bug 1732308

Summary: Backport PR 2194
Product: Red Hat Enterprise Linux 8 Reporter: Renaud Métrich <rmetrich>
Component: rearAssignee: Pavel Cahyna <pcahyna>
Status: CLOSED ERRATA QA Contact: David Jež <djez>
Severity: medium Docs Contact:
Priority: medium    
Version: ---CC: djez, pcahyna
Target Milestone: rcFlags: pm-rhel: mirror+
Target Release: 8.2   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: rear-2.4-11.el8 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-28 15:47:07 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: 1732328    
Bug Blocks: 1746915, 1755139    

Description Renaud Métrich 2019-07-23 07:10:28 UTC
Description of problem:

We need to backport Upstream PR https://github.com/rear/rear/pull/2194 to our ReaR-2.4 to fix an issue when recovering a system in Migration Mode (happens when a different system is used or disks have not same size) or when Thin Pools are used.
Without the fix, multiple "lvmvol" lines for same LV are added in disklayout.conf, causing multiple "lvcreate" commands for same LV to be used, which breaks the recovery.


Version-Release number of selected component (if applicable):

rear-2.4


How reproducible:

Always


Steps to Reproduce:

1. Add 2 disks to an existing system (to enable creating stripes)

2. Create a VG with the disks

# vgcreate data /dev/sdb /dev/sdc

3. Create 2 LVs with segments

# lvcreate -n lv1 -L 1G data
# lvcreate -n lv2 -L 1G data
# lvextend /dev/data/lv1 -L +1G -i 2
# lvextend /dev/data/lv2 -L +1G -i 2
# lvextend /dev/data/lv1 -L +1G -i 1
# lvextend /dev/data/lv2 -L +1G -i 1

4. Format and mount the LVs

# mkdir -p /lv1 /lv2
# mkfs.ext4 /dev/data/lv1
# mkfs.ext4 /dev/data/lv2
# mount /dev/data/lv1 /lv1
# mount /dev/data/lv2 /lv2

5. Create rescue ISO

# rear mkrescue

6. Check /var/lib/rear/layout/disklayout.conf


Actual results:

(broken)
# lvmvol <volume_group> <name> <size(bytes)> <layout> [key:value ...]
lvmvol /dev/data lv1 3221225472b linear,striped stripes:1
lvmvol /dev/data lv1 3221225472b linear,striped stripesize:65536b stripes:2
lvmvol /dev/data lv1 3221225472b linear,striped stripes:1
lvmvol /dev/data lv2 2147483648b linear,striped stripes:1
lvmvol /dev/data lv2 2147483648b linear,striped stripesize:65536b stripes:2


Expected results:

(with the fix)
# lvmvol <volume_group> <name> <size(bytes)> <layout> [key:value ...]
# WARNING: Volume data/lv1 has multiple segments. Restoring it in Migration Mode using 'lvcreate' won't preserve segments and volume properties of the other segments!
lvmvol /dev/data lv1 3221225472b linear,striped segmentsize:1073741824b stripes:1
#lvmvol /dev/data lv1 3221225472b linear,striped stripesize:65536b segmentsize:1073741824b stripes:2
#lvmvol /dev/data lv1 3221225472b linear,striped segmentsize:1073741824b stripes:1
# WARNING: Volume data/lv2 has multiple segments. Restoring it in Migration Mode using 'lvcreate' won't preserve segments and volume properties of the other segments!
lvmvol /dev/data lv2 2147483648b linear,striped segmentsize:1073741824b stripes:1
#lvmvol /dev/data lv2 2147483648b linear,striped stripesize:65536b segmentsize:1073741824b stripes:2


Additional info:

When in Migration Mode or when recreating Thin Pools, the LV will be recreated using one segment only, which characteristics (e.g. "stripes") of the first segment only.
This is sub-optimal but too complicated to do differently.

Comment 1 Pavel Cahyna 2019-09-02 12:49:20 UTC
I would like to ask whether in light of bz1747468 it makes sense to fix this one or if rather a different approach to fix both is needed.

Comment 2 Renaud Métrich 2019-10-22 06:12:48 UTC
I would recommend fixing both with the current approach from Upstream for now.

Comment 6 errata-xmlrpc 2020-04-28 15:47:07 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-2020:1648