Before you post please read how to get help
Installing Mint 18.2, 64bit, I'm trying to get full disk encryption with separate system, swap, and home partitions. The reason is that I want to keep my system partition small, so that my system clone backups won't take up a ton of storage space, or take forever to run. The data on the home partition could then be backed up simply as data; the partition itself wouldn't have to be saved. I realize that I could use TimeShift to do system backups, but quite frankly I do not fully trust anything but direct cloning for that purpose.
I've tried the tutorial found here: http://linuxbsdos.com/2014/01/16/manual ... x-mint-16/, which describes a way to do this using Ubiquity, the live disc installer.
I want to keep this short, but I think I have to give the procedure I actually used, as I understood from the tutorial:
1) At installation options, choose Something Else
2) Select main HD (in my case, /dev/sda) and click New Partition Table.
3) Make a boot partition: Select (click on) Free Space, click the + button, and choose Size = 500MB, Type = Primary, Use As = ext2, Mount Point = /boot. Click OK.
4) Make a root (system) partition: Select Free Space, click the + button, and choose Size = 12000MB, Type = Logical, Use As = physical volume for encryption, enter passphrase. Leave Mount Point unchosen. Click OK.
5) Make a swap partition: Select the Free Space, click the + button, and choose Size = 3000MB, Type = Logical, Use As = physical volume for encryption, enter passphrase. Mount Point is again not chosen. Click OK.
6) Make a home partition: Select the Free Space, click the + button, and choose Size = all remaining space, Type = Logical, Use As = physical volume for encryption, enter passphrase. Mount Point is not chosen. Click OK.
7) Assign mount points:
a) At top of partition table, select /dev/mapper/sda5_crypt. (There are two; choose the one underneath that shows the size as 12GB. This will be the system partition.) Double click, and choose Use As = ext4, Format, Mount Point = /. Click OK.
b) I am now back in the Partition Table. Select and double click /dev/mapper/sda6_crypt (the one that shows its size as 3GB. This will be the swap partition). Double click, and choose Use As = swap. Click OK.
c) Back in the Partition Table. Select and double click /dev/mapper/sda7_crypt (the one that shows its size as all remaining disk space. This will be the home partition). Double click, and choose Use As = ext4, Format, Mount Point = /home. Click OK.
Note: In creating all partitions, the Location chosen was always the default: Beginning Of This (Free) Space.
Lastly, clicked on Device For Bootloader Installation, and chose the 500MB partition that was already made as /boot (in my case was /dev/sda1).
Here is a screenshot of what things looked like before clicking the Install Now button:
The User Name, etc. dialogue came up, then the Time Zone selection dialogue, but soon after also this message: "Attempt to mount file system at /sda5_crypt failed". The options are given to Go Back, or Continue. Doing the latter results in the installation stalling soon after, while it is trying to set up /sda7_crypt (the home partition).
Repartitioning to a single partition using gparted, and redoing the whole install process, but choosing Go Back instead of Continue, brings me to the installation options menu, and choosing Something Else again gets me back into the Partition Table dialogue. However, the /dev/mapper/sda5_crypt (system and root) partition is not visible in the list any more (although it IS seen in the list of partitions shown when you click on the Device For Bootloader Installation). Further, all partitions can be selected, but none can be changed.
I again repartitioned to a single partition using gparted, and redid the whole install process. This time, when shown "Attempt to mount file system at /sda5_crypt failed", I opened a terminal and tried to manually mount it. I tried sudo mount /sda5, sudo mount /dev/sda5, sudo mount /dev/sda5_crypt, sudo mount /dev/mapper/sda5_crypt. All returned a message "can't find in /etc/fstab".
Does anybody have any ideas what I'm doing wrong?
We all have to educate ourselves as to the options, then choose according to personal circumstances and preferences.
I'm seeking out full, disk level encryption because I simply don't believe that home folder or other file/folder level encryption is good enough for my purposes. I believe the forensic tools to examine temporary, swap and other files so as to crack file/folder level encryption are available to and usable by a lot more people than just government intelligence employees.
I'm looking for separate system and home partitions to avoid the troubles mentioned. I do use Time Shift, but I have seen enough cases in this forum of people being unable to restore from Time Shift backups so that I don't think I should entirely rely on it. Nothing against Time Shift in particular. I've had problems with other similar programs. A full reinstall of a busted Mint system is certainly WAY easier than doing the same on a Windows system, but it will still take at least a week of work to do so. I WILL have system backups, and they will be as trustworthy as possible. I can't just clone an entire 750GB disk every time I need a system backup; don't have enough or big enough external drives. Plus a backup would take a couple of days to run.
All things considered, I am willing to take on a LOT of trouble to avoid these troubles.
Thanks for the tip on the boot partition. That is certainly a necessary thing to know!
The idea is:
1) Boot into Ubiquity installer (Live Mint disc).
2) Under install options, choose disk encryption with LVM.
3) This install makes root and swap partitions (and I assume a boot partition, although that isn't mentioned); there are no sub-options. Go ahead and complete standard install of encrypted LVM as such.
Now what follows is what I am unsure of. I understand that with LVM you can resize, add or remove partitions. So I'm thinking I can...
4) After the encrypted LVM install, boot into the system with my passphrase, then use gparted to resize the root (system) partition to 12GB.
5) Add a new partition using most of the available disk space.
6) Move the home folder from the root partition to this new partition.
It would seem then I have everything I want: Full disk encryption (that moreover requires entering a passphrase only once), a root partition that is small, and so can be quickly cloned for system backups, and won't take up much storage space, a separated home folder that can be separately backed up simply as data.
Assuming this works in principle, when I move the home folder, will the system and home "see" each other as normal?
- Level 18
- Posts: 8881
- Joined: Fri Oct 12, 2012 9:44 pm
- Location: Australian Antarctic Territory
@WharfRat was being diplomatic when he said 'This looks like more of a headache than it's worth'. I'm not known for being backward in coming forward so I'll state it plainly for you. If you can't figure out encryption on your own then you shouldn't be using it. You're headed for disaster otherwise, then you'll want help in recovering the unrecoverable when it all breaks merely because an errant cosmic particle flipped a single bit in RAM, or your neighbour's dilapidated old refrigerator turned on at the wrong time and sent a noisy electrical spike down the line at your machine.
Perhaps you might consider experimenting on an old, spare machine. Borrow one if necessary.
No offense whatsoever intended.
PS: There are alternatives for keeping your sekrit stuff from prying eyes. VeraCrypt, for example.
Actually, my previous post was inadvisable. I should have recalled that encrypted partitions cannot be resized in gparted -- at least by any method I presently know. I am sorry I have taken up your time by provoking an unnecessary response.
In any case, it is clear that I will, as you say, have to figure it out by myself. So, back to the research.
- Level 18
- Posts: 8881
- Joined: Fri Oct 12, 2012 9:44 pm
- Location: Australian Antarctic Territory
It's absolutely not necessary to apologise. You learned something so it was worth the question. That's why were here in the Mint forums and not in the Arch linux forums
I solved this to my own satisfaction (no LVM) to make private+persistent live-session USB sticks. Encrypted copies of system folders are mounted on-top-of a plain-text running system...
o Plain-text Mint boots normally. No swap and a single 16GB partition is easy.
o A line in the plain-text /etc/crypttab prompts for a passphrase and unlocks a large LUKS container...
private /dev/sda4 none luks
o A line in the plain-text /etc/fstab mounts the unlocked container...
/dev/mapper/private /root ext4 rw 0 2
o More lines in the plain-text /etc/fstab mount private versions of folders on-top-of the running system...
/root/swap swap swap rw 0 0
/root/usr /usr ext4 bind 0 0
/root/var /var ext4 bind 0 0
/root/home /home ext4 bind 0 0
It's not widely advertised that fstab can do bind mounts like that.
Valuable clues here too...
https://wiki.archlinux.org/index.php/Dm ... ire_system
Some day I will try the grub-can-unlock-the-whole-drive option... not tonight Josephine.
First, I tried a number of things to get Ubiquity to do what I wanted. Ubiquity's default partition types were given as: /boot = Primary, / = logical, swap = logical, /home = logical. Those were the ones I had used. I thought perhaps / was not being mounted for installation because it also had to be set as Primary. One internet voice claimed that on BIOS/MBR systems (like mine), this was necessary. That voice was contradicted by a couple of others, but I tried this anyway, and for the hell of it also tried numerous other combinations. No joy.
Second, it was said elsewhere: "If you do not setup an LVM for each of your partitions /usr /tmp and encrypt them, the installer will not realise the mount points have been set, and fail.” I didn't want separate partitions for /usr or /temp, but that gave me the idea to try something I found right here on the Mint forums: viewtopic.php?f=42&t=228836&p=1209652&h ... l#p1209652. This was authored by Mint Forums stalwart Laurent.
Of course, it was a routine meant for a much more complicated setup than I had in mind. I therefore abstracted from it a process tailored to my needs. It went as follows:
Three Major Steps
1) Prepare LUKS container and logical volumes
2) Install Mint using the live DVD/USB installer (Ubiquity)
3) Edit the encryption settings so that the machine will boot
Note: I am working on a new computer; complete fresh install.
1) Prepare LUKS container and logical volumes
- a) Boot install DVD/USB. Open Terminal ((menu bar at bottom of screen, or ctl+alt+t), then type <sudo gparted>
i) sda1: size 500MB, type ext2, label=boot.
ii) sda2: size 600GB, unformatted (clear). This will be a LUKS container for other logical partitions.
Note: After making these, go to the menu, click on Partition, then Information, and note the designation that is actually given by gparted to the device. If the partitions are not listed as sda1 and sda2, but something else, use the actual device designation given by gparted; i.e., in the following instructions, replace sda1 and sda2 with whatever gparted gives you.
iii) Leave the rest as free space. It will be available to other partitions to expand them in case of need.
Type <sudo cryptsetup luksFormat /dev/sda2>
You are asked to enter a passphrase twice. It's advisable to stick with the ASCII 7bit character set, as this is compatible with ASCII 8bit, UTF-8, and many other common sets, and will prevent the possibility of your computer “misunderstanding” your keyboard, and locking you out. Google ASCII 7bit for more info.
Now type <sudo cryptsetup luksOpen /dev/sda2 luks1>
<sudo pvcreate /dev/mapper/luks1>
<apt install system-config-lvm>
Note: The following is just a sketch of what was actually done. Laurent had posted a couple of images that showed what he did for his case, but these had expired, so I shot from the hip here and used LVM as common sense (if I have any) told me.
i) Create a volume group for your luks1 container. Call it vg1 (or whatever).
ii) Create logical volumes under this volume group:
Name: root, size=12GB, type=ext4, mount, mountpoint= /
Name: swap, size=3GB, type=none
Name: home, size=XXXGB, type=ext4, mount, mountpoint= /home
Left some space unallocated for possible future expansion.
i) Double click on sda1 and set it as: mount point=/boot, type=ext2, format=yes
ii) Double click on /dev/mapper/vg1-root and set it as: mount point=/, type=ext4, format=yes
iii) Double click on /dev/mapper/vg1-swap and set as swap area.
iv) Double click on /dev/mapper/vg1-home and set as: mount point=/home, type=ext4, format=yes.
Set Device For Bootloader as /dev/sda
(The install completed smoothly. Finally got some joy!)
3) Edit the encryption settings so that the machine will boot
<sudo mount -bind /dev /mnt/dev>
<sudo chroot /mnt mount -t proc proc /proc>
<sudo chroot /mnt mount -t sysfs sysfs /sys
<sudo chroot /mnt mount -t devpts devpts /dev/pts
NB: No adjustments were made here to Laurent's procedure (since I wouldn't have a clue what adjustments would be necessary, if any).
<gksu xed /mnt/etc/crypttab>
When the text file opens, type:
# <target name> <source device> <key file> <options>
luks1 /dev/sda2 none luks
Save the file.
NB: As I understand, it should not make any difference, but I used spaces between the elements of the first line, and tabs between those of the second.
<sudo chroot /mnt update-initramfs -u>
Laurent's tutorial says to ignore any warnings. I did receive one (or two), but did not write them down (wish now I had).
It took a minute or so for a new prompt to come up, indicating the process was finished.
I rebooted without the boot disc. Everything seemed to go well; the Mint leaf with the moving dots underneath appeared, as it usually does just prior to showing you the prompt to enter your decryption key, and...stayed there. No big deal. It usually takes some time for that prompt to show. Then the hard drive light began to pulse in regular fashion, and the comp emitted soft chirps likewise. Not good. That's computerese for "I'm *trying* to understand what you're telling me, but it's making no freaking sense!"
Sure enough, the screen went black, and this showed up:
Busybox v1.22.1 (Ubuntu 1:1.22.0-15) built-in shell (ash)
Enter 'help' for a list of built-in commands
I looked at the commands, saw nothing apparently useful, typed exit, which did not cause BusyBox to exit, then powered down by holding down the power button.
I did some research on this problem. I rebooted. As predicted by some, this time GRUB showed (though it had not before). I selected the Mint 18.3 op system (which was expectedly the only one available), and pressed Enter. The BusyBox screen came up again, I typed exit again. This time I got this message:
Gave up waiting for root device. Common problems:
- Boot args (cat /proc/cmdline)
- Check root delay= (did the system wait long enough?)
- Check root= (did the system wait for the right device?)
- Missing modules (cat /proc/modules: ls /dev)
Alert! /dev/mapper/vg1-root does not exist. Dropping to a shell!
Some internet sources suggest that a simple disk scan for errors would fix the problem. BusyBox does not list fsck among its tools, so...
Booted into the Live DVD again, ran <sudo lvmdiskscan>, returned:
0 LVM physical volume whole disks
0 LVM physical volumes
Then ran fsck on all file systems
<sudo fsck -AV> returned "checking all file systems", then immediately dropped to a new prompt. Oh well.
sudo fsck /dev/sda1 returned "clean"
sudo fsck /dev/sda2 returned nothing
sudo fsck /dev/sda returned
ext2fs_open2: Bad magic number in super-block
est2fs.ext2: Super-block invalid, trying backup blocks
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda
Then I rebooted into the hard drive.
To find all the drives and partitions which GRUB can look at to find an OS, at the GRUB menu, I typed 'c' to bring up a command prompt, and typed
(hd0) (hd0, msdos2) (hd0, msdos1)
Typing <ls (hd0)>, and so for the others, gives:
(hd0): size of 732,574,584KiB (750GB). Sector size = 512B. No start point given. This is obviously the hard drive itself (the size is the size of my entire HD). File system listed as unknown, but I would expect that since the drive itself wouldn't have one.
(hd0, msdos1): starts at 1024KB, size of 512MB. File system is ext*. Obviously it's the sda1 boot partition.
(hd0, msdos2): starts at 513MB, and a size of 614400000KiB (630GB). Obviously it's the sda2 partition. File system listed as unknown.
So GRUB is not seeing the encrypted logical volume group, nor of course the root partition on it. That makes perfect sense, since on boot I never get a chance to enter the decryption key.
My hypothesis is that the problem is not a bad magic number in the superblock, but a mistake I made in Part 3 (since I made no adjustments to Laurent's formula), or maybe Part 1.
There are certainly people here that would know something about this -- especially Laurent himself, or Mute Ant. It seems stupid to keep digging away with a shovel if somebody has a backhoe.
Oh, BTW, Mute Ant,
"sudo mount /dev/mapper/sda5_crypt" -----> "can't find in /etc/fstab" possibly because you are not telling it where to mount it."
Well, slap my forehead. Not being privy to Linux architecture, I had no clue. I don't often mount partitions through the command line. Would the command then be <sudo mount /dev/mapper/sda5_crypt /mnt/> ?
Even if I get the current installation fixed, I might well try that in the straight Ubiquity installer. If it works, it would be simpler, to say the least, and would be good for me and others to know. If not, I can always redo things the long way.
I'm thinking a tutorial on this is eventually going to be in order.
I've seen that archlinux page you linked to. Could be useful if no one spots what I've done wrong using the Laurent method.
I hope this was a typo: the boot partition is /dev/sda1 not /dev/sda. Since you got a grub menu later, I'm guessing it was just a typo on the forum... but you should verify the contents.
boot the install media again, mount the boot partition and make sure it's not empty:
Code: Select all
sudo mount /dev/sda1 /mnt ls -l /mnt
If it's not empty, you may be able to edit /mnt/grub/grub.cfg to a bootable state... possibly. Maybe post back the contents of that file and see if there's anything to do there ...
Thanks for the observation.
That was not a typo. I had it like that because Laurent's tutorial says that, for his case "the first 4 partitions sda1 to sda4 are allocated to EFI and Windows". For mine, I'll have nothing but Mint 18.3.
In his case, at 3)b he had: sudo mount /dev/sda5 /mnt/boot
I figured that sda5 was equivalent to my sda. Also, it had been mentioned by Wharf Rat that when I had earlier tried to do this entirely through Ubiquity, I should put Set Device For Bootloader as /dev/sda, not sda1, so I carried that idea over to Laurent's method.
Come to think of it, it could be wrong, b/c sda is simply the hard drive as a whole, and is not even a partition in itself, right?
So I see how that could be a problem. But if it is, I also don't see why it would not be a problem doing the same in Ubiquity.
At any rate, I did the check you showed me. Here is the result:
Seems that bootup is definitely seeing the sda1 boot partition.
Correct. As FreedomTruth pointed it out. Trying to mount /dev/sda must have reported an error message. Following command was also not correct, one missing dash maybe a typo for "--bind":
You don't need to reinstall, only start over the procedure that will update the initrd file with your encryption settings. From a live session unlock partition sda2 and activate lvm volume group vg1 and logical volumes :
Code: Select all
sudo cryptsetup luksOpen /dev/sda2 luks1 sudo vgchange --activate y
Code: Select all
sudo mount /dev/mapper/vg1-root /mnt sudo mount /dev/sda1 /mnt/boot sudo mount --bind /dev /mnt/dev sudo chroot /mnt mount -t proc proc /proc sudo chroot /mnt mount -t sysfs sysfs /sys sudo chroot /mnt mount -t devpts devpts /dev/pts
Code: Select all
sudo chroot /mnt update-initramfs -u
Code: Select all
Yes, really hard to get through so many terminal commands without making a typo or two, especially when, not being very conversant in terminal "grammar", one mostly lacks the ability to see when the rules are being broken. It becomes a matter of monkey see, monkey do.
I've been busy, so couldn't get to this today, maybe not tomorrow either, but definitely ASAP.
Laurent85, You da MAN!
Everything is up and running.
One of the nice things about this setup is that there's only one passphrase entry required on bootup.
I am going to clone the existing installation as a backup, then try the standard Ubiquity installation, with a manual mount when Ubiquity tells me that it has failed to mount the root partition.
I suspect it will not work, but it is worth a try...unless someone already *knows* that it will not work.
And thanks to all who contributed.
I tried again to install an FDE system with separate boot, root, swap and home partitions, not using LVM, and using just the Ubiquity installer.
I used the process as first tried, looking to find a way to get Ubiquity to mount sda5_crypt. Just before clicking Install Now, I checked the mount status of all partitions using a terminal and <lsblk>. Only the install DVD and loop0 were mounted.
Clicked Install and checked again. No change.
Clicked Continue and checked again. Usual error: “Mount of sda5_crypt failed”.
Lsblk now shows swap mounted, but nothing else.
I tried various ways of mounting sda5_crypt, but I suppose the less said about that the better. It's quite likely that I was going about it in an entirely wrong way, given I know so little about what is going on "under the hood". Let's just say that nothing I tried worked.
I still wanted to attempt the non-LVM kind of FDE installation, I looked around some more and found this: http://thesimplecomputer.info/full-disk ... ith-ubuntu
I did as instructed, and carefully. When setting up the system, I used the same passphrase for root, swap and home partitions.
On reboot, I got the decrypt prompt, entered the passphrase, and the comp sat for a while, then went to BusyBox.
I typed 'exit', and BB began checking dev/mapper/root file system, then a prompt to decrypt home partition showed, within BB. I entered the passphrase, and the machine finished booting.
Opened Places and found a 4.2GB device mounted. I had created a 4GB swap partition, so I figured that had to be it, though I was not expecting it to show in Places, I clicked on it, was prompted for a passphrase, entered it, and a message said “Unable to mount...no recognizable file system”. Dismissing the message resulted in the 4.2GB partition disappearing from Places. Since no file system is on swap anyway, and it does not have to be mounted to work, I figured all was OK.
The installation seemed basically good, except the tutorial had said: “If you do have systemd (Jessie, 15.04, CentOS 7...) and /home is using the same passphrase as /, then /home will be decrypted automatically after you enter the system partition's passphrase.”
But that didn't happen for me; had to enter the pwd for each partition separately. Also, it didn't seem normal that, after the usual Mintleaf screen asking for root's pwd, BB would open, and that I would have to type 'exit' and enter a passphrase for home right there in BB. It also doesn't seem normal to have to also open up Places after full bootup and decrypt swap from there.
To see if this would resolve itself, I shutdown and rebooted. The same routine occurred. I entered the passphrase for root and home as before and got the system up and running again.
I did a little looking on the net about systemd:
https://unix.stackexchange.com/question ... dy-mounted
I began to suspect that since the tutorial was last updated in June 2015, changes to systemd had led to this abnormal boot behavior.
And it seems that, according to message #202 in the above link, systemd only works for multiple encrypted partitions if LVM is used. As of Feb.2, 2018, this bug has not been fixed.
But I checked the Updater anyway. There was indeed an update for systemd. I could not find anything in the changelog that might point to this update curing the problem, but I installed it anyway.
Things went as before, except that when BB opened, it was telling me: “USB2-port4 disabled by hub”. It kept trying and failing to enable it. I exited, and BB briefly attempted a scan of Btrfs file systems (of which there are none on my computer). It then opened a prompt to decrypt the home partition. I entered the passphrase, it started the Btrfs scan again, then broke off and finished booting.
I then installed upstart-sysv, which required uninstalling systemd-sysv.
The same as the last time; “USB2-port4 disabled by hub”, exiting causes BB to attempt a scan of Btrfs file systems; exiting causes it to open a prompt to decrypt the home partition. But this time entering the passphrase does not work; it asks for the passphrase again. So I am locked out of the computer.
Rather than do a full re-install of this non-LVM system, and try some other solution, I decided to just restore the Laurent Method LVM system that I had cloned with RedoBackup immediately after completing it.
I conclude that systemd prevents proper functioning of an install of Mint 18.3 when multiple encrypted partitions are used, but LVM is not used.
Too bad. LVM works, of course, but RedoBackup, which I use, does not allow for cloning individual logical volumes within your volume group; the whole group has to be cloned. So one of the main advantages to separate root and home partitions, which is to be able to clone the system partition alone, so your system clones are small and fast, is not possible. Even with a volume group having ca. 640GB of total space, at least backup goes quickly. In my test case, the actual used space of my up and running system was only 6.6GB. The saved backup clone totalled 22.6GB in total size. So a bit by bit backup of all volumes (i.e. including free space) is not being done, it seems. But restore takes a long time (13hrs on my machine, which has a 2.3GHz CPU and almost 4GB RAM). It seems to be copying over the entire volume group on a bit by bit basis. So there is some mystery to me here. RedoBackup is plainly not making a bit by bit backup of the volume group, including free space, but it seems to be restoring in that fashion.
Unless some expert has produced a tutorial for a workaround, it looks like Joe User at present has no way to make an FDE installation of the kind I wanted, but has to use LVM.
One thing that partially saves the situation for the LVM installation is that TimeShift sees the LVM root and home partitions, and can backup and restore them separately or together. Although I would not trust TimeShift nearly as much as a clone, I did test it, and it worked. Since I don't find anything on the forums about how to use TimeShift to backup and restore FDE LVM installations, I thought some might find it useful to have a general idea of how that works.
With the LVM encrypted computer up and running, open TimeShift. Under Settings>Users, you will see the logical volumes root and home (not swap, since no one needs to back that up anyway). You can select either the root or the home volume, or both, for backup. If backing up the root, you should probably check the boxes for Include Hidden Items, and Include Everything. On the Location tab you can choose an external drive as the backup location.
You can of course restore these volumes by opening TimeShift in the running system. If the system is broken and cannot boot, it can be restored from a live DVD/USB.
Boot into a live session with your Mint install DVD.
If the version of Mint your install DVD contains already has TimeShift, just open TS from the menu. If it doesn't, get on the internet and install it into the live system:
<sudo apt-get update>
<sudo apt-get install timeshift>
Now TS can be used just as it would be if your system had been able to boot.
Open TS from the main program menu.
You will see your backup in the list of backups. (If you do not, your external drive is probably not on. Turn it on. TS should see it. (If it doesn't, you may have to close out and reopen TS. Note: Clicking the Menu button in the upper right corner of TS gives you an option to refresh the disk list. It does not seem to work.) Now click Settings>Location, and select that drive from the available sources. In any case, to assure that the source drive is correct, click Settings>Location and check which drive is selected.
Go back to the main menu, select the backup you want to restore from the list (all will be from the external drive, since you selected that as your Location), and click Restore on the main menu.
A dialogue box will come up, called Select Target Device.
Assuming you have backed up boot, root and home, you will see these as available for restoration.
Clicking on the option bar for root shows all drives (greyed out) and partitions (selectable). In my case, sda2, my LUKS container, was one of these. Selecting that opens a prompt for the passphrase. Entering that unlocks sda2 and shows the logical volumes in the container. Mine were called dm-1 (that was the root) and dm-3 (home). Since I was in the root option bar, I selected dm-1.
In my case, I wanted to restore both home and root, so I clicked on the option bar for home. It shows the same possible selections. I chose dm-3. Caution: It is possible to choose any ungreyed-out option, but of course only one is correct.
A large option bar underneath the others is labeled Bootloader Options (Advanced). Clicking on this gives the following choices:
(Preselected) Reinstall GRUB2 on:
And the option bar under this had the choices: (preselected) sda, sdb
(MBR), sdb1, and sda1. The correct choice for me was sda, as preselected.
(Unpreselected) Update initramfs. Hovering the mouse over this gives info: “Generally
not needed. Select only if boot fails.”
(Preselected) Update GRUB menu. A mouse hover reveals: “This is safe to run and
should be left selected”
I proceeded with the restore. It ran very fast; maybe two minutes.
When finished, the status report said that 14 files were created, 11 deleted, and 44 changed from the original installation. Since nothing had changed on the machine, because I booted into the live DVD for the restore immediately after saving the backup that was restored, I suspect this means simply that some files were overwritten, and/or that dates were changed – at least I hope that this is the case. It does go to show why I prefer cloning.
After the failed non-LVM installation, I restored the clone I had made, using RedoBackup, of the LVM installation.
It did not work.
On powerup, I entered the BIOS password, and after a few moments the prompt for the password just came back. Re-entered pwd, and the prompt came back...etc.
Actual bootup never started.
RedoBackup has not been updated since 2012; it's still version 1.0.4.
But it's not that it was never designed to handle FDE backup and restore, at least for an LVM FDE installation, because as said above I tested backup and restore right after my LVM FDE installation, and it worked. It seems something happened during the non-LVM installation that changed something at a deep enough level that RedoBackup did not overwrite it when the restore of the LVM installation was done.
Good thing I also have a full system backup of the LVM FDE installation done by TimeShift.
That did work.
Double backups...always good!
Double backups using two different backup methods...always better.
BTW, when doing the restore using TimeShift, I did not select the Update Initramfs box, but it still worked. Moreover, the restore was blazing fast; around two minutes.
I just lost a little respect for RedoBackup, and gained a lot for TimeShift.
I've been trying to make a Mint 19 FDE setup work on multiple drives, not just multiple partitions like you. The approach I'm attempting now (for the second time) is to just accept all the setup defaults, so I end up with a working single-drive system, and adding FDE to my second drive, with the intent of eventually moving /home to it. I want to do it in a fairly standard way, though, because I've had custom solutions break when I'd done updates, usually on days when I absolutely needed a working computer. The solution I've seen posted so far is old and requires a lot of tinkering, so I don't feel safe using it.
You seem to know more about this than me. Can you follow the link to my post and offer some advice? And if the page you linked to is still available, maybe you can post an updated link? Thanks!