#1444 Issue closed: Not able to recover encypted OS¶
Labels: support / question, fixed / solved / done
metro1234 opened issue at 2017-08-13 17:12:¶
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): 1.17.2
- OS version (cat /etc/rear/os.conf or lsb_release -a):Redhat 7.2
- rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
OUTPUT=ISO
OUTPUT_URL=nfs://192.168.56.1/storage
BACKUP=NETFS
BACKUP_URL=nfs://192.168.56.1/storage
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp' '/var/crash')
NETFS_KEEP_OLD_BACKUP_COPY=
- Are you using legacy BIOS or UEFI boot?
BIOS - Brief description of the issue:
OS Is encrypted with luks.
I have tried to restore using below command
rear -v recover
Asked Passphrase of key (Encryption key) and entered correct password
and it failed for layout recreation
log file error:
cryptsetup luksFormat -q --cipher aeAn error occured s-xts-plain64 --hash sha1 --uuid efd9xxxxxxxxxx /dev/sda5/ Password quality check failed: The password fails the directory check -error loading dictionary an error occurred during layout recreation
- Work-around, if any: I did not found any work arround
metro1234 commented at 2017-08-20 12:53:¶
Hi Team,
Is it a bug or I am doing anything wrong configuration?.
Below are few more test results:
- Tried with latest 2.2.X version and not able to restore
- Tried only with one file system encrypt (/project) and not able to restore
gozora commented at 2017-08-20 16:22:¶
Hi @metro1234,
I doubt that this is your fault.
Just from plain looking at your error:
cryptsetup luksFormat -q --cipher aeAn error occured s-xts-plain64 --hash sha1 --uuid efd9xxxxxxxxxx /dev/sda5/
It looks that something went wrong during rear mkbackup.
It would be interesting to see following files
- /var/lib/rear/layout/disklayout.conf from your original system
- /var/log/rear/rear-<hostname>.log created during
rear -d -D recoversession
Can you please provide these two files?
Thanks
V.
metro1234 commented at 2017-08-22 05:56:¶
Hi Gozora,
/var/lib/rear/layout/disklayout.conf
# Disk /dev/sda
# Format: disk <devname> <size(bytes)> <partition label type>
disk /dev/sda 42949672960 msdos
# Partitions on /dev/sda
# Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
part /dev/sda 511705088 1048576 primary boot /dev/sda1
part /dev/sda 10001317888 512753664 primary none /dev/sda2
part /dev/sda 10001317888 10514071552 primary none /dev/sda3
part /dev/sda 1024 20515389440 extended none /dev/sda4
part /dev/sda 1999634432 20516438016 logical none /dev/sda5
# Filesystems (only ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs are supported).
# Format: fs <device> <mountpoint> <fstype> [uuid=<uuid>] [label=<label>] [<attributes>]
fs /dev/mapper/luks-3828ec1d-fe65-4ffe-a09c-dff15b0fb3d7 / xfs uuid=cacafb5f-b6a0-46f6-a126-a13f4d7aa9ab label=root options=rw,relatime,attr2,inode64,noquota
fs /dev/mapper/luks-a6fed55d-e3ae-4e45-8115-6dbfd343a70e /data1 xfs uuid=93ef016b-4423-4c60-8c55-f34e820fc445 label=data1 options=rw,relatime,attr2,inode64,noquota
fs /dev/sda1 /boot xfs uuid=b3dd4c45-848d-4e32-9f7e-3b8732e4d992 label= options=rw,relatime,attr2,inode64,noquota
# Swap partitions or swap files
# Format: swap <filename> uuid=<uuid> label=<label>
swap /dev/sda5 uuid=0d62fd69-3ea8-4533-acb4-413e0f17176f label=
crypt /dev/mapper/luks-a6fed55d-e3ae-4e45-8115-6dbfd343a70e /dev/sda3 cipher=aes mode=xts-plain64 hash=sha1 uuid=a6fed55d-e3ae-4e45-8115-6dbfd343a70e
crypt /dev/mapper/luks-3828ec1d-fe65-4ffe-a09c-dff15b0fb3d7 /dev/sda2 cipher=aes mode=xts-plain64 hash=sha1 uuid=3828ec1d-fe65-4ffe-a09c-dff15b0fb3d7
/var/log/rear/rear-
rear-reartest.zip
Thanks
gozora commented at 2017-08-22 06:19:¶
@metro1234,
At first glance I don't see anything wrong neither in disklayout.conf
nor in log file.
I'd need to install similar setup to yours and try to reproduce your
problem.
V.
gozora commented at 2017-08-22 13:24:¶
@metro1234
I just successfully finished ReaR (2.2) restore of Centos 7.3, with setup similar to yours:
# Disk /dev/sda
# Format: disk <devname> <size(bytes)> <partition label type>
disk /dev/sda 8589934592 msdos
# Partitions on /dev/sda
# Format: part <device> <partition size(bytes)> <partition start(bytes)> <partition type|name> <flags> /dev/<partition>
part /dev/sda 209715200 1048576 primary boot /dev/sda1
part /dev/sda 5368709120 210763776 primary none /dev/sda2
part /dev/sda 2936012800 5579472896 primary none /dev/sda3
part /dev/sda 1024 8515485696 extended none /dev/sda4
part /dev/sda 73400320 8516534272 logical none /dev/sda5
# Filesystems (only ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs are supported).
# Format: fs <device> <mountpoint> <fstype> [uuid=<uuid>] [label=<label>] [<attributes>]
fs /dev/mapper/Cdata1 /data1 xfs uuid=8e9e5841-9f8d-4de0-85fb-184143874484 label= options=rw,relatime,attr2,inode64,noquota
fs /dev/mapper/luks-0ef6a905-e6a2-4a3d-92ab-caa541f9306a / xfs uuid=9a819074-d24c-477d-804e-6e7edbae8305 label= options=rw,relatime,attr2,inode64,noquota
fs /dev/sda1 /boot ext3 uuid=c90282da-c159-45d9-85d4-6869e265f26d label= blocksize=1024 reserved_blocks=5% max_mounts=-1 check_interval=0d bytes_per_inode=4096 default_mount_options=user_xattr,acl options=rw,relatime,data=ordered
# Swap partitions or swap files
# Format: swap <filename> uuid=<uuid> label=<label>
swap /dev/sda5 uuid=5d0a9255-f0b8-408d-8a30-86fbaa2be704 label=
crypt /dev/mapper/Cdata1 /dev/sda3 cipher=aes mode=xts-plain64 hash=sha256 uuid=acd42bd9-53d0-41b5-8d31-f03d320d2b75
crypt /dev/mapper/luks-0ef6a905-e6a2-4a3d-92ab-caa541f9306a /dev/sda2 cipher=aes mode=xts-plain64 hash=sha256 uuid=0ef6a905-e6a2-4a3d-92ab-caa541f9306a
Your problem is rather simple to solve.
Prompt for password you see after launch of rear recover is not asking
you for password you've used prior rear recover, but for NEW password
that will be set on newly created partitions for encryption. (which just
give perfect sense, if you think about it ...)
So all you have to do is enter (and later re-enter) some STRONG password
that will be accepted by password quality check of cryptsetup ...
Once rear recover finishes, you will use this password to decrypt
restored partitions (a.k.a boot ;-) ).
V.
schlomo commented at 2017-08-22 14:09:¶
Thanks @gozora for trying out that setup.
What about error loading dictionary? Can it be that cryptsetup wants
to check the quality of the passphrase with the help of an external
tool?
Can it be that we need to improve the user guidance in ReaR so that it
will show the user a short help text before running cryptsetup?
Maybe we should also actively handle the case that cryptsetup fails
due to bad user input, maybe show the crypsetup error to the user and
give him a chance to try again?
gozora commented at 2017-08-22 15:58:¶
Hi @schlomo,
Thanks @gozora for trying out that setup.
No problem, I was curious about how ReaR works with LUKS ...
What about error loading dictionary? Can it be that cryptsetup wants to check the quality of the passphrase with the help of an external tool?
I have no idea where this is coming from ... Maybe missing cracklib ? I really can't tell unless I have more information ...
Can it be that we need to improve the user guidance in ReaR so that it will show the user a short help text before running cryptsetup?
Today it was first time in my life I've was configuring LUKS. I must say that neither configuring LUKS nor ReaR was "brain surgery or rocket science". So I'd conclude that if user have some basic understanding how LUKS works, he can handle such setups + basic troubleshooting.
Maybe we should also actively handle the case that cryptsetup fails due to bad user input, maybe show the crypsetup error to the user and give him a chance to try again?
You have this chance even now by running rear recover again ...
Like I already said, LUKS + ReaR works well enough for me. Only thing I
would add is recovery of keys that were used on original system.
Currently you have to enter NEW passphrase for every LUKS partition.
Problem with such approach is that original LUKS partition could have up
to 8 passphrases/keys for unlocking (various users can do unlock). This
creates some additional work for administrator after recovery like
configure additional passphrases/keys or setup automatic unlocking.
@metro1234 if you still have trouble with restore, maybe you could share with me your recovery ISO so I can see what is wrong.
V.
gozora commented at 2017-08-22 16:05:¶
Like I already said, LUKS + ReaR works well enough for me. Only thing I would add is recovery of keys that were used on original system.
Thinking of it, this is not such a good idea ... It would require to store original passphrases/keys somewhere very very safely, so NO Vladimir don't even think about it! :-)
schlomo commented at 2017-08-22 16:11:¶
IMHO crypto disks are, by design, not meant for automated disaster recovery as long as the crypto secrets are entered by a human on the source system. ReaR cannot automate more than is already automated in the source system.
That means that it could be automated if the entire crypto setup is automated on the source system, e.g. by retrieving the keys from a key server during booting (and yes, this is probably not a typical setup).
If you all agree that ReaR doesn't require any improvement for this use case then please close the issue.
jsmeix commented at 2017-08-23 10:57:¶
I think the issue is sufficiently answered so that I close it.
For the future we might use my new grandiose UserInput function
where the user can predefine user input values to get them
automatically input (for an unattended "rear recover")
to get the LUKS passwords from the user.
This way it is the user who can predefine his LUKS passwords
input values as he likes it before he runs "rear recover"
and no secret needs to be stored by ReaR.
For example the user can predefine his LUKS passwords
input values manually in the running ReaR recovery system
before he runs "rear recover" to achieve that the actual
"rear recover" runs unattended.
Alternatively - if the user really likes it - he could predefine
his LUKS passwords input values manually in /etc/rear/local.conf
and keep his /etc/rear/local.conf sufficiently secure as he needs
it in his particular use case.
metro1234 commented at 2017-08-24 10:44:¶
@gozora ,
For some reasons I have not able to recover. I have used different password no luck and used difficult password no luck. How do i share files. Do you have any link?
Thanks
gozora commented at 2017-08-24 10:56:¶
@metro1234
You can upload it to Dropbox and share (c(at)gozora.sk).
metro1234 commented at 2017-08-24 13:35:¶
Hi,
I have shared it. Could you please confirm you have received it.
gozora commented at 2017-08-24 14:32:¶
Got it.
# /usr/bin/sha256sum rox1.zip
770bb5464385502d1f6d01c0effb394dfd1944c1bea4e68d951b2fcffce46d52 rox1.zip
You can remove it if checksum matches ...
V,
gozora commented at 2017-08-24 14:50:¶
@metro1234
Just to clarify things a bit, wasn't your problem accidentally that once
you've entered passphrase rear recover just hanged?
V.
metro1234 commented at 2017-08-24 17:26:¶
Yes Exactly
metro1234 commented at 2017-08-25 14:00:¶
@gozora ,
Just curious. How did you encrypt the file system? Did you encrypt during installation or Did you encrypt after OS Installation. Could you Please share steps you performed during encryption. I will try same setup here. I have tried cent OS,RHEL 7.2 for both version It will hung after passphrases password enter.
gozora commented at 2017-08-25 14:27:¶
I've let installer to setup and encrypt / and once installation was
done, I've manually configured encryption for /data1, this however
does not matter.
You need to adapt your config to make things work.
- There looks to be some dependency (which I did not had time to investigate further) between cryptsetup and dmsetup.
- You will need to have existing /var/tmp in order to let ReaR do its post installation steps (this is currently discussed in #1455).
So your ReaR config should look something like:
...
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/media' '/var/tmp/*' '/var/crash')
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" /usr/sbin/dmsetup )
...
After you run rear mkbackup, you should be able to boot and restore
from your newly created ISO without any further problems.
V.
metro1234 commented at 2017-08-26 06:28:¶
@gozora
Great ! , I am able to restore it.
jsmeix commented at 2017-08-28 09:41:¶
@metro1234
can you post here what specific settings you need
in your /etc/rear/local.conf to make it work for you
on your Red Hat 7.2 system so that also other
Red Hat 7.2 users could benefit from it?
gozora commented at 2017-08-28 10:25:¶
Hello @jsmeix,
In this case it requires to have /var/tmp directory available at
restore time (addressed by your #1457), and dmsetup needs to be
available (addressed by mine #1458).
So with current ReaR 2.2, following needs to be added to _local.conf)
...
BACKUP_PROG_EXCLUDE=("${BACKUP_PROG_EXCLUDE[@]}" '/var/tmp/*')
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" /usr/sbin/dmsetup )
...
V.
[Export of Github issue for rear/rear.]