When I restored my full-disk encrypted system with TimeShift lately it didn't boot after the restoration process. Precisely it could not find my encrypted logical volume that contains the Ubuntu 18.04. And so I received just the
<cli> WARNING: Failed to connect to lvmetad. </cli>
You'll find a similar report and important hints to solution here.
I actually struggled some time because of this:
When running cryptsetup luksOpen, you must use the same name as the one that is in /etc/crypttab on the root parition (sda3_crypt in this example).
And because of the fact that I had to change my harddrive before restoration since I suspected it of being damaged. Since that was the actual problem with the booting process. The machine simply could not find the devices by the old UUIDs.
After some annoying failures I finally found out how to fix my restored system.
<cli> sudo -i cryptsetup luksOpen /dev/sda3 sdc3_crypt vgchange -ay mount /dev/mapper/ubuntu–vg-root /mnt mount /dev/sda2 /mnt/boot mount /dev/sda1 /mnt/boot/efi mount -o rbind /dev /mnt/dev mount -t proc proc /mnt/proc mount -t sysfs sys /mnt/sys chroot /mnt /bin/bash </cli>
lsblk -f
. (I failed some times because I didn't open the volume as sdc3_crypt but like in the instruction as sda3_crypt. So that in the next step the update of the initramfs couldn't find it. Check the correct label in the /etc/crypttab.)
apt install lvm2 cryptsetup
update-initramfs -c -k all
Now I could reboot into my restored system.
If you receive a message after apt upgrade
that the UUID of your /dev/mapper/ubuntu--vg-swap
doesn't link to any device this might be the reason why suspend doesn't work properly.
It means that the UUID which is defined in etc/initramfs-tools/conf.d/resume
isn't correct.
Get the correct UUID by
<cli> sudo blkid </cli>
copy the UUID of the /dev/mapper/ubuntu--vg-swap
and paste it into etc/initramfs-tools/conf.d/resume
instead of the old one.
<cli> sudo update-initramfs -u -k all </cli>
again after that and the error message won't appear again. I didn't start my machine yet but I'm hopefull it will work :P
(compare: https://ubuntuforums.org/showthread.php?t=2401012&p=13800549#post13800549)
As I realized after a while that my setup didn't make use of the 5G big swap partition at /dev/mapper/ubuntu--vg-swap_1 but used a rather smaller swap (< 1G!) I had to do some research again. I had to
<cli> sudo swapoff /dev/mapper/ubuntu–vg-swap_1 sudo mkswap /dev/mapper/ubuntu–vg-swap_1 $1) sudo swapon /dev/mapper/ubuntu–vg-swap_1 </cli>
and htop
as like as swapon -s
showed me that now the far bigger 5G partition was used as swap.
To get that persistent even after an update of the kernel I had also to
<cli>
lsblk -o NAME,UUID ## to get the correct UUID of the swap partition
sudo <your editor> /etc/initramfs-tools/conf.d/resume # to exchange an old UUID that prevented initramfs from working properly to the new one
sudo update-initramfs -k all -u # to update all the kernel variants that could be booted from grub
sudo update-grup ## to update grub
</cli>
And important thread that helped was https://www.linuxquestions.org/questions/ubuntu-63/ubuntu-19-04-19-10-problem-with-encrypted-swap-partition-4175673274/.
n>