Ubuntu – How to reinstall kernels after accidental deletion with a separate boot partition and an encrypted LVM volume

First, it's not 100% clear that you booted the installer in EFI mode. If it booted in BIOS mode, it would try to install grub-pc (for BIOS-based systems), which wouldn't work if your firmware is set to boot the hard disk in EFI mode. I doubt if this is the problem, but I thought I'd toss it out as a possibility. You can check your boot mode by dropping to a shell and looking for the /sys/firmware/efi file; if it's present, you've booted in EFI mode. If not, you've probably booted in BIOS mode, although that's not 100% certain.

In any event, at this point your best bet is to do a manual installation of an EFI boot loader. IMHO, GRUB 2 (which is Ubuntu's default) is the worst possible choice; it's flaky and unreliable on EFI systems, in my experience. The easiest to get working is likely to be either ELILO or Fedora's patched GRUB Legacy. If you want to use a 3.3.0 or later kernel, it includes its own built-in EFI boot loader, which is quite reliable and can be very easy to use if paired with rEFInd. My Web page on EFI boot loaders describes all the options and includes installation instructions. Detailing them all here would be impractical.

Offhand, I'm thinking that if your using the entire device (/dev/sdb) and your LUKS header is at the start of the drive, and if some other tool or OS "helpfully" decides that your disk is unformatted with no MBR or GPT, if it were to overwrite your LUKS header that would be bad. If you were using a partition for LUKS then at least a new MBR or GPT wouldn't be as devastating.

You should always backup the LUKS header anyway, as the cryptsetup man page advises too.

And this is what the cryptsetup FAQ says about using "2.2 LUKS on partitions or on raw disks?" (it's long but I'll just paste it, mentions RAID & LVM can greatly complicate things, you may want to rethink using LVM on top of LUKS):

This is a complicated question, and made more so by the availability of RAID and LVM. I will try to give some scenarios and discuss advantages and disadvantages. Note that I say LUKS for simplicity, but you can do all the things described with plain dm-crypt as well. Also note that your specific scenario may be so special that most or even all things I say below do not apply.

Be aware that if you add LVM into the mix, things can get very complicated. Same with RAID but less so. In particular, data recovery can get exceedingly difficult. Only do so if you have a really good reason and always remember KISS is what separates an engineer from an amateur. Of course, if you really need the added complexity, KISS is satisfied. But be very sure as there is a price to pay for it. In engineering, complexity is always the enemy and needs to be fought without mercy when encountered.

Also consider using RAID instead of LVM, as at least with the old superblock format 0.90, the RAID superblock is in the place (end of disk) where the risk of it permanently damaging the LUKS header is smallest and you can have your array assembled by the RAID controller (i.e. the kernel), as it should be. Use partition type 0xfd for that. I recommend staying away from superblock formats 1.0, 1.1 and 1.2 unless you really need them. Be aware that you lose autodetection with them and have to fall back to some user-space script to do it.

Scenarios:

(1) Encrypted partition: Just make a partition to your liking, and put LUKS on top of it and a filesystem into the LUKS container. This gives you isolation of differently-tasked data areas, just as ordinary partitioning does. You can have confidential data, non-confidential data, data for some specific applications, user-homes, root, etc. Advantages are simplicity as there is a 1:1 mapping between partitions and filesystems, clear security functionality and the ability to separate data into different, independent (!) containers.

Note that you cannot do this for encrypted root, that requires an initrd. On the other hand, an initrd is about as vulnerable to a competent attacker as a non-encrypted root, so there really is no security advantage to doing it that way. An attacker that wants to compromise your system will just compromise the initrd or the kernel itself. The better way to deal with this is to make sure the root partition does not store any critical data and move that to additional encrypted partitions. If you really are concerned your root partition may be sabotaged by somebody with physical access (that would however strangely not, say, sabotage your BIOS, keyboard, etc.), protect it in some other way. The PC is just not set-up for a really secure boot-chain (whatever some people may claim).

(2) Fully encrypted raw block device: For this, put LUKS on the raw device (e.g. /dev/sdb) and put a filesystem into the LUKS container, no partitioning whatsoever involved. This is very suitable for things like external USB disks used for backups or offline data-storage.

(3) Encrypted RAID: Create your RAID from partitions and/or full devices. Put LUKS on top of the RAID device, just if it were an ordinary block device. Applications are just the same as above, but you get redundancy. (Side note as many people seem to be unaware of it: You can do RAID1 with an arbitrary number of components in Linux.) See also Item 2.8.

(4) Now, some people advocate doing the encryption below the RAID layer. That has several serious problems. One is that suddenly debugging RAID issues becomes much harder. You cannot do automatic RAID assembly anymore. You need to keep the encryption keys for the components in sync or manage them somehow. The only possible advantage is that things may run a little faster as more CPUs do the encryption, but if speed is a priority over security and simplicity, you are doing this wrong anyways. A good way to mitigate a speed issue is to get a CPU that does hardware AES.