Linux Mint choked at decryot password, thus unable to use Timeshift
October 28, 2020 6:20 PM Subscribe
I keep Timeshift up to date to facilitate reload if the machine gets unhappy and/or fussy. But my puter got unhappy and fussy at the encryption login; I couldn't get near Timeshift, or anything else. Most all was backed up using external drives, lost a few files plus had to reload Mint, no big deal. I did encrypt it again because hey, Linux Mint, easy-peasy. But supposing the machine gets south-footed again, how can I get to Timeshift? And what the hell happened to lock me out -- never happened before or since.
You boot with a live CD that has 'cryptsetup' and 'LVM' support. Then you mount the disk via the 'cryptsetup', then you mount the LVM volumes with the 'lvm-random-stuff' and you fix what was broken.
Sorry, it's not easy, it's a PITA to do. Probably what happened was during an upgrade or something your '/boot/initrd.something' got created without the necessary 'cryptsetup/LVM' bits leaving you unable to mount the root partition.
What's supposed to happen is that your unencrypted /boot partition holds the kernel and an initrd. The kernel loads and then loads the initrd which has a bit of smarts in it that knows to run the cryptsetup stuff (ask for password to map the encrypted bit to a sort of virtual disk) and then do the LVM stuff to mount the /root, etc. LVM partitions that live inside that encrypted disk-thing into regular filesystems that you no longer think about. With Debian (I think Mint is a subset of Ubuntu which is a subset of Debian gah!) when you install a new kernel there's a bit of code that gets run to recreate a new initrd image, it's supposed to notice that your disk is LVM and is encrypted and put the needed bits into the initrd image. For some reason that didn't happen this time.
You would probably spend more time trying to read up on how to fix this (and it would probably take another computer and a USB drive and finding a suitable LiveCD with the tools you need and knowing how to get your encrypted disk back online and how to go in and fix it so that you can reboot and it would work).
It's wizardly. Good for you that you have backups. Even I would probably not bother and just take the opportunity to upgrade the OS all clean-slate and pull in things from backups as needed as a sort of spring cleaning. Because fixing this when you're not prepared and don't already know mostly how to fix it is a PITA.
posted by zengargoyle at 10:24 PM on October 28, 2020 [1 favorite]
Sorry, it's not easy, it's a PITA to do. Probably what happened was during an upgrade or something your '/boot/initrd.something' got created without the necessary 'cryptsetup/LVM' bits leaving you unable to mount the root partition.
What's supposed to happen is that your unencrypted /boot partition holds the kernel and an initrd. The kernel loads and then loads the initrd which has a bit of smarts in it that knows to run the cryptsetup stuff (ask for password to map the encrypted bit to a sort of virtual disk) and then do the LVM stuff to mount the /root, etc. LVM partitions that live inside that encrypted disk-thing into regular filesystems that you no longer think about. With Debian (I think Mint is a subset of Ubuntu which is a subset of Debian gah!) when you install a new kernel there's a bit of code that gets run to recreate a new initrd image, it's supposed to notice that your disk is LVM and is encrypted and put the needed bits into the initrd image. For some reason that didn't happen this time.
You would probably spend more time trying to read up on how to fix this (and it would probably take another computer and a USB drive and finding a suitable LiveCD with the tools you need and knowing how to get your encrypted disk back online and how to go in and fix it so that you can reboot and it would work).
It's wizardly. Good for you that you have backups. Even I would probably not bother and just take the opportunity to upgrade the OS all clean-slate and pull in things from backups as needed as a sort of spring cleaning. Because fixing this when you're not prepared and don't already know mostly how to fix it is a PITA.
posted by zengargoyle at 10:24 PM on October 28, 2020 [1 favorite]
To prevent it in the future.... your /boot and /boot/grub are typically not-encrypted. GRUB (the bootloader) has to be able to get some things from unencrypted bits of the disk before hitting the encrypted part.
Look at your /boot/grub/grub.cfg then make a copy of it named /boot/grub/my-grub.cfg just in case. Look for the first section that goes like:
Then, when you reboot and things break, you need to know how to escape into the GRUB bootloader, usually you press a key or something but who knows how splash-screen-hide-everything Mint is. But you get to a GRUB prompt and you have to guess and use TAB-completion to figure things out. But you want to do a 'linux (hd??????)' sort of thing to find the partition where your copied kernel lives, it'll be like 'linux (hd0,2)/my-vmlinuz.....' and you want to put the 'root=....' bit on it. That will load your saved kernel into memory with the right parameters (you can ignore most of the rest, they don't really matter). Then you want to do the same thing with the 'initrd ....' line, TAB-complete to (hd0,2)/my-initrd....' which will load your saved initial ramdisk (go figure). Then you cross your fingers and type the magic command 'boot'. If all works out, you'll boot back into that working setup that got borked by some upgrade and then you have the task of trying to fix things so that it works the next time without the hassle.
Eventually after years of goofing around you start to do things like making your /boot partition a bit large and putting whole LiveCD .iso(s) in your grub.cfg so as long as your disk isn't bonked or you have a bootable GRUB based USB stick lying around you can just fumble your way through fixing this sort of "WTF I can't boot" thing.
Good luck, you should try this while things are working. Find out how to get to the GRUB command line (and even setup GRUB so that it doesn't do the graphical immediate boot pretty thing and just tells you to hit a key within a few seconds to get to the command line). Then try to poke around and boot your system. Half of being able to recover from these sorts of disaster is just having done it before and halfway knowing what it takes and fumbling through until you get it right.
posted by zengargoyle at 11:26 PM on October 28, 2020
Look at your /boot/grub/grub.cfg then make a copy of it named /boot/grub/my-grub.cfg just in case. Look for the first section that goes like:
menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --clas
s os $menuentry_id_option 'gnulinux-simple-a293b1f4-53eb-4c1b-b88d-6c854ac3cc28'
{
load_video
insmod gzio
if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
insmod part_gpt
insmod ext2
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root 609fa044-e0c3-4b60-aa71-089fd411b487
else
search --no-floppy --fs-uuid --set=root 609fa044-e0c3-4b60-aa71-089fd411b487
fi
echo 'Loading Linux 4.19.0-11-amd64 ...'
linux /vmlinuz-4.19.0-11-amd64 root=/dev/mapper/gaz--vg-root ro quiet
echo 'Loading initial ramdisk ...'
initrd /initrd.img-4.19.0-11-amd64
}
and ignore most of it. What you want is the 'linux' and 'initrd' bits. Find those in /boot and make a copy like the grub.cfg file.Then, when you reboot and things break, you need to know how to escape into the GRUB bootloader, usually you press a key or something but who knows how splash-screen-hide-everything Mint is. But you get to a GRUB prompt and you have to guess and use TAB-completion to figure things out. But you want to do a 'linux (hd??????)' sort of thing to find the partition where your copied kernel lives, it'll be like 'linux (hd0,2)/my-vmlinuz.....' and you want to put the 'root=....' bit on it. That will load your saved kernel into memory with the right parameters (you can ignore most of the rest, they don't really matter). Then you want to do the same thing with the 'initrd ....' line, TAB-complete to (hd0,2)/my-initrd....' which will load your saved initial ramdisk (go figure). Then you cross your fingers and type the magic command 'boot'. If all works out, you'll boot back into that working setup that got borked by some upgrade and then you have the task of trying to fix things so that it works the next time without the hassle.
Eventually after years of goofing around you start to do things like making your /boot partition a bit large and putting whole LiveCD .iso(s) in your grub.cfg so as long as your disk isn't bonked or you have a bootable GRUB based USB stick lying around you can just fumble your way through fixing this sort of "WTF I can't boot" thing.
Good luck, you should try this while things are working. Find out how to get to the GRUB command line (and even setup GRUB so that it doesn't do the graphical immediate boot pretty thing and just tells you to hit a key within a few seconds to get to the command line). Then try to poke around and boot your system. Half of being able to recover from these sorts of disaster is just having done it before and halfway knowing what it takes and fumbling through until you get it right.
posted by zengargoyle at 11:26 PM on October 28, 2020
« Older Should I be worried about my teeth? | Phantom toilet flushing and air in the pipes, oh... Newer »
This thread is closed to new comments.
posted by fritley at 7:21 PM on October 28, 2020