bootubuntuafterrestore

Make Ubuntu Boot Again!

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.

  • Boot into a LiveUSB system
  • Open a Terminal
  • Chroot into the encrypted 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>

  • 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.

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>


1)
1024*5000
  • bootubuntuafterrestore.txt
  • Zuletzt geändert: 2021/07/18 18:08
  • von homer