<markdown>
# Make Ubuntu Boot Again! 

When I restored my full-disk encrypted system with [TimeShift](https://github.com/teejee2008/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

</markdown><cli>
WARNING: Failed to connect to lvmetad.
</cli><markdown>

You'll find a similar report and important hints to solution [here](https://feeding.cloud.geek.nz/posts/recovering-from-unbootable-ubuntu-encrypted-lvm-root-partition/).

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.

* Boot into a LiveUSB system
* Open a Terminal
* Chroot into the encrypted system:
</markdown><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><markdown>

* Now I could edit _/etc/fstab_ **AND** _/etc/crypttab_ and change the __UUIDs__ to right ones which I checked by `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.)*

* After checking that everything I needed was there by:

`apt install lvm2 cryptsetup`

* I could fix my problem by:

`update-initramfs -c -k all`

Now I could reboot into my restored system.


## Resume From Swap doesn't work
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 
</markdown><cli>
sudo blkid
</cli><markdown>
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.
</markdown><cli>
sudo update-initramfs -u -k all
</cli><markdown>
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

</markdown><cli>
sudo swapoff /dev/mapper/ubuntu--vg-swap_1
sudo mkswap /dev/mapper/ubuntu--vg-swap_1 $((1024*5000))
sudo swapon /dev/mapper/ubuntu--vg-swap_1
</cli><markdown>
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

</markdown><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><markdown>
And important thread that helped was https://www.linuxquestions.org/questions/ubuntu-63/ubuntu-19-04-19-10-problem-with-encrypted-swap-partition-4175673274/.


</markdown>
n>