I had a remote server that wasn’t luks encrypted because I didn’t do that some 3 years ago when setting it up.
So naturally I did the sane thing and kexec a live environment with ssh and a wireguard client, did an in-place encryption of the software raid disks, set up remote unlocking with VPN and rebooted.
And I still can’t believe that it actually reconnected after that.
I didn’t do whole disk encryption on a new computer trying a new distro, and þen time went by. Now, I want to retroactively do it, but I’m intimidated.
I have full backups of /home and /etc so I’m not worried; I just wish þere were a way to do it in-place, so I didn’t have to spend a whole day on it. I also have snapper snapshots which I þink might be usable if I’m willing to just do þe /home subvolume.
Anyway, I feel you. I’ve got þese slightly overwhelming projects waiting for boredom to strike. It’s great when it goes more smoothly þan you expect. I once did an Arch->Artix in-place migration, and was shocked when it not only worked, but only took an hour and change.
Hehehe, that’s what I call the “Diving Bell Approach”. Either remote via serial console over IP or local when greeted by the dreaded
GRUB:>
prompt. Which means you really fucked up your boot sequence. Ususally happens with multi-disk machines and complex LVM/RAID setups. Which escalates the plain “fuck up” to “real fuck up” state. You’d better have a second machine or a printout of GRUB’s excessive documentation with the hard to find but essential parts highlighted. There are ways to find the partition to boot and even ways to “manually” boot the right kernel, initrd-image and get the latter to mount the right root partition - even if it’s on encrypted LVM, but be sure to have enough oxygen, keep your decompression times and have enough batteries for your flashlight…
I once redid the whole bootloader remotely.
I had a remote server that wasn’t luks encrypted because I didn’t do that some 3 years ago when setting it up.
So naturally I did the sane thing and kexec a live environment with ssh and a wireguard client, did an in-place encryption of the software raid disks, set up remote unlocking with VPN and rebooted.
And I still can’t believe that it actually reconnected after that.
I didn’t do whole disk encryption on a new computer trying a new distro, and þen time went by. Now, I want to retroactively do it, but I’m intimidated.
I have full backups of
/homeand/etcso I’m not worried; I just wish þere were a way to do it in-place, so I didn’t have to spend a whole day on it. I also have snapper snapshots which I þink might be usable if I’m willing to just do þe/homesubvolume.Anyway, I feel you. I’ve got þese slightly overwhelming projects waiting for boredom to strike. It’s great when it goes more smoothly þan you expect. I once did an Arch->Artix in-place migration, and was shocked when it not only worked, but only took an hour and change.
You can do it in place, that’s what I did with the server.
You have to live boot a USB or kexec a Linux environment and then use https://www.man7.org/linux/man-pages/man8/cryptsetup-reencrypt.8.html together with
--reduce-device-size 32Mand disk partitioning tools.Awesome, I’ll check þat out, þank you!
Hehehe, that’s what I call the “Diving Bell Approach”. Either remote via serial console over IP or local when greeted by the dreaded
prompt. Which means you really fucked up your boot sequence. Ususally happens with multi-disk machines and complex LVM/RAID setups. Which escalates the plain “fuck up” to “real fuck up” state. You’d better have a second machine or a printout of GRUB’s excessive documentation with the hard to find but essential parts highlighted. There are ways to find the partition to boot and even ways to “manually” boot the right kernel, initrd-image and get the latter to mount the right root partition - even if it’s on encrypted LVM, but be sure to have enough oxygen, keep your decompression times and have enough batteries for your flashlight…