cryptswap1 (eCryptfs is used)¶

Labels: support / question, no-issue-activity

jefstath opened issue at 2019-02-10 14:03:¶

Relax-and-Recover (ReaR) Issue Template¶

Fill in the following items before submitting a new issue
(quick response is not guaranteed with free support):

ReaR version ("/usr/sbin/rear -V"):
Relax-and-Recover 2.4 / 2018-06-21
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"):

OS_VENDOR=Ubuntu
OS_VERSION=16.04

ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
/etc/rear/site.conf not present.
/etc/rear/local.conf

BACKUP=RSYNC
RSYNC_PROTOCOL_VERSION=30
# backup URL modified to hide actual backup server name
BACKUP_URL=rsync://svr3@svr4.domain.com::/svr3
BACKUP_RSYNC_OPTIONS=( "${BACKUP_RSYNC_OPTIONS[@]}" --password-file=/root/rsync-password )

Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR):
Dell Optiplex PC
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device):
x86 compatible
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot):
BIOS and GRUB 2.02
Storage (lokal disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe):
local disk (500 MB)
Description of the issue (ideally so that others can reproduce it):

create backup CD

boot from backup CD

# rear recover

recovery process starts as expected but stops with the following message:

````No code has been generated to recreate /dev/mapper/cryptswap1```

user home partitions are encrypted with ecryptfs

Workaround, if any:
Attachments, as applicable ("rear -D mkrescue/mkbackup/recover" debug log files):
rear-pbcl-svr3.log

jsmeix commented at 2019-02-12 12:07:¶

Regarding partitions are encrypted with ecryptfs:

I am not a Ubuntu user and I never used eCryptfs
so that I myself cannot help with eCryptfs specific issues.

In /usr/share/rear/layout/save/GNU/Linux/230_filesystem_layout.sh
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/layout/save/GNU/Linux/230_filesystem_layout.sh
there is

supported_filesystems="ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs"

and ecryptfs (ignore case) is nowhere mentioned in ReaR
which does not look promising that eCryptfs is supported by ReaR.

@jefstath
could you please post here the output of the command

lsblk -i -p -o NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT

on your original system because it provides a helpful overview
of the general disk layout on your original system.

For a more detailed analysis at least the

Attachments, as applicable
("rear -D mkrescue/mkbackup/recover" debug log files)

part is required.

See also the section "Debugging issues with Relax-and-Recover" at
https://en.opensuse.org/SDB:Disaster_Recovery

jefstath commented at 2019-02-13 11:48:¶

I've attached the debug file generated by rear -D recover to my original message.
The block device configuration is as follows:

$ lsblk -i -p -o NAME,KNAME,PKNAME,TRAN,TYPE,FSTYPE,SIZE,MOUNTPOINT
NAME                              KNAME     PKNAME    TRAN   TYPE  FSTYPE        SIZE MOUNTPOINT
/dev/sr0                          /dev/sr0            sata   rom   iso9660     191.9M
/dev/sda                          /dev/sda            sata   disk              465.8G
|-/dev/sda2                       /dev/sda2 /dev/sda         part                  1K
|-/dev/sda5                       /dev/sda5 /dev/sda         part  LVM2_member 465.3G
| |-/dev/mapper/ubuntu--vg-swap_1 /dev/dm-1 /dev/sda5        lvm   swap            2G
| | `-/dev/mapper/cryptswap1      /dev/dm-2 /dev/dm-1        crypt swap            2G [SWAP]
| `-/dev/mapper/ubuntu--vg-root   /dev/dm-0 /dev/sda5        lvm   ext4        463.3G /
`-/dev/sda1                       /dev/sda1 /dev/sda         part  ext2          487M /boot

Thanks for the documentation link. I will take a closer look.

github-actions commented at 2020-06-28 01:33:¶

Stale issue message

[Export of Github issue for rear/rear.]