#2491 Issue closed: LUKS2 error even if the device is excluded or not mounted¶
Labels: enhancement, bug, fixed / solved / done
kalos opened issue at 2020-09-15 09:08:¶
Relax-and-Recover (ReaR) Issue Template¶
-
ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.6 / Git -
OS version ("cat /etc/os-release" or "lsb_release -a" or "cat /etc/rear/os.conf"):
Distributor ID: Debian
Description: Debian GNU/Linux bullseye/sid
Release: testing
Codename: bullseye -
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
AUTOEXCLUDE_DISKS=y
EXCLUDE_RECREATE+=( "fs:/mnt/minij" "fs://mnt/tmp" "/dev/mapper/minij_crypt" "btrfssnapshotsubvol:all" )
OUTPUT=ISO
OUTPUT_URL=null
BACKUP=REQUESTRESTORE
-
Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
PC/laptop -
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86_64 -
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
UEFI and Grub2 -
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
Local NVMe + external usb disk (NOT for ReaR backup) -
Storage layout ("lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT" or "lsblk" as makeshift):
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT
/dev/sdb /dev/sdb usb disk 931,5G
`-/dev/sdb1 /dev/sdb1 /dev/sdb part crypto_LUKS 931,5G
`-/dev/mapper/minij_crypt /dev/dm-3 /dev/sdb1 crypt btrfs 931,5G /mnt/minij
/dev/nvme0n1 /dev/nvme0n1 nvme disk 476,9G
|-/dev/nvme0n1p1 /dev/nvme0n1p1 /dev/nvme0n1 nvme part vfat 512M /boot/efi
|-/dev/nvme0n1p2 /dev/nvme0n1p2 /dev/nvme0n1 nvme part ext2 244M /boot
`-/dev/nvme0n1p3 /dev/nvme0n1p3 /dev/nvme0n1 nvme part crypto_LUKS 476,2G
`-/dev/mapper/nvme0n1p3_crypt /dev/dm-0 /dev/nvme0n1p3 crypt LVM2_member 476,2G
|-/dev/mapper/jiji--vg-root /dev/dm-1 /dev/dm-0 lvm btrfs 460,4G /mnt/btrfs_pool
`-/dev/mapper/jiji--vg-swap_1 /dev/dm-2 /dev/dm-0 lvm swap 15,8G [SWAP]
- Description of the issue (ideally so that others can reproduce
it):
I cannot run "rear mkrescue" when an external LUKS2 hard drive is connected, even if the device has been excluded with EXCLUDE_RECREATE.
I think the problem is in the order of the LUKS2 check.
-
Workaround, if any:
I temporarily solved it by commenting this line:
https://github.com/rear/rear/blob/f8477cd7992990cfb1989a2193004bb2c842a618/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh#L48 -
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
I attach the output of 'rear mkrescue -d':
jsmeix commented at 2020-09-15 11:01:¶
@kalos
please attach a rear -D mkrescue full debug (i.e. -D not only -d)
log file
and your var/lib/rear/layout/disklayout.conf
and var/lib/rear/layout/disktodo.conf files
cf.
https://github.com/rear/rear/issues/2204#issuecomment-692547494
Additionally please provide the output of
findmnt -a -o TARGET,SOURCE
because I am puzzled that your lsblk output does not show something
mounted at /
but I usually expect to see in the lsblk output what the root
filesystem is.
E.g. see "SLES 12 SP 5 with default LUKS encrypted LVM and btrfs
structure"
and "SLES 15 SP 1 with default LVM and LUKS encryption and btrfs
structure" in
https://github.com/rear/rear/wiki/Test-Matrix-rear-2.6
because I use SUSE but not Debian or Ubuntu where I now see on that
page
in the Ubuntu examples that there lsblk also does not show something
mounted at /
so things look now as if Ubuntu and Debian could run even without a root
filesystem ;-)
@kalos
could you explain what is actually used as root filesystem in your
case?
Regardless that this does not strictly belong to this issue I need to
understand
how nowadays Ubuntu and Debian run because normally I rely on what
lsblk shows
but when that does not show something mounted at / I need to learn how
to find out
what is actually used as the root filesystem in those cases.
kalos commented at 2020-09-15 12:13:¶
Full log: rear-jiji.log
disklayout.conf: disklayout.txt
disktodo.conf is empty
findmnt -a -o TARGET,SOURCE:
TARGET SOURCE
/ /dev/mapper/jiji--vg-root[/@]
|-/sys sysfs
| |-/sys/kernel/security securityfs
| |-/sys/fs/cgroup tmpfs
| | |-/sys/fs/cgroup/unified cgroup2
| | |-/sys/fs/cgroup/systemd cgroup
| | |-/sys/fs/cgroup/net_cls,net_prio cgroup
| | |-/sys/fs/cgroup/perf_event cgroup
| | |-/sys/fs/cgroup/pids cgroup
| | |-/sys/fs/cgroup/blkio cgroup
| | |-/sys/fs/cgroup/cpu,cpuacct cgroup
| | |-/sys/fs/cgroup/devices cgroup
| | |-/sys/fs/cgroup/freezer cgroup
| | |-/sys/fs/cgroup/cpuset cgroup
| | |-/sys/fs/cgroup/memory cgroup
| | `-/sys/fs/cgroup/rdma cgroup
| |-/sys/fs/pstore pstore
| |-/sys/firmware/efi/efivars efivarfs
| |-/sys/fs/bpf none
| |-/sys/kernel/debug debugfs
| |-/sys/kernel/tracing tracefs
| `-/sys/fs/fuse/connections fusectl
|-/proc proc
| `-/proc/sys/fs/binfmt_misc systemd-1
| `-/proc/sys/fs/binfmt_misc binfmt_misc
|-/dev udev
| |-/dev/pts devpts
| |-/dev/shm tmpfs
| |-/dev/hugepages hugetlbfs
| `-/dev/mqueue mqueue
|-/run tmpfs
| |-/run/lock tmpfs
| `-/run/user/1000 tmpfs
| `-/run/user/1000/doc portal
|-/boot /dev/nvme0n1p2
| `-/boot/efi /dev/nvme0n1p1
|-/home /dev/mapper/jiji--vg-root[/@home]
| `-/home/kalos/misc /dev/mapper/jiji--vg-root[/@misc]
|-/mnt/btrfs_pool /dev/mapper/jiji--vg-root
|-/mnt/minij /dev/mapper/minij_crypt
`-/var/lib/docker/btrfs /dev/mapper/jiji--vg-root[/@/var/lib/docker/btrfs]
/etc/fstab:
## BOOT
# /boot was on /dev/nvme0n1p2 during installation
UUID=3c45571e-e287-4d8f-bbe2-7498ada021f5 /boot ext2 defaults 0 2
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=1195-349B /boot/efi vfat nofail,x-systemd.device-timeout=1,umask=0077 0 1
## BTRFS
# subvol: root
/dev/mapper/jiji--vg-root / btrfs defaults,noatime,ssd,compress=lzo,subvol=@ 0 0
# subvol: home
/dev/mapper/jiji--vg-root /home btrfs defaults,noatime,ssd,compress=lzo,subvol=@home 0 0
# subvol: misc
/dev/mapper/jiji--vg-root /home/kalos/misc btrfs defaults,noatime,ssd,compress=lzo,subvol=@misc 0 0
# subvol: btrfs pool ROOT
/dev/mapper/jiji--vg-root /mnt/btrfs_pool btrfs defaults,noatime,ssd,compress=lzo,subvolid=5 0 0
My rootfs is a btrfs subvolume '@'.
I mount subvolid 5 as a 'root' of btrfs pool
ls /mnt/btrfs_pool/
'@'/ '@backups'/ '@home'/ '@misc'/
jsmeix commented at 2020-09-15 13:07:¶
I am now experimenting with excluding LUKS things.
I found already
https://github.com/rear/rear/issues/2492
Sorting that out will take some time.
@kalos
for now keep your workaround.
You may alternatively change that line to
test "$hash" || LogPrintError "No hash value for LUKS device '$target_name' at '$source_device' (only LUKS version 1 is supported)"
which shows the message so you are informed but it does not error out.
By the way:
With your workaround does "rear recover" work on your replacement
hardware?
Cf. "No disaster recovery without testing and continuous validation"
at
https://en.opensuse.org/SDB:Disaster_Recovery
jsmeix commented at 2020-09-16 12:13:¶
I can reproduce it.
I created an additional LUKS2 test volume
as in
https://github.com/rear/rear/issues/2492
# parted -s /dev/sda unit B mkpart playground2 ext2 497151901696 498225643519
# parted -s /dev/sda unit MiB print
Model: ATA TOSHIBA MQ01ABF0 (scsi)
Disk /dev/sda: 476940MiB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: pmbr_boot
Number Start End Size File system Name Flags
1 1.00MiB 9.00MiB 8.00MiB bios_grub
2 9.00MiB 4105MiB 4096MiB swap
3 4105MiB 208905MiB 204800MiB legacy_boot
4 208905MiB 311305MiB 102400MiB ext4
5 311305MiB 464905MiB 153600MiB ext4
6 464905MiB 473097MiB 8192MiB ext2 other
7 473097MiB 474121MiB 1024MiB playground
8 474121MiB 475145MiB 1024MiB playground2
# cryptsetup luksFormat --type luks2 --force-password /dev/sda8
# cryptsetup luksOpen /dev/sda7 luks1test
# cryptsetup luksOpen /dev/sda8 luks2test
# mkfs.ext2 /dev/mapper/luks2test
# mkdir /luks1test
# mkdir /luks2test
# mount /dev/mapper/luks1test /luks1test
# mount /dev/mapper/luks2test /luks2test
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT
/dev/sda /dev/sda sata disk 465.8G
|-/dev/sda1 /dev/sda1 /dev/sda part 8M
|-/dev/sda2 /dev/sda2 /dev/sda part crypto_LUKS 4G
| `-/dev/mapper/cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 /dev/dm-0 /dev/sda2 crypt swap 4G [SWAP]
|-/dev/sda3 /dev/sda3 /dev/sda part crypto_LUKS 200G
| `-/dev/mapper/cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 /dev/dm-1 /dev/sda3 crypt ext4 200G /
|-/dev/sda4 /dev/sda4 /dev/sda part ext4 100G /nfs
|-/dev/sda5 /dev/sda5 /dev/sda part ext4 150G /var/lib/libvirt
|-/dev/sda6 /dev/sda6 /dev/sda part ext2 8G
|-/dev/sda7 /dev/sda7 /dev/sda part crypto_LUKS 1G
| `-/dev/mapper/luks1test /dev/dm-2 /dev/sda7 crypt ext2 1022M /luks1test
`-/dev/sda8 /dev/sda8 /dev/sda part crypto_LUKS 1G
`-/dev/mapper/luks2test /dev/dm-3 /dev/sda8 crypt ext2 1020M /luks2test
/dev/sr0 /dev/sr0 sata rom 1024M
# cryptsetup -v status luks1test
/dev/mapper/luks1test is active and is in use.
type: LUKS1
cipher: aes-xts-plain64
keysize: 256 bits
key location: dm-crypt
device: /dev/sda7
sector size: 512
offset: 4096 sectors
size: 2093056 sectors
mode: read/write
# cryptsetup -v status luks2test
/dev/mapper/luks2test is active and is in use.
type: LUKS2
cipher: aes-xts-plain64
keysize: 256 bits
key location: keyring
device: /dev/sda8
sector size: 512
offset: 8192 sectors
size: 2088960 sectors
mode: read/write
ReaR behaves really bad when there is a LUKS2 volume
because it errors out in any case with
ERROR: No hash value for LUKS device 'luks2test' at '/dev/sda8' (only LUKS version 1 is supported)
even when the filesystem in that LUKS2 volume is not mounted
i.e. after I had done umount /dev/mapper/luks2test
The reason is that
usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh
processes all what is listed by dmsetup ls --target crypt which is in
my case
# dmsetup ls --target crypt
cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 (254, 1)
luks1test (254, 2)
cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 (254, 0)
luks2test (254, 3)
To not let ReaR process luks2test I need to luksCloseit
# cryptsetup luksClose luks2test
# lsblk -ipo NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME KNAME PKNAME TRAN TYPE FSTYPE SIZE MOUNTPOINT
/dev/sda /dev/sda sata disk 465.8G
|-/dev/sda1 /dev/sda1 /dev/sda part 8M
|-/dev/sda2 /dev/sda2 /dev/sda part crypto_LUKS 4G
| `-/dev/mapper/cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 /dev/dm-0 /dev/sda2 crypt swap 4G [SWAP]
|-/dev/sda3 /dev/sda3 /dev/sda part crypto_LUKS 200G
| `-/dev/mapper/cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 /dev/dm-1 /dev/sda3 crypt ext4 200G /
|-/dev/sda4 /dev/sda4 /dev/sda part ext4 100G /nfs
|-/dev/sda5 /dev/sda5 /dev/sda part ext4 150G /var/lib/libvirt
|-/dev/sda6 /dev/sda6 /dev/sda part ext2 8G /other
|-/dev/sda7 /dev/sda7 /dev/sda part crypto_LUKS 1G
| `-/dev/mapper/luks1test /dev/dm-2 /dev/sda7 crypt ext2 1022M /luks1test
`-/dev/sda8 /dev/sda8 /dev/sda part crypto_LUKS 1G
/dev/sr0 /dev/sr0 sata rom 1024M
# dmsetup ls --target crypt
cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 (254, 1)
luks1test (254, 2)
cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 (254, 0)
then "rear mkrescue" succeeds.
jsmeix commented at 2020-09-16 13:58:¶
@kalos
could you test if the code changes in
https://github.com/rear/rear/pull/2493
make things work for your use case?
kalos commented at 2020-09-16 14:21:¶
[...]
By the way:
With your workaround does "rear recover" work on your replacement hardware?
Currently I test the recovery on VM, and I have some trouble with auto-shrink.
I plan to test it on suitable hardware in the next few days.
kalos commented at 2020-09-16 14:27:¶
@kalos
could you test if the code changes in
#2493
make things work for your use case?
it works perfectly.
I am attaching the log (partial and complete):
LOG.txt
rear-jiji.log
and disklayout:
disklayout.txt
Thank you very much!
jsmeix commented at 2020-09-17 11:08:¶
@kalos
I did some further general cleanup and improvements
of layout/save/GNU/Linux/260_crypt_layout.sh
so I would appreciate it if you could use the one from
https://raw.githubusercontent.com/rear/rear/5057f8bdc00196c08cd9ff33b0b4c2cc0c96cda5/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh
for your further tests.
Regarding your
https://github.com/rear/rear/issues/2491#issuecomment-693438874
Currently I test the recovery on VM, and I have some trouble with auto-shrink
see the section about the config variables
AUTORESIZE_PARTITIONS
AUTORESIZE_EXCLUDE_PARTITIONS
AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE
AUTOINCREASE_DISK_SIZE_THRESHOLD_PERCENTAGE
in usr/share/rear/conf/default.conf
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L399
In particular because you use LVM note therein
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L428
# In particular this does not resize volumes on top of the affected partitions.
# To migrate volumes on a disk where the disk size had changed the user must in advance
# manually adapt his disklayout.conf file before he runs "rear recover".
I.e. when partitions are resized which affects the size of LVM volumes
then the affected LVM volumes get not automatically resized so that
LVM setup during "rear recover" will fail unless you had manually
adapted your disklayout.conf.
In general have a look at the texts about MIGRATION_MODE in
default.conf like
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L356
kalos commented at 2020-09-17 14:18:¶
@kalos
I did some further general cleanup and improvements
of layout/save/GNU/Linux/260_crypt_layout.sh
so I would appreciate it if you could use the one from
https://raw.githubusercontent.com/rear/rear/5057f8bdc00196c08cd9ff33b0b4c2cc0c96cda5/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh
for your further tests.
It works like a charm.
Regarding your
#2491 (comment)
Currently I test the recovery on VM, and I have some trouble with auto-shrink
see the section about the config variablesAUTORESIZE_PARTITIONS AUTORESIZE_EXCLUDE_PARTITIONS AUTOSHRINK_DISK_SIZE_LIMIT_PERCENTAGE AUTOINCREASE_DISK_SIZE_THRESHOLD_PERCENTAGE
[...]
Thank you very much. You are really kind.
jsmeix commented at 2020-09-18 12:41:¶
With
https://github.com/rear/rear/pull/2493
merged
this issue should be fixed.
@kalos
you may have a look at the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
[Export of Github issue for rear/rear.]