#2591 PR merged: Automatically shrink LVs if needed during "rear recover"¶
Labels: enhancement, fixed / solved / done, severe improvement
jsmeix opened issue at 2021-03-25 12:14:¶
-
Type: Enhancement
-
Impact: High
This enables to run "rear recover" with automated LVM LVs shrinking as needed
on a bit smaller replacement disk (e.g. when a nominally same sized replacement disk
is actually a bit smaller than the original disk).
The automated LVs shrinking is not intended when replacement disk(s) are substantially smaller.
To migrate onto a substantially smaller replacement disk the user must in advance
manually adapt his disklayout.conf file before he runs "rear recover". -
How was this pull request tested?
On my SLES 15 SP 3 system with the YaST default LVM setup as in
"SLES 15 SP 1 with default LVM and btrfs structure" in
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6
where "rear recover" runs on a 1GiB smaller disk
i.e. 19GiB on the replacement VM
with those additional entries in etc/rear/local.conf
AUTORESIZE_PARTITIONS=( /dev/sda2 )
AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE=20
- Brief description of the changes in this pull request:
In layout/prepare/GNU/Linux/110_include_lvm_code.sh
assume lvcreate had failed because of "Volume group ... has insufficient
free space"
which usually happens when the replacement disk is a bit smaller than
the original disk
so that the following fallback attempt to create a LV could work at
least once per VG
which is sufficient when the replacement disk is a bit smaller than the
original disk
because then the last LV that is created gets shrinked to the remaining
space in the VG.
In the lvopts string replace the exact size option of the form
-L 123456b
with an option to use all remaining free space in the VG via
-l 100%FREE
so e.g. lvcreate -L 123456b -n LV VG
becomes lvcreate -l 100%FREE -n LV VG
In layout/save/GNU/Linux/220_lvm_layout.sh
sort the 'lvs' output lines by the size of the LVs
as a precondition to make automated shrinking of LVs
work reasonably well with a "minimal changes" approach where
only some biggest LVs may get automatically shrinked (if needed)
because we assume that the data of the backup can still be restored
into a big LV after it was shrinked a bit.
jsmeix commented at 2021-03-25 12:23:¶
This is the first result of my current SUSE Hack Week project
https://hackweek.suse.com/20/projects/improve-relax-and-recover-rear-system-migration-different-disk-size-support
jsmeix commented at 2021-03-25 12:30:¶
@gdha @gozora @rmetrich @pcahyna @OliverO2
I would much appreciate it if you could have a look here.
For me it "just works" so far and I would be interested what you think
about it.
I am not a LVM expert so I may have overlooked something.
What I am wondering about is why it "just works" for me
regardless that I did not yet also shrink the size of the VG.
goodale commented at 2021-03-25 12:33:¶
Your post is timely and raises a question from me.
I am looking to replace two 500GB HDD’s (sda/sdb running as md0 with SW
RAID 1)
with two 512GB SSD’s and use REAR to create the backup before the
replacement
and then restore onto the new SDD’s.
Can I expect this to work with the latest version of rear?
jsmeix commented at 2021-03-25 12:38:¶
@goodale
recreating on bigger disks should not cause severe problems
provided you keep the layout of the storage objects.
See the
AUTORESIZE_PARTITIONS
AUTORESIZE_EXCLUDE_PARTITIONS
AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE
AUTOINCREASE_DISK_SIZE_THRESHOLD_PERCENTAGE
config variables description in usr/share/rear/conf/default.conf
If you use LVM this pull request is only about automated shrinking for
smaller disks.
Currently there is no automated increasing of LVM storage objects.
jsmeix commented at 2021-03-26 12:32:¶
Regarding how ReaR recreates the VG in my case:
My disklayout.conf contains
# Format for LVM PVs
# lvmdev <volume_group> <device> [<uuid>] [<size(bytes)>]
lvmdev /dev/system /dev/sda2 2SpJI1-1hPC-nqVV-3lXq-Ft7C-qnuh-AReMfY 41924575
# Format for LVM VGs
# lvmgrp <volume_group> <extentsize> [<size(extents)>] [<size(bytes)>]
lvmgrp /dev/system 4096 5117 20959232
# Format for LVM LVs
# lvmvol <volume_group> <name> <size(bytes)> <layout> [key:value ...]
lvmvol /dev/system swap 1262485504b linear
lvmvol /dev/system home 6148849664b linear
lvmvol /dev/system root 14050918400b linear
Therein the size(bytes) value 20959232 of the lvmgrp is plain wrong
because 20959232 bytes are only 19.98828125 MiB.
Also the size(bytes) value 41924575 of the lvmdev does not look right.
But it seems that doesn't matter because
on my recreated system my /var/log/rear/recover/rear-localhost.log shows
++ source /var/lib/rear/layout/diskrestore.sh
...
+++ Print 'Creating LVM VG '\''system'\'' (some properties may not be preserved)'
+++ lvm vgremove --force --force --yes system
Failed to clear hint file.
Volume group "system" not found
Cannot process volume group system
+++ true
+++ '[' -e /dev/system ']'
+++ lvm vgcreate --physicalextentsize 4096k system /dev/sda2
Failed to clear hint file.
Volume group "system" successfully created
+++ lvm vgchange --available y system
0 logical volume(s) in volume group "system" now active
+++ component_created /dev/system lvmgrp
So it seems VGs are recreated without specifying its size
and according to how I understand "man vgcreate"
one cannot specify the size of a VG and I assume
there is no such thing as a VG size because
the size of a VG is the sum of its PVs sizes (minus VG metadata).
On my recreated system I have
# lsblk -ipbo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT
/dev/sda /dev/sda ata disk 20401094656
|-/dev/sda1 /dev/sda1 /dev/sda part 8388608
`-/dev/sda2 /dev/sda2 /dev/sda part LVM2_member 20390608896
|-/dev/mapper/system-root /dev/dm-0 /dev/sda2 lvm btrfs 12977176576 /
|-/dev/mapper/system-swap /dev/dm-1 /dev/sda2 lvm swap 1262485504 [SWAP]
`-/dev/mapper/system-home /dev/dm-2 /dev/sda2 lvm xfs 6148849664 /home
/dev/sr0 /dev/sr0 ata rom iso9660 121964544
# vgs --units b
VG #PV #LV #SN Attr VSize VFree
system 1 3 0 wz--n- 20388511744B 0B
The VG size of 20388511744 bytes = 19444 MiB
matches the size of its PV /dev/sda2 size = 20390608896 bytes = 19446
MiB
so the VG is 2 MiB smaller than its PV and that 2 MiB are used for VG
metadata.
jsmeix commented at 2021-03-26 12:46:¶
In a separated cleanup attempt I may (as time permits)
have a closer look at those wrong looking size(bytes) values
for lvmgrp and lvmdev entries in disklayout.conf
and remove them from disklayout.conf when they are not used
because I think unused and possibly wrong data in disklayout.conf
is worse than having no such data at all. Furthermore since
https://github.com/rear/rear/commit/d8946bcc1cc61086b392e5d85ce956fdcd7d69cf
we have 'lsblk' output as disklayout.conf header comments
e.g. in my disklayout.conf
# Disk layout dated 20210325121244 (YYYYmmddHHMMSS)
# NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT
# /dev/sda /dev/sda ata disk 20G
# |-/dev/sda1 /dev/sda1 /dev/sda part 8M
# `-/dev/sda2 /dev/sda2 /dev/sda part LVM2_member 20G
# |-/dev/mapper/system-swap /dev/dm-0 /dev/sda2 lvm swap 1.2G [SWAP]
# |-/dev/mapper/system-root /dev/dm-1 /dev/sda2 lvm btrfs 13.1G /
# `-/dev/mapper/system-home /dev/dm-2 /dev/sda2 lvm xfs 5.7G /home
# /dev/sr0 /dev/sr0 ata rom 1024M
so human readable (but not exact) size values are there.
Perhaps I may change that lsblk output to show sizes as bytes via '
-b'
to have exact (but less human readable) size values in disklayout.conf?
jsmeix commented at 2021-03-26 12:52:¶
Regarding how ReaR recreates the PV in my case:
On my recreated system my /var/log/rear/recover/rear-localhost.log shows
++ source /var/lib/rear/layout/diskrestore.sh
...
+++ Print 'Creating LVM PV /dev/sda2'
+++ lvm vgchange -a n system
0 logical volume(s) in volume group "system" now active
+++ lvm pvcreate -ff --yes -v --uuid 2SpJI1-1hPC-nqVV-3lXq-Ft7C-qnuh-AReMfY --norestorefile /dev/sda2
Failed to clear hint file.
Wiping signatures on new PV /dev/sda2.
Set up physical volume for "/dev/sda2" with 39825408 available sectors.
Zeroing start of device /dev/sda2.
Writing physical volume data to disk "/dev/sda2".
Physical volume "/dev/sda2" successfully created.
+++ component_created pv:/dev/sda2 lvmdev
so also no size is specified when creating the PV
and setphysicalvolumesize appears nowhere in the ReaR scripts
# find usr/share/rear/ -type f | xargs grep -i setphysicalvolumesize
[no output]
jsmeix commented at 2021-03-26 12:58:¶
SUSE Hack Week ends today and if there are no objections
I would like to merge it next Monday afternoon.
Have a relaxed and recovering weekend!
jsmeix commented at 2021-10-11 13:39:¶
Tested it with LVM inside LUKS
on SLES15
on KVM VM
with original disk size 20GiB
on replacement disk with only 17 GiB
which requires AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE=80
Original system:
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT,UUID /dev/sda
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT UUID
/dev/sda /dev/sda ata disk 20G
|-/dev/sda1 /dev/sda1 /dev/sda part 8M
`-/dev/sda2 /dev/sda2 /dev/sda part crypto_LUKS 20G 0c58676a-bcb6-42be-8e1c-46a24d954ca7
`-/dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2 /dev/dm-0 /dev/sda2 crypt LVM2_member 20G zJalOt-2mjE-OrW4-MRxO-ErID-beeL-rRwzOp
|-/dev/mapper/system-swap /dev/dm-1 /dev/dm-0 lvm swap 2G [SWAP] a88670c6-43c7-4024-822f-f0fa0d00cfbc
|-/dev/mapper/system-root /dev/dm-2 /dev/dm-0 lvm btrfs 12.6G / bd326c18-0806-47d7-a740-97d5047d7de4
`-/dev/mapper/system-home /dev/dm-3 /dev/dm-0 lvm xfs 5.4G /home c9a5ebc9-3eac-4aa8-a768-731295af64a8
# grep -v '^#' etc/rear/local.conf
OUTPUT=ISO
BACKUP=NETFS
BACKUP_OPTIONS="nfsvers=3,nolock"
BACKUP_URL=nfs://192.168.122.1/nfs
REQUIRED_PROGS+=( snapper chattr )
PROGS+=( lsattr )
COPY_AS_IS+=( /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
BACKUP_PROG_INCLUDE=( /srv /root /tmp /boot/grub2/x86_64-efi /usr/local /var /boot/grub2/i386-pc /opt )
POST_RECOVERY_SCRIPT=( 'if snapper --no-dbus -r $TARGET_FS_ROOT get-config | grep -q "^QGROUP.*[0-9]/[0-9]" ; then snapper --no-dbus -r $TARGET_FS_ROOT set-config QGROUP= ; snapper --no-dbus -r $TARGET_FS_ROOT setup-quota && echo snapper setup-quota done || echo snapper setup-quota failed ; else echo snapper setup-quota not used ; fi' )
SSH_ROOT_PASSWORD="rear"
USE_DHCLIENT="yes"
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="3"
FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )
LUKS_CRYPTSETUP_OPTIONS+=" --force-password"
AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE=80
Recovery on replacement VM:
# rear -D recover
Relax-and-Recover 2.6 / Git
Running rear recover (PID 2674 date 2021-10-11 14:52:45)
Command line options: /bin/rear -D recover
Using log file: /var/log/rear/rear-linux-uxxi.log
Using build area: /var/tmp/rear.75c7IDA9CCSNTJ4
Running workflow recover within the ReaR rescue/recovery system
Starting required daemons for NFS: RPC portmapper (portmap or rpcbind) and rpc.statd if available.
Started RPC portmapper 'rpcbind'.
RPC portmapper 'rpcbind' available.
RPC status rpc.statd available.
Using backup archive '/var/tmp/rear.75c7IDA9CCSNTJ4/outputfs/linux-uxxi/backup.tar.gz'
Will do driver migration (recreating initramfs/initrd)
Calculating backup archive size
Backup archive size is 1.8G /var/tmp/rear.75c7IDA9CCSNTJ4/outputfs/linux-uxxi/backup.tar.gz (compressed)
Comparing disks
Device sda has size 18253611008 bytes but 21474836480 bytes is expected (needs manual configuration)
Switching to manual disk layout configuration
Original disk /dev/sda does not exist (with same size) in the target system
Using /dev/sda (the only appropriate) for recreating /dev/sda
Current disk mapping table (source => target):
/dev/sda => /dev/sda
UserInput -I LAYOUT_MIGRATION_CONFIRM_MAPPINGS needed in /usr/share/rear/layout/prepare/default/300_map_disks.sh line 275
Confirm or edit the disk mapping
1) Confirm disk mapping and continue 'rear recover'
2) Confirm identical disk mapping and proceed without manual configuration
3) Edit disk mapping (/var/lib/rear/layout/disk_mappings)
4) Use Relax-and-Recover shell and return back to here
5) Abort 'rear recover'
(default '1' timeout 300 seconds)
UserInput: No real user input (empty or only spaces) - using default input
UserInput: Valid choice number result 'Confirm disk mapping and continue 'rear recover''
User confirmed disk mapping
Disabling excluded components in /var/lib/rear/layout/disklayout.conf
Applied disk layout mappings to /var/lib/rear/layout/disklayout.conf
Applied disk layout mappings to /var/lib/rear/layout/config/df.txt
Applied disk layout mappings to /etc/rear/rescue.conf
Examining gpt disk /dev/sda to automatically resize its last active partition
Checking /dev/sda1 if it is the last partition on /dev/sda
Checking /dev/sda2 if it is the last partition on /dev/sda
Found 'rear-noname' partition /dev/sda2 as last partition on /dev/sda
Determining if last partition /dev/sda2 is resizeable
Determining new size for last partition /dev/sda2
Determining if last partition /dev/sda2 actually needs to be increased or shrinked
New /dev/sda is 3221225472 bytes smaller than old disk
Last partition /dev/sda2 must be shrinked by 3222257152 bytes to still fit on disk
Shrinking last partition /dev/sda2 to end of disk (new disk at most 80% smaller)
Changed last partition /dev/sda2 size from 21465382400 to 18243125248 bytes
UserInput -I LAYOUT_FILE_CONFIRMATION needed in /usr/share/rear/layout/prepare/default/500_confirm_layout_file.sh line 26
Confirm or edit the disk layout file
1) Confirm disk layout and continue 'rear recover'
2) Edit disk layout (/var/lib/rear/layout/disklayout.conf)
3) View disk layout (/var/lib/rear/layout/disklayout.conf)
4) View original disk space usage (/var/lib/rear/layout/config/df.txt)
5) Use Relax-and-Recover shell and return back to here
6) Abort 'rear recover'
(default '1' timeout 300 seconds)
UserInput: No real user input (empty or only spaces) - using default input
UserInput: Valid choice number result 'Confirm disk layout and continue 'rear recover''
User confirmed disk layout file
Marking component '/dev/sda' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/sda1' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/sda2' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'pv:/dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'pv:/dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/system' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/mapper/system-swap' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/mapper/system-home' as done in /var/lib/rear/layout/disktodo.conf
Marking component '/dev/mapper/system-root' as done in /var/lib/rear/layout/disktodo.conf
Doing SLES-like btrfs subvolumes setup for /dev/mapper/system-root on / (BTRFS_SUBVOLUME_SLES_SETUP contains /dev/mapper/system-root)
SLES12-SP1 (and later) btrfs subvolumes setup needed for /dev/mapper/system-root (default subvolume path contains '@/.snapshots/')
Marking component 'fs:/' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'fs:/home' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/.snapshots' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/srv' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/root' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/boot/grub2/x86_64-efi' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/usr/local' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/var' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/boot/grub2/i386-pc' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/tmp' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'btrfsmountedsubvol:/opt' as done in /var/lib/rear/layout/disktodo.conf
Marking component 'swap:/dev/mapper/system-swap' as done in /var/lib/rear/layout/disktodo.conf
UserInput -I LAYOUT_CODE_CONFIRMATION needed in /usr/share/rear/layout/recreate/default/100_confirm_layout_code.sh line 26
Confirm or edit the disk recreation script
1) Confirm disk recreation script and continue 'rear recover'
2) Edit disk recreation script (/var/lib/rear/layout/diskrestore.sh)
3) View disk recreation script (/var/lib/rear/layout/diskrestore.sh)
4) View original disk space usage (/var/lib/rear/layout/config/df.txt)
5) Use Relax-and-Recover shell and return back to here
6) Abort 'rear recover'
(default '1' timeout 300 seconds)
UserInput: No real user input (empty or only spaces) - using default input
UserInput: Valid choice number result 'Confirm disk recreation script and continue 'rear recover''
User confirmed disk recreation script
Start system layout restoration.
Disk '/dev/sda': creating 'gpt' partition table
Disk '/dev/sda': creating partition number 1 with name ''sda1''
Disk '/dev/sda': creating partition number 2 with name ''sda2''
Creating LUKS volume cr_ata-QEMU_HARDDISK_QM00001-part2 on /dev/sda2
Set the password for LUKS volume cr_ata-QEMU_HARDDISK_QM00001-part2 (for 'cryptsetup luksFormat' on /dev/sda2):
Enter passphrase for /dev/sda2:
Enter the password for LUKS volume cr_ata-QEMU_HARDDISK_QM00001-part2 (for 'cryptsetup luksOpen' on /dev/sda2):
Enter passphrase for /dev/sda2:
Creating LVM PV /dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2
Creating LVM VG 'system' (some properties may not be preserved)
Creating LVM volume 'system/swap' (some properties may not be preserved)
Creating LVM volume 'system/home' (some properties may not be preserved)
Creating LVM volume 'system/root' (some properties may not be preserved)
Failed to create LVM volume 'system/root' with lvcreate -L 13518241792b -n root system
Created LVM volume 'system/root' using fallback options lvcreate -l 100%FREE -n root system
Creating filesystem of type btrfs with mount point / on /dev/mapper/system-root.
Mounting filesystem /
Running snapper/installation-helper
Creating filesystem of type xfs with mount point /home on /dev/mapper/system-home.
Mounting filesystem /home
Creating swap on /dev/mapper/system-swap
Disk layout created.
UserInput -I LAYOUT_MIGRATED_CONFIRMATION needed in /usr/share/rear/layout/recreate/default/200_run_layout_code.sh line 98
Confirm the recreated disk layout or go back one step
1) Confirm recreated disk layout and continue 'rear recover'
2) Go back one step to redo disk layout recreation
3) Use Relax-and-Recover shell and return back to here
4) Abort 'rear recover'
(default '1' timeout 300 seconds)
UserInput: No real user input (empty or only spaces) - using default input
UserInput: Valid choice number result 'Confirm recreated disk layout and continue 'rear recover''
User confirmed recreated disk layout
Restoring from '/var/tmp/rear.75c7IDA9CCSNTJ4/outputfs/linux-uxxi/backup.tar.gz' (restore log in /var/lib/rear/restore/recover.backup.tar.gz.2674.restore.log) ...
Backup restore program 'tar' started in subshell (PID=7444)
Restored 174 MiB [avg. 59466 KiB/sec]
...
Restored 3562 MiB [avg. 31723 KiB/sec]
OK
Restored 3622 MiB in 118 seconds [avg. 31439 KiB/sec]
Restoring finished (verify backup restore log messages in /var/lib/rear/restore/recover.backup.tar.gz.2674.restore.log)
Created SELinux /mnt/local/.autorelabel file : after reboot SELinux will relabel all files
Recreating directories (with permissions) from /var/lib/rear/recovery/directories_permissions_owner_group
Migrating disk-by-id mappings in certain restored files in /mnt/local to current disk-by-id mappings ...
Replacing restored udev rule '/mnt/local//etc/udev/rules.d/70-persistent-net.rules' with the one from the ReaR rescue system
Migrating restored network configuration files according to the mapping files ...
UserInput -I RESTORED_FILES_CONFIRMATION needed in /usr/share/rear/finalize/default/520_confirm_finalize.sh line 41
Confirm restored config files are OK or adapt them as needed
1) Confirm it is OK to recreate initrd and reinstall bootloader and continue 'rear recover'
2) Edit restored etc/fstab (/mnt/local/etc/fstab)
3) View restored etc/fstab (/mnt/local/etc/fstab)
4) Use Relax-and-Recover shell and return back to here
5) Abort 'rear recover'
(default '1' timeout 300 seconds)
UserInput: No real user input (empty or only spaces) - using default input
UserInput: Valid choice number result 'Confirm it is OK to recreate initrd and reinstall bootloader and continue 'rear recover''
User confirmed restored files
Running mkinitrd...
Recreated initrd (/sbin/mkinitrd).
Installing GRUB2 boot loader...
Determining where to install GRUB2 (no GRUB2_INSTALL_DEVICES specified)
Found possible boot disk /dev/sda - installing GRUB2 there
Finished 'recover'. The target system is mounted at '/mnt/local'.
Exiting rear recover (PID 2674) and its descendant processes ...
Running exit tasks
To remove the build area use (with caution): rm -Rf --one-file-system /var/tmp/rear.75c7IDA9CCSNTJ4
# reboot
On the recreated system:
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT,UUID /dev/sda
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT UUID
/dev/sda /dev/sda ata disk 17G
|-/dev/sda1 /dev/sda1 /dev/sda part 8M
`-/dev/sda2 /dev/sda2 /dev/sda part crypto_LUKS 17G 0c58676a-bcb6-42be-8e1c-46a24d954ca7
`-/dev/mapper/cr_ata-QEMU_HARDDISK_QM00001-part2 /dev/dm-0 /dev/sda2 crypt LVM2_member 17G zJalOt-2mjE-OrW4-MRxO-ErID-beeL-rRwzOp
|-/dev/mapper/system-root /dev/dm-1 /dev/dm-0 lvm btrfs 9.6G / bd326c18-0806-47d7-a740-97d5047d7de4
|-/dev/mapper/system-swap /dev/dm-2 /dev/dm-0 lvm swap 2G [SWAP] a88670c6-43c7-4024-822f-f0fa0d00cfbc
`-/dev/mapper/system-home /dev/dm-3 /dev/dm-0 lvm xfs 5.4G /home c9a5ebc9-3eac-4aa8-a768-731295af64a8
[Export of Github issue for rear/rear.]