Installing other Linux in an encrypted disk

Question

I recently got an SSD to replace my laptop's HDD and decided to change and use "full disk" encryption.

I created a small unencrypted partition for /boot and an big encrypted LUKS partition where I used LVM to create 5 logical volumes in a volume group:

• One to install Fedora (lv_fedora).
• One for swap (lv_swap).
• One for another Linux OS (lv_os2).
• And two for data (lv_data1 and lv_data2).

I installed Fedora in lv_fedora as my first OS without any trouble and I am able to boot it from GRUB's menu, but now I don't know how could I install another Linux based OS (Linux Mint 17) in the encrypted disk and make Fedora's GRUB2 detect it and boot this OS as well.

I have tried two different approaches. in both cases I started ubiquity, the Linux Mint installer, with the --no-bootloader option, to prevent Mint from installing the bootloader. And in both cases, in order to start installation, I have previously unlocked the LUKS partition from the LinuxMint Live image's file manager to be able to select the corresponding lv_os2 logic volume as installation target. Now:

• First I tried to install Linux Mint in a single partition assigned to / in lv_os2. The installation was successful. From Fedora, I executed grub2-mkconfig -o /boot/grub/grub.cfg to update the GRUB entries (that's what I have been doing all my life when using non-encrypted disk). GRUB detected Linux Mint was present and added the corresponding entries to the boot menu. The problem was that I was not able to boot from those entries afterwards.
• Then I thought maybe [1] it was due to the kernel images being encrypted in the boot folder in Linux Mint's partition. Maybe GRUB 2 needed those files to be in an unencrypted partition, just as when I first installed Fedora (I used a /boot unencrypted partition simply because it was the recommended setup). So this time I backed up Fedora's /boot partition (just in case) and reinstalled Linux Mint, but making it use the unencrypted partition as /boot too, so that the kernel images could be copied into that directory and, maybe, booted after installation. The installation was successful and the "extra" files added in /boot by Linux Mint did not override any of the Fedora files, so at least Fedora was working and I didn't have to use the /boot bakcup. I then started Fedora and executed grub2-mkconfig -o /boot/grub/grub.cfg again. This time it was even worse. GRUB mixed up entries creating, for example, an entry for Fedora (targeting lv_fedora) loading a Linux Mint's kernel image. I tried to manually modify those entries, but unsuccessfully.

I bet I am doing something wrong. Is there a better way to install a secondary Linux OS into an already encrypted volume and let the primary Linux OS handle the boot loader? (updating its GRUB entries to allow booting from the secondary OS as well)

[1]: as you can see, I'm just trying and learning, but I don't have a deep understanding on the subject.

Answer 1

From everything I've read, it seems to come down to having initramfs "embedded into the kernel and loaded at an early stage of the boot process."1

For Mint you will have to configure /etc/crypttab, then make use of update-initramfs.2

From what I understand, this should serve as a guide to creating the initramfs image after installing Mint, which you seem to have installed already. Hopefully this covers everything, but be sure to research each part yourself.

Live boot Mint, mount and chroot to the partition you installed Mint on.3

Create and configure /etc/crypttab to unlock at boot.4 This is where you add the path to your lvm where Mint is installed, which, based on your question, should be located in /dev/mapper/lv_os2 or /dev/<big encrypted LUKS>/lv_os25

Most examples I've seen of /etc/crypttab look like the following:
root /dev/mapper/lv_os2 none luks. The four fields, respectively are: of your choosing, path to the lvm where you installed Mint, none setting the password to be manually entered during system boot, and luks forces LUKS mode, but it doesn't seem necessary.

When no mode is specified in the options field and the block device contains a LUKS signature, it is opened as a LUKS device; otherwise, it is assumed to be in raw dm-crypt (plain mode) format.

Configure /etc/fstab to mount the /dev/mapper/<name> that you just created in /etc/crypttab as the root directory /. Something like:
/dev/mapper/<name> / <fs_vfstype> <fs_mntops>
See man fstab.

Once you have /etc/crypttab and /etc/fstab configured to your liking, you can use update-initramfs to build/update the boot image.

See man update-initramfs. It may be best to use the specific kernel version displayed by uname -r in Mint. The command should look something like update-initramfs -u -k 3.11.0-26-generic except replace the kernel version with your own.

At this point, you might be able to boot into Fedora again and try the grub2-mkconfig -o /boot/grub/grub.cfg option that detected Mint before. If that doesn't work then follow the multi-boot manual config in the GRUB manual.6

Particularly, this part:

In all the OSes install GRUB tools but disable installing GRUB in bootsector, so you’ll have menu.lst and grub.cfg available for use. Also disable os-prober use by setting:

GRUB_DISABLE_OS_PROBER=true

in /etc/default/grub

Hopefully this covers the majority of what you need to get Mint to boot.

Answer 2

It doesn't really answer your question "how", but should give you a bit of insight - and it's too long for a comment.

First of all, you can't boot of an encrypted partition. Simply because a the boot chain does understand encryption only fairly late in the process:

1. hardware loads firmware - typically BIOS of UEFI (on x86 platform). The hardware as such is completely data agnostic - it just loads whatever it finds in some persistent storage (on a predefined address).

2. Firmware loads boot loader or directly the kernel. As with the CPU, it hasn't got any idea about possible encryption modes (not that it couldn't, but it just usually doesn't).

3. If bootloader is involved, it loads the kernel (or a chained bootloader as for example when booting Windows) and more often than not also an initial ramdisk (which can be either in a standalone file or embedded in the kernel image). Here it gets more interesting, since for example GRUB2 should be able to boot from a LUKS device, but the documentation seems to be rather scarce.

4. The kernel mounts the root filesystem and runs init (System V init, systemd, OpenRC, upstart... choices are plentiful).

5. If booting with initial ramdisk, it is first expanded into memory, then mounted and the init system is run from there. The initramfs shuold contain everything needed to mount the proper root file system - typically it contains every available driver (for example RAID drivers that are necessary when the final rootfs is on a RAID device), graphical boot infrastructure - which often means a minimal (or not-so-minimal) X11 stack - and often also tools for mounting encrypted partitions. After all is set up, and the final rootfs mounted the init system run from the initramfs does pivot_root() (see the pivot_root(8) and pivot_root(2) man pages for more details), thus switching the / to the proper file system.

Now, typically the easiest way of booting off an encrypted volume is doing the cryptography setup in step 5 - mostly because it is done by the kernel that is going to run and it can use the infrastructure offered by any decent recent distribution.

Thus you probably want to look into how exactly Fedora and Mint boot from encrypted volume. The solution to your problem might be for example creating an appropriate initramfs image for the Mint kernel. You might even be able to use one initramfs for both kernels, provided you make sure there is a conditional mounting of the right rootfs depending on the kernel booted, although I wouldn't recommend that, especially if you decided to use different (e.g. stock) kernel for each distribution.

That said you might also want to consider whether you really want to have two installations side-by-side - it might be more convenient to run one virtualised.