Restoring 4.0 qubes fails on 4.1

User Support 4.1
#1

I recently upgraded my system from 4.0 to 4.1. But some things didn’t work since I’d tried some oddball things (local pihole instance for all DNS, local squid proxy, local vpn, etc) on 4.0.

So I decided to start on a fresh 4.1 install and restore the backed up qubes from 4.0. But every attempt at restoration is failing with errors about “gzip: stdin: unexpected end of file …Passphrase is incorrect\n”. I thought the error was correct and I typed the (very simple) password wrong, but when I installed 4.0, all qubes restore without issue. Same password. So I tried a new backup with the word “password” as the password. Still fails to restore on 4.1. Saw the thread about restoring via CLI, and tried that with the --ignore-size-limit flag set. Still fails with a password error.

Is there a way to perform a backup on 4.0 without a password? Maybe via CLI? If so, I might try that next.(Hope to know before doing another wipe/reinstall)

Is there something wrong with the restore feature on 4.1? It kinda seems like something is broken.

Thanks!

#2

Yes, there is.

From dom0 take a look at the qvm-backup command. It does not have a man page, but --help is your friend.

As this seems like a gzip error, maybe also try to disable compression.

This command will create an unencrypted backup without compression:

qvm-backup --no-compress --dest-vm $QUBE_WITH_STORAGE $STORAGE_MOUNTPOINT

$QUBE_WITH_STORAGE is your qube that has your desired storage target mounted on $STORAGE_MOUNTPOINT. For example: qvm-backup --no-compress --dest-vm personal /mnt/usbstick

Another thing you can try if that fails to restore is restoring it in --paranoid-mode (here is information on it) and see if that does the trick with the command qvm-backup-restore. I won’t give you a full command, as there are many options on what to restore and how to deal with name collisions and other stuff, so take a look at qvm-backup-restore --help

#3

Thanks!

I’ll give that a shot.

#4

No luck. Same error with an uncompressed backup.

What’s the trick to creating a non-encrypted backup? When using the CLI, there’s still a prompt for it, and the command fails if you just hit “enter” with no password. I feel like there must be a way to do it, because the restoration process seems to allow restoring non-encrypted backups.

#5

I actually never tried this. I saw the --encrypt option in the backups and just assumed it would be unencrypted if this is not set.

in the man page i read:

       --encrypt, -e
              Ignored, backup is always encrypted

Indeed it asks for a passphrase.

I really would like to have the option to not encrypt the backups too.

There is a boolean in the source to indicate that it is encrypted, but it is set to true per default and not checked at all.

You should be able to modify the backup routine to not use encryption if you really want to.

Other than that i would try to increase the verbosity of backup and restore processes.

Maybe what is causing your problems is related to one specific qube?

Have you tried to only backup one single qube and restore that?

If that works you could try binary search to locate the qube causing that problem, back up all others and manually extract information of the faulty one.

With binary search i mean:
Assuming you have qubes 1-10. Back up 1-5 and restore. if that works, the faulty one is in 6-10. back up 6-8 and restore. if that does not work your faulty qube is there. Always split the set of qubes you evaluate in half. With this you can identify the qube making problems manually as fast as possible.

#6

Got it!

I tried restoring one at a time to find the one(s) having trouble, and that narrowed it down to 4 out of 21. Then I tried adding the --ignore-size-limit flag again to the ones still throwing the password error, and was able to restore them as well.

Thanks for the help and guidance!!

For anyone else stumbling across this or having similar issues, I did the following;

  1. Rolled my system back to a fresh 4.0 install.
  2. Patched dom0 (sudo qubes-dom0-update) to get the latest tools.
  3. Restored my original 4.0-based backups (without issue).
  4. Started each one to make sure it worked (templates and appvms).
  5. Made an uncompressed backup.
  6. Installed 4.1, patched, then restored one at a time using the qvm-backup-restore command. For the 4 that threw the password error, I was able to restore them by adding the --ignore-size-limit flag. I also had --ignore-missing where applicable since some of the failing restores were templatevms.