Background
I should know better than to mess with drivers on my old Mac Pro -- the hardware is finicky at best. Out of curiosity, though, I decided the other day to switch to an Nvidia driver. Big mistake!--I soon found myself unable to get to the login screen, and attempts to even get into the command line weren't particularly fruitful (an issue, I suspect, with the boot disk being encrypted). I'm a strong advocate for disk encryption, but it can sometimes come back to bite you in the trasero. The Mac Pro is my at-home work computer, so I kind of needed to get it back in the running, ASAP. In most cases, I'd avoid at all costs a reinstall of the OS, but I also needed a quick turnaround on whatever the fix was. I remembered that I had been using Ubuntu's in-built backup feature (a.k.a Deja Dup) for the last few months; the fastest way forward was probably to do a fresh install and then restore my backup.
NOTE: there are some important caveats to Deja Dup, so if you're unfamiliar with it please be warned: you should understand how Deja Dup works before considering it as a fix-all. (I did not...)
I wiped my startup disk and setup a fresh install of Ubuntu 18.04. I logged into my new account and opened up Deja Dup--you can find it labeled in the App Grid as "Backups".
Restoring a Backup: Failed to Execute Child Process
One of the first steps in restoring a backup is telling Deja Dup where your backups are located. In my case, I had them all on a second internal hard drive. I located the backups folder and hit "next" in the Backups dialogue and got served the following: "Backup Failed to Execute Child Process". Now--it's important to note that this hard drive with all my backups was partitioned with my old installation of Ubuntu. You may recall a recent post in which I discussed the default permissions on disks partitioned with Ubuntu's Disks utility. Permissions often default to 700--meaning read/write & execute access for the disk OWNER and NO ONE ELSE.
The mistake: when I did a fresh install of Ubuntu, I created a username different than the one I had used when I created my backups-disk. In my earlier install, my user was named webwork; in this newer install my user was named terracoders. Since my hard disk with the backups was partitioned/owned by webwork, and since the disk has read/write & execute access for the owner only, Deja Dup wouldn't have access to the disk unless I ran it as sudo--hence, it seems, I get this error.
The fix, as with my previous disk permission adventures, was to simply update the owner and permissions on the disk. In this case, I decided on the following:
- To change ownership recursively: sudo chown -R username:username /path/to/disk
- To give recursive read/write/execute permissions to both owner and group: sudo chmod -R 770 /path/to/disk
Note that the /path/to/disk, once mounted, is usually: /media/user/diskname .
After updating permission on my backups disk, Deja Dup stopped serving this error.
Can We Restore Now? Not Quite Yet
As noted in the Deja Dup documentation, Deja Dup is basically just a wrapper for a command line tool called duplicity. Deja Dup will be kind enough to remind you of this if you don't have the command line tool installed:
There are a bunch of people posting to Ubuntu forums on how they get this message but when they try and install these they get some business about how the packages aren't available. DO YOURSELF A FAVOR: be sure to run sudo apt-get udpate before you go looking for duplicity and python-gi. There may actually be other reasons why the packages are unavailable. For me, though, all it took was running an update. After which, I had no problem installing the packages with apt:
NOTE: Any time you do a fresh install, running sudo apt-get update is probably one of the first things you should do either way!
Once you've got the tools installed, head back to backups and you should have no problems restoring. Just be aware that it may take several minutes for the restoration to complete. Don't panic!--those backup archives are likely pretty hefty!
In the Clear at Last?--Maybe...
A couple caveats at the very end. Recall, in my case, that I changed user names for my new install. This doesn't prevent Deja Dup from restoring your files. It does, however, mean that any of your configuration files (all that stuff which is largely hidden in your home folder--i.e., .config, .ssh, .git, .drush, .vscode), are going to reference paths which are no longer valid. Once you've reinstalled applications, you may find that you need to reconfigure them either way.
A quick example: VS Code knows that my project files were previously located at /home/webwork/Sites/sitename/docroot; Deja Dup restored these files, but since my user name has changed, restored them to /home/terracoders/Sites/sitename/docroot. Obviously, VS Code isn't going to look for them in the new location.
If you're going to use Deja Dup to recover after a re-install, you should probably make sure to use the same user-name as your previous install.