-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to recover LUKS version 2 #2204
Comments
Can you please test if you have same behavior with ReaR 2.2 ? V. |
heh, this is even worse ... Never mind it was worth a try ;-). Could you provide debug log from session executed with your most recent ReaR (guess it was 2.4) V. |
Here is the log file from This time I noticed a couple of message about UserInput. I'm not sure what they mean:
|
@adatum Your command According change history of 160_include_luks_code.sh, @OliverO2 was the last one doing changes in this file so he might be the most suitable one to help you ... V. |
Thanks for noticing that @gozora If there's anything you'd like me to try, let me know. Since the system being backed up and recovered is just a test VM, I can try anything even if it's destructive. Where is a good place to ask questions about ReaR that aren't necessarily issues? Besides the two "additional notes" above, I have a few other questions about ReaR's behavior. |
Good evening @adatum, having been notified of this issue I took a short look. As @gozora noted correctly there is a missing
That code exists since its initial implementation on 2011, so its not something I was directly involved in. But maybe you could shed some light on it by running this command on the original system:
The output is expected to look similar to this, in particular the line starting with
|
Thank you for the quick reply @OliverO2. Here is the luksDump. The hash spec is
|
Yes, it seems like LUKS version 2 requires its own port within ReaR: The output format of Maybe you have the option of just staying with LUKS version 1 for now until version 2 is more established and someone would come up with a port for ReaR. |
Thanks for confirming. This complicates the situation. Of two systems I want to use with ReaR, one is using LUKS2. LUKS2 has been supported on Fedora since 29, and is the default since Fedora 30. LUKS allows converting between versions 1 and 2 under certain conditions:
Unfortunately that last point combined with Fedora's defaults prevents converting back to LUKS1. Here is the output from my conversion attempt on the VM with the luksDump from above:
|
@OliverO2 thanks for finding culprit! Since fixing this issue would require some additional work, I'm assigning "need sponsorship" label and changing title of this issue. If anyone wants to sponsor fix for this issue, please drop message to this thread to avoid double work. V. |
I think in general missing support for a newer and incompatible version |
In the meantime, a workaround is to convert LUKS2 to LUKS1, which is by no means guaranteed to succeed, as "it depends" on many factors such as what features of LUKS2 are being used. However this worked for me:
https://unix.stackexchange.com/questions/535077/convert-luks2-back-to-luks-version-1/535081#535081 |
Error out during "rear mkrescue/mkbackup" when LUKS version 2 is used. LUKS version 2 is not suppported, see #2204 When LUKS version 2 is used it fails at least to determine the hash value so we use an empty hash value as a simple test if gathering crypt information was successful and error out if not.
With #2381 The whole LUKS code needs to be overhauled to be more fail safe. In |
Error out during "rear mkrescue/mkbackup" when LUKS version 2 is used. LUKS version 2 is not suppported, see #2204 When LUKS version 2 is used it fails at least to determine the hash value so we use an empty hash value as a simple test if gathering crypt information was successful and error out if not.
Stale issue message |
Added "--type luks1" to the default LUKS_CRYPTSETUP_OPTIONS. Because LUKS2 is not supported by ReaR (cf. #2204) the option '--type luks1' is needed to enforce the LUKS1 header format because the default header format is LUKS1 with cryptsetup < 2.1.0 but LUKS2 with cryptsetup ≥ 2.1.0 (cf. #2432) to ensure LUKS1 gets recreated as LUKS1 also with with newer cryptsetup versions.
Reading through the numerous updates to the thread, it seems LUKS2 is not supported, but the issue has been closed? Is LUKS2 now supported? Thanks for any clarifications 👍 |
@mannp LUKS2 is not (yet) supported so far. Cold issues are getting automatically closed by GitHub Bot as it makes no sense if nothing happens (after 90 days) to keep them open. I f you feel it is so important you cannot live without it then sponsoring an issue is a valid option to keep it alive. Or, even better preparing a pull request or adding feedback to the issue which could be useful to get it fixed by someone. |
Thanks @gdha I assumed as much, but as it had been open for almost a year I wondered why the bot closed now....updated 12 days ago.... Anyway, I have not been using rear as all my machines are luks2, just using alternatives :) All the best. |
@mannp What alternatives have you found? One way is to convert LUKS2 to LUKS1 #2204 (comment) to be able to use ReaR. I find it unfortunate to close valid issues simply because they haven't been addressed in X days. |
Hi @adatum, not wanting to take anything away from ReaR, as I think it is a great idea I use timeshift [https://github.com/teejee2008/timeshift] which is not perhaps a direct comparison, but is does support LUKS2 and has bailed me out on one occasion. Using it with arch it takes care of snapshots in between pacman updates. That said I did subscribe to this thread as I would have liked another backup of my backup and I do use borg backup [https://github.com/borgbackup/borg] but only for user files, not bare metal restores. That's where ReaR would be an great fit being able to use borg. Hope that helps :) |
With the patch #2381, I get an error even if I exclude the device with LUKS2. In this way, if I have mounted an (even external) LUKS2 device, which I have no intention to backing up, the creation of the layout fails: |
@kalos |
#2204 (comment) |
Added initial LUKS2 support, see #2204 Added new parameter 'type' to 'crypt' keyword used in disklayout.conf. Using this parameter allows to recreate the same version of LUKS as on the original system. Added LUKS version detection, parsing depending on version and usage of 'type' parameter.
ReaR version ("/usr/sbin/rear -V"): 2.4 and 2.5
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): Fedora 30
ReaR configuration files ("cat /etc/rear/site.conf" and/or "cat /etc/rear/local.conf"):
Hardware (PC or PowerNV BareMetal or ARM) or virtual machine (KVM guest or PoverVM LPAR): Virtualbox VM
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
Storage (local disk or SSD) and/or SAN (FC or iSCSI or FCoE) and/or multipath (DM or NVMe): local SSD
Description of the issue (ideally so that others can reproduce it):
The disk layout recreation script fails after printing a message asking for the LUKS password, but never giving a chance to enter it. I tried rerunning it, but each time it skips to exactly the same point asking the options seen in the screenshot.
The text was updated successfully, but these errors were encountered: