Comment 13 for bug 1514120

/boot can be encrypted. See the link you yourself gave two messages above.

In my case, I have a non-encrypted EFI System Partition (ESP), with the appropriate UEFI GRUB 2 loader with the LVM and LUKS V1 modules (GRUB 2 does not currently support booting from LUKS2 devices). The rest of the disk is a single LUKS V1 partition. GRUB happily opens this, and finds the LVM set up, and /boot is one of the LVM volumes I have set up (swap is another).

The downside of this is that you need to give a LUKS V1 password TWICE: once for GRUB to open the LUKS partition, then the LVM volume and mount /boot; then a second time after GRUB has passed control to the linux kernel in the initramfs as the linux kernel needs to go through the device discovery process and remount the drives. It is possible to set things up so that the linux kernel can open the LUKS partition with a keyfile - the technique is outlined in this linuxquestions.org answer: https://www.linuxquestions.org/questions/linux-security-4/security-implications-of-keyfiles-on-a-luks-encrypted-boot-4175614861 ; and it in turn links to two other documents which describe things in more detail:

https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
https://www.pavelkogan.com/2015/01/25/linux-mint-encryption/

The above links point out that when the system is booted, the keyfile is unencrypted with a copy on the ramdisk, which is likely unacceptable to some people. Holding the keyfile on a separate USB drive which can be removed could be a solution for some people.

It would be helpful if GRUB2 and other bootloaders had a standard method by which LUKS keys could be passed in a secure manner to the kernel being booted, but that is beyond the scope of this bug. As it is, 'full disk encryption' is significantly less functional on GNU/Linux than Bitlocker is on Microsoft Windows.