-
-
Notifications
You must be signed in to change notification settings - Fork 48
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
Backup: Restoring a qube with large root and private volumes fails due to scrypt error #4683
Comments
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
|
Automated announcement from builder-github The package
Or update dom0 via Qubes Manager. |
Automated announcement from builder-github The package
|
Qubes OS version:
R4.0
Affected component(s):
qubes-backup-restore
Steps to reproduce the behavior:
Create a Standalone qube
Expand private volume to 100 GiB and root volume to 50 GiB
Fill both volumes to ~80% capacity
Create a backup without compression including this qube and ~10 other much smaller qubes such that this large qube is ~80% of the backup size
Freshly install Qubes on the same machine used to create the backup
Try to restore the large qube by itself after updating dom0 and restoring the other qubes
Expected behavior:
qube is restored successfully, with some delay due to the size of the qube.
Actual behavior:
The private volume seemed to restore to the correct size, but the restore tool finished returning errors from tar and scrypt. Specifically, on a particular chunk of the root.img, tar failed because scrypt failed to decrypt the chunk, reporting that "Decrypting the file would take too much CPU time."
General notes:
I fixed this by modifying line 235 of qubesadmin/backup/restore.py to
command_line = ['scrypt', action, '-f', input_name, output_name]
According to the scrypt manpage the -f flag disables the CPU time and memory usage estimate checking before decryption, which worked - I'm writing this from the restored qube. This machine has a i5-6300U and 16GB of RAM - which does not seem like an exceptionally slow platform for running Qubes.
The next largest qube I was restoring has a 20 GiB root volume that is at >85% capacity but restored without issue. The total backup size was ~160 GiB.
Related issues:
Possibly #3468
The text was updated successfully, but these errors were encountered: