#2714 PR merged: Overhauled RAID code¶
Labels: enhancement, cleanup, fixed / solved / done
jsmeix opened issue at 2021-11-16 11:49:¶
-
Type: Cleanup
-
Impact: High
That old code drives me nuts.
In particular its confusing variable names, cf. the "By the way" part in
https://github.com/rear/rear/pull/2702#issuecomment-968934959 -
Reference to related issue (URL):
https://github.com/rear/rear/pull/2702 -
How was this pull request tested?
With a simple RAID1 array (two component devices /dev/sda and /dev/sdb)
I got sameraidline values in disklayout.conf after "rear mkrescue".
But I could have made mistakes for other types of RAID arrays. -
Brief description of the changes in this pull request:
Overhauled layout/save/GNU/Linux/210_raid_layout.sh
based on
https://github.com/rear/rear/pull/2702
i.e. with the changes in
https://github.com/rear/rear/pull/2702
jsmeix commented at 2021-11-16 13:33:¶
I had "rear recover" issues which is unexpected because
my changes did not result any changed entry in disklayout.conf for me.
Both the original system and the replacement system are QEMU/KVM VMs
with 12GiB /dev/sda and /dev/sdb for the RAID1 array
and 1 GiB /dev/sdc for swap.
My disk layout on the original system with a
RAID1 array of the plain /dev/sda and /dev/sdb disks as component
devices
# lsblk -ipo NAME,KNAME,PKNAME,TYPE,FSTYPE,MOUNTPOINT,UUID
NAME KNAME PKNAME TYPE FSTYPE MOUNTPOINT UUID
/dev/sda /dev/sda disk linux_raid_member 8d05eb84-2de8-31d1-dfed-54b2ad592118
`-/dev/md127 /dev/md127 /dev/sda raid1
|-/dev/md127p1 /dev/md127p1 /dev/md127 part
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs / 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdb /dev/sdb disk linux_raid_member 8d05eb84-2de8-31d1-dfed-54b2ad592118
`-/dev/md127 /dev/md127 /dev/sdb raid1
|-/dev/md127p1 /dev/md127p1 /dev/md127 part
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs / 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdc /dev/sdc disk
`-/dev/sdc1 /dev/sdc1 /dev/sdc part swap [SWAP] 9c606f48-92cd-4f98-be22-0f8a75358bed
My disklayoutt.conf (without comments and lengthy btrfs stuff):
# egrep -v '^#|^btrfs' /var/lib/rear/layout/disklayout.conf
disk /dev/sda 12884901888 gpt
disk /dev/sdb 12884901888 gpt
disk /dev/sdc 1073741824 gpt
part /dev/sdc 1072676352 1048576 rear-noname swap /dev/sdc1
raid /dev/md127 metadata=1.0 level=raid1 raid-devices=2 uuid=8d05eb84:2de831d1:dfed54b2:ad592118 name=raid1sdab devices=/dev/sda,/dev/sdb
part /dev/md127 10485760 1048576 rear-noname bios_grub /dev/md127p1
part /dev/md127 12739067392 11534336 rear-noname none /dev/md127p2
fs /dev/mapper/cr_root / btrfs uuid=85406026-0559-4b0d-8f67-ec19d3b556f5 label= options=rw,relatime,space_cache,subvolid=256,subvol=/@
swap /dev/sdc1 uuid=9c606f48-92cd-4f98-be22-0f8a75358bed label=
crypt /dev/mapper/cr_root /dev/md127p2 type=luks1 cipher=aes-xts-plain64 key_size=512 hash=sha256 uuid=d0446c00-9e79-4872-abaa-2d464fd71c99
Excepts how "rear recover" recreates the disk layout:
Start system layout restoration.
Disk '/dev/sdc': creating 'gpt' partition table
Disk '/dev/sdc': creating partition number 1 with name ''sdc1''
Creating software RAID /dev/md127
Disk '/dev/md127': creating 'gpt' partition table
Disk '/dev/md127': creating partition number 1 with name ''md127p1''
Disk '/dev/md127': creating partition number 2 with name ''md127p2''
Creating swap on /dev/sdc1
Creating LUKS volume cr_root on /dev/md127p2
Set the password for LUKS volume cr_root (for 'cryptsetup luksFormat' on /dev/md127p2):
Enter passphrase for /dev/md127p2:
Enter the password for LUKS volume cr_root (for 'cryptsetup luksOpen' on /dev/md127p2):
Enter passphrase for /dev/md127p2:
Creating filesystem of type btrfs with mount point / on /dev/mapper/cr_root.
Mounting filesystem /
Disk layout created.
Then I had this "rear recover" failures (excerpt)
Installing GRUB2 boot loader...
Determining where to install GRUB2 (no GRUB2_INSTALL_DEVICES specified)
Found possible boot disk /dev/sda
/dev/sdb - installing GRUB2 there
Failed to install GRUB2 on possible boot disk /dev/sda
/dev/sdb
Found possible boot disk /dev/sda
/dev/sdb - installing GRUB2 there
Failed to install GRUB2 on possible boot disk /dev/sda
...
so some strange confusion about sda and sdb
during autodetection where to install GRUB.
Therefore (in the recovery system) I added to /etc/rear/local.conf
GRUB2_INSTALL_DEVICES="/dev/sda /dev/sdb"
and commented the Error exit in
usr/share/rear/lib/finalizeonly-workflow.sh
so that I could run the finalizeonly workflow as a quick and dirty hack
and
I did "rear -D finalizeonly" to re-install GRUB which worked:
Running mkinitrd...
Recreated initrd (/sbin/mkinitrd).
Installing GRUB2 boot loader...
Installing GRUB2 on /dev/sda (specified in GRUB2_INSTALL_DEVICES)
Installing GRUB2 on /dev/sdb (specified in GRUB2_INSTALL_DEVICES)
In the recovery system I got this recreated disk layout shown
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT,UUID
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT UUID
/dev/sda /dev/sda ata disk linux_raid_member 12G 8d05eb84-2de8-31d1-dfed-54b2ad592118
|-/dev/sda1 /dev/sda1 /dev/sda part linux_raid_member 10M 8d05eb84-2de8-31d1-dfed-54b2ad592118
|-/dev/sda2 /dev/sda2 /dev/sda part crypto_LUKS 11.9G d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/md127 /dev/md127 /dev/sda raid1 12G
|-/dev/md127p1 /dev/md127p1 /dev/md127 part 10M
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS 11.9G d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs 11.9G /mnt/local 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdb /dev/sdb ata disk linux_raid_member 12G 8d05eb84-2de8-31d1-dfed-54b2ad592118
|-/dev/sdb1 /dev/sdb1 /dev/sdb part linux_raid_member 10M 8d05eb84-2de8-31d1-dfed-54b2ad592118
|-/dev/sdb2 /dev/sdb2 /dev/sdb part crypto_LUKS 11.9G d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/md127 /dev/md127 /dev/sdb raid1 12G
|-/dev/md127p1 /dev/md127p1 /dev/md127 part 10M
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS 11.9G d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs 11.9G /mnt/local 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdc /dev/sdc ata disk 1G
`-/dev/sdc1 /dev/sdc1 /dev/sdc part swap 1023M 9c606f48-92cd-4f98-be22-0f8a75358bed
This looks different compared to what is shown for the original system.
But after reboot on the replacement hardware
I get this disk layout shown in the recreated system
# lsblk -ipo NAME,KNAME,PKNAME,TYPE,FSTYPE,MOUNTPOINT,UUID
NAME KNAME PKNAME TYPE FSTYPE MOUNTPOINT UUID
/dev/sda /dev/sda disk linux_raid_member 8d05eb84-2de8-31d1-dfed-54b2ad592118
`-/dev/md127 /dev/md127 /dev/sda raid1
|-/dev/md127p1 /dev/md127p1 /dev/md127 part
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs / 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdb /dev/sdb disk linux_raid_member 8d05eb84-2de8-31d1-dfed-54b2ad592118
`-/dev/md127 /dev/md127 /dev/sdb raid1
|-/dev/md127p1 /dev/md127p1 /dev/md127 part
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs / 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdc /dev/sdc disk
`-/dev/sdc1 /dev/sdc1 /dev/sdc part swap [SWAP] 9c606f48-92cd-4f98-be22-0f8a75358bed
This is exactly the same as the one of the original system
so it seems the system was actually correctly recreated
but still things smell fishy in the recovery system.
jsmeix commented at 2021-11-16 15:26:¶
Same GRUB install failure with current ReaR master code
i.e. without the changes in
https://github.com/rear/rear/pull/2702
and without the changes in this pull request here:
Installing GRUB2 boot loader...
Determining where to install GRUB2 (no GRUB2_INSTALL_DEVICES specified)
Found possible boot disk /dev/sda
/dev/sdb - installing GRUB2 there
Failed to install GRUB2 on possible boot disk /dev/sda
/dev/sdb
Found possible boot disk /dev/sda
/dev/sdb - installing GRUB2 there
Failed to install GRUB2 on possible boot disk /dev/sda
/dev/sdb
Found possible boot disk /dev/sda
/dev/sdb - installing GRUB2 there
Failed to install GRUB2 on possible boot disk /dev/sda
/dev/sdb
Failed to install GRUB2 - you may have to manually install it
WARNING:
For this system
SUSE_LINUX/15.3 on Linux-i386 (based on SUSE/15/i386)
there is no code to install a boot loader on the recovered system
...
Also same different looking 'lsblk' output in the recovery system
after "rear recover":
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT,UUID
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT UUID
/dev/sda /dev/sda ata disk linux_raid_member 12G 8d05eb84-2de8-31d1-dfed-54b2ad592118
|-/dev/sda1 /dev/sda1 /dev/sda part linux_raid_member 10M 8d05eb84-2de8-31d1-dfed-54b2ad592118
|-/dev/sda2 /dev/sda2 /dev/sda part crypto_LUKS 11.9G d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/md127 /dev/md127 /dev/sda raid1 12G
|-/dev/md127p1 /dev/md127p1 /dev/md127 part 10M
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS 11.9G d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs 11.9G /mnt/local 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdb /dev/sdb ata disk linux_raid_member 12G 8d05eb84-2de8-31d1-dfed-54b2ad592118
`-/dev/md127 /dev/md127 /dev/sdb raid1 12G
|-/dev/md127p1 /dev/md127p1 /dev/md127 part 10M
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS 11.9G d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs 11.9G /mnt/local 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdc /dev/sdc ata disk 1G
`-/dev/sdc1 /dev/sdc1 /dev/sdc part swap 1023M 9c606f48-92cd-4f98-be22-0f8a75358bed
I guess this is how it was all the time and I never before had a look
what 'lsblk' shows after "rear recover" in the recovery system
in case of a recreated RAID1 array.
As in
https://github.com/rear/rear/pull/2714#issuecomment-970279152
GRUB2_INSTALL_DEVICES="/dev/sda /dev/sdb"
and "rear -D finalizeonly" makes things work
Running mkinitrd...
Recreated initrd (/sbin/mkinitrd).
Installing GRUB2 boot loader...
Installing GRUB2 on /dev/sda (specified in GRUB2_INSTALL_DEVICES)
Installing GRUB2 on /dev/sdb (specified in GRUB2_INSTALL_DEVICES)
and the rebooted recreated system shows
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT,UUID
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT UUID
/dev/sda /dev/sda ata disk linux_raid_member 12G 8d05eb84-2de8-31d1-dfed-54b2ad592118
`-/dev/md127 /dev/md127 /dev/sda raid1 12G
|-/dev/md127p1 /dev/md127p1 /dev/md127 part 10M
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS 11.9G d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs 11.9G / 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdb /dev/sdb ata disk linux_raid_member 12G 8d05eb84-2de8-31d1-dfed-54b2ad592118
`-/dev/md127 /dev/md127 /dev/sdb raid1 12G
|-/dev/md127p1 /dev/md127p1 /dev/md127 part 10M
`-/dev/md127p2 /dev/md127p2 /dev/md127 part crypto_LUKS 11.9G d0446c00-9e79-4872-abaa-2d464fd71c99
`-/dev/mapper/cr_root /dev/dm-0 /dev/md127p2 crypt btrfs 11.9G / 85406026-0559-4b0d-8f67-ec19d3b556f5
/dev/sdc /dev/sdc ata disk 1G
`-/dev/sdc1 /dev/sdc1 /dev/sdc part swap 1023M [SWAP] 9c606f48-92cd-4f98-be22-0f8a75358bed
So the changes in
https://github.com/rear/rear/pull/2702
plus the changes in this pull request here
do not make things worse compared to current ReaR master code
at least for me with my simple RAID1 array.
jsmeix commented at 2021-11-18 14:36:¶
With the completely overhauled
layout/save/GNU/Linux/210_raid_layout.sh
in
https://github.com/rear/rear/pull/2714/commits/dc20466f3185aed08b71174e75a43c81cfae5587
I get the same "rear mkbackup" / "rear recover" behaviour as above for
my simple RAID1 array
so (hopefully) I did not break something.
The orderinmg of the mdadm options in disklayout.conf changed.
Before it was on my test system
raid /dev/md127 metadata=1.0 level=raid1 raid-devices=2 uuid=8d05eb84:2de831d1:dfed54b2:ad592118 name=raid1sdab devices=/dev/sda,/dev/sdb
and now it is
raid /dev/md127 level=raid1 raid-devices=2 devices=/dev/sda,/dev/sdb name=raid1sdab metadata=1.0 uuid=8d05eb84:2de831d1:dfed54b2:ad592118
jsmeix commented at 2021-11-18 14:39:¶
Now layout/save/GNU/Linux/210_raid_layout.sh looks OK to me
certainly not perfect - some things are missing - but OK for now.
Tomorrow I will work on layout/prepare/GNU/Linux/120_include_raid_code.sh
I use that RAID code cleanup as preparation to get familiar with RAID
which I need to solve
https://github.com/rear/rear/issues/2696
jsmeix commented at 2021-11-19 10:18:¶
Regarding mdadm version on older Linux distributions
and what mdadm options are supported:
SLES10 SP4 provides mdadm - v2.6 in the mdadm-2.6-0.25.13 RPM
where "man mdadm" shows in particular
CREATE MODE
Usage:
mdadm --create md-device --chunk=X --level=Y --raid-devices=Z devices
...
A new array will normally get a randomly assigned 128bit UUID
which is very likely to be unique. If you have a specific need, you
can choose a UUID for the array by giving the --uuid= option.
so since SLE10 mdadm supports --uuid and --raid-devices
jsmeix commented at 2021-11-19 11:43:¶
@pcahyna
thank you for reviewing my code changes!
jsmeix commented at 2021-11-19 13:25:¶
With the recent canges in
https://github.com/rear/rear/pull/2714/commits/e980b65154c67b82bb69b1ca874fbbb01e102dc1
i.e. now using "COMMAND | while read ... do ... done"
instead of "while read ... do ... done < <( COMMAND )"
I get same disklayout.conf as before
so it seems - at least in my case - that extract_partitions()
does not set variables that are meant to be used outside
of the "while read ... do ... done" process of the pipe.
Also "rear recover" works as before.
I use now GRUB2_INSTALL_DEVICES="/dev/sda /dev/sdb"
in etc/rear/local.conf and then GRUB2 install just works:
Running mkinitrd...
Recreated initrd (/sbin/mkinitrd).
Installing GRUB2 boot loader...
Installing GRUB2 on /dev/sda (specified in GRUB2_INSTALL_DEVICES)
Installing GRUB2 on /dev/sdb (specified in GRUB2_INSTALL_DEVICES)
pcahyna commented at 2021-11-19 13:49:¶
so it seems - at least in my case - that extract_partitions() does not set variables that are meant to be used outside of the "while read ... do ... done" process of the pipe.
Indeed, I checked and variables set inside extract_partitions() are
all lowercase and virtually all declared with declare (I saw only one
exception - uuid - which seems to be just an oversight).
jsmeix commented at 2021-11-19 14:43:¶
@pcahyna and all @rear/contributors
I wish you a relaxed and recovering weekend!
jsmeix commented at 2021-11-24 14:22:¶
My last commit here
https://github.com/rear/rear/pull/2714/commits/8472f4bc9a7034ac237ff48cdaa44f4abd0b3cfb
should mitigate what is described in
https://github.com/rear/rear/pull/2702#issuecomment-970395567
by at least informing the user (via LogPrintError), cf.
https://github.com/rear/rear/pull/2702#issuecomment-971331028
jsmeix commented at 2021-11-25 14:28:¶
For the reason behind the recent commits see
https://github.com/rear/rear/issues/2715#issuecomment-979259881
jsmeix commented at 2021-11-25 15:01:¶
Now things look OK from my point of view.
Not all is perfect but it should now be OK to merge it
and do further adaptions and enhancements based on it.
@pcahyna @rear/contributors
please have a look - perhaps you find obvious mistakes.
If there are no objections I would like to merge it on Monday afternoon.
jsmeix commented at 2021-11-26 10:58:¶
I tested with a hardcoded hack in
layout/prepare/GNU/Linux/120_include_raid_code.sh
so that it recreates the RAID1 array with a different UUID than what is
in disklayout.conf
# rear recover
...
Start system layout restoration.
Disk '/dev/sdc': creating 'gpt' partition table
Disk '/dev/sdc': creating partition number 1 with name ''sdc1''
Creating software RAID /dev/md127
Disk '/dev/md127': creating 'gpt' partition table
Disk '/dev/md127': creating partition number 1 with name ''md127p1''
Disk '/dev/md127': creating partition number 2 with name ''md127p2''
Creating swap on /dev/sdc1
Creating LUKS volume cr_root on /dev/md127p2
Set the password for LUKS volume cr_root (for 'cryptsetup luksFormat' on /dev/md127p2):
Enter passphrase for /dev/md127p2:
Enter the password for LUKS volume cr_root (for 'cryptsetup luksOpen' on /dev/md127p2):
Enter passphrase for /dev/md127p2:
Creating filesystem of type btrfs with mount point / on /dev/mapper/cr_root.
Mounting filesystem /
Disk layout created.
RAID device /dev/sda (/dev/sda) recreated with UUID 8d05eb84-2de8-31d1-dfed-54b2ad592119 that is not in /var/lib/rear/layout/disklayout.conf
RAID device /dev/sdb (/dev/sdb) recreated with UUID 8d05eb84-2de8-31d1-dfed-54b2ad592119 that is not in /var/lib/rear/layout/disklayout.conf
I used a UUID where the last digit is different comapred to what is in disklayout.conf
# grep '^raid ' /var/lib/rear/layout/disklayout.conf
raid /dev/md127 level=raid1 raid-devices=2 devices=/dev/sda,/dev/sdb name=raid1sdab metadata=1.0 uuid=8d05eb84:2de831d1:dfed54b2:ad592118
jsmeix commented at 2021-11-26 11:29:¶
I tested with a hardcoded hack in
layout/prepare/GNU/Linux/120_include_raid_code.sh
so that it recreates the RAID1 array without a --uuid option:
# rear recover
...
Start system layout restoration.
Disk '/dev/sdc': creating 'gpt' partition table
Disk '/dev/sdc': creating partition number 1 with name ''sdc1''
Creating software RAID /dev/md127
Disk '/dev/md127': creating 'gpt' partition table
Disk '/dev/md127': creating partition number 1 with name ''md127p1''
Disk '/dev/md127': creating partition number 2 with name ''md127p2''
Creating swap on /dev/sdc1
Creating LUKS volume cr_root on /dev/md127p2
Set the password for LUKS volume cr_root (for 'cryptsetup luksFormat' on /dev/md127p2):
Enter passphrase for /dev/md127p2:
Enter the password for LUKS volume cr_root (for 'cryptsetup luksOpen' on /dev/md127p2):
Enter passphrase for /dev/md127p2:
Creating filesystem of type btrfs with mount point / on /dev/mapper/cr_root.
Mounting filesystem /
Disk layout created.
RAID device /dev/sda (/dev/sda) recreated with UUID 46e4126b-0801-d8bd-8ef3-edb3a24da7d6 that is not in /var/lib/rear/layout/disklayout.conf
RAID device /dev/sdb (/dev/sdb) recreated with UUID 46e4126b-0801-d8bd-8ef3-edb3a24da7d6 that is not in /var/lib/rear/layout/disklayout.conf
i.e. without --uuid option the RAID array gets created with a random
UUID
at least on SLES15
# man mdadm
...
CREATE MODE
...
A new array will normally get a randomly assigned 128bit UUID
which is very likely to be unique. If you have a specific need,
you can choose a UUID for the array by giving the --uuid= option.
jsmeix commented at 2021-11-26 12:01:¶
I think we need further enhanced disk write-protection
cf.
https://github.com/rear/rear/pull/2703
for the disks in DISKS_TO_BE_WIPED
cf. how that currently works
https://github.com/rear/rear/pull/2714/commits/0cb21299efea81900285a8f224e0a0c6a20160e5
The further enhanced disk write-protection for the disks in
DISKS_TO_BE_WIPED
will not be included in this pull request because it does not belong
directly to RAID.
jsmeix commented at 2021-11-26 13:46:¶
On SLES10-SP4 with mdadm version 4.1
"man mdadm" reads (excerpt)
CREATE MODE
...
A new array will normally get a randomly assigned 128bit UUID
which is very likely to be unique. If you have a specific need,
you can choose a UUID for the array by giving the --uuid= option.
so I think the FEATURE_MDADM_UUID code in
layout/prepare/GNU/Linux/120_include_raid_code.sh
is meanwhile obsolete because all mdadm versions
that are in use for supported ReaR Linux distributions
support --uuid - see also my above
https://github.com/rear/rear/pull/2714#issuecomment-973938852
jsmeix commented at 2021-11-29 13:45:¶
With latest commits and this 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=( /boot/grub2/x86_64-efi /home /boot/grub2/i386-pc /root /srv /opt /tmp /usr/local /var )
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"
FIRMWARE_FILES=( 'no' )
MODULES=( 'loaded_modules' )
PROGRESS_MODE="plain"
PROGRESS_WAIT_SECONDS="3"
DISKS_TO_BE_WIPED=''
LUKS_CRYPTSETUP_OPTIONS+=" --force-password"
GRUB2_INSTALL_DEVICES="/dev/sda /dev/sdb"
DISKS_TO_BE_WIPED="/dev/sd[a-z]"
I get on the same VMs as above (excerpts):
# rear -D recover
...
Comparing disks
Ambiguous disk layout needs manual configuration (more than one disk with same size used in '/var/lib/rear/layout/disklayout.conf')
Switching to manual disk layout configuration
Using /dev/sda (same name and same size 12884901888) for recreating /dev/sda
Using /dev/sdb (same name and same size 12884901888) for recreating /dev/sdb
Using /dev/sdc (same name and same size 1073741824) for recreating /dev/sdc
Current disk mapping table (source => target):
/dev/sda => /dev/sda
/dev/sdb => /dev/sdb
/dev/sdc => /dev/sdc
UserInput -I LAYOUT_MIGRATION_CONFIRM_MAPPINGS needed in /usr/share/rear/layout/prepare/default/300_map_disks.sh line 315
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)
2
...
Wiping child devices of /dev/sda in reverse ordering: /dev/sda2 /dev/sda1 /dev/sda
Wiped first 16777216 bytes of /dev/sda2
Wiped last 16777216 bytes of /dev/sda2
Wiped first 10485760 bytes of /dev/sda1
Skip wiping at the end of /dev/sda1 (dvice size 10485760 not greater than the bytes that were wiped)
Wiped first 16777216 bytes of /dev/sda
Wiped last 16777216 bytes of /dev/sda
Wiping child devices of /dev/sdb in reverse ordering: /dev/sdb2 /dev/sdb1 /dev/sdb
Wiped first 16777216 bytes of /dev/sdb2
Wiped last 16777216 bytes of /dev/sdb2
Wiped first 10485760 bytes of /dev/sdb1
Skip wiping at the end of /dev/sdb1 (dvice size 10485760 not greater than the bytes that were wiped)
Wiped first 16777216 bytes of /dev/sdb
Wiped last 16777216 bytes of /dev/sdb
Wiping child devices of /dev/sdc in reverse ordering: /dev/sdc1 /dev/sdc
Wiped first 16777216 bytes of /dev/sdc1
Wiped last 16777216 bytes of /dev/sdc1
Wiped first 16777216 bytes of /dev/sdc
Wiped last 16777216 bytes of /dev/sdc
Start system layout restoration.
Disk '/dev/sdc': creating 'gpt' partition table
Disk '/dev/sdc': creating partition number 1 with name ''sdc1''
Creating software RAID /dev/md127
Disk '/dev/md127': creating 'gpt' partition table
Disk '/dev/md127': creating partition number 1 with name ''md127p1''
Disk '/dev/md127': creating partition number 2 with name ''md127p2''
Creating swap on /dev/sdc1
Creating LUKS volume cr_root on /dev/md127p2
Set the password for LUKS volume cr_root (for 'cryptsetup luksFormat' on /dev/md127p2):
Enter passphrase for /dev/md127p2:
Enter the password for LUKS volume cr_root (for 'cryptsetup luksOpen' on /dev/md127p2):
Enter passphrase for /dev/md127p2:
Creating filesystem of type btrfs with mount point / on /dev/mapper/cr_root.
Mounting filesystem /
Disk layout created.
...
Backup restore program 'tar' started in subshell (PID=5454)
Restored 23 MiB [avg. 7973 KiB/sec]
...
Restored 3772 MiB [avg. 16370 KiB/sec]
OK
Restored 3772 MiB in 245 seconds [avg. 15768 KiB/sec]
...
Running mkinitrd...
Recreated initrd (/sbin/mkinitrd).
Installing GRUB2 boot loader...
Installing GRUB2 on /dev/sda (specified in GRUB2_INSTALL_DEVICES)
Installing GRUB2 on /dev/sdb (specified in GRUB2_INSTALL_DEVICES)
The recreated system boots well and sems to work well.
[Export of Github issue for rear/rear.]