How to install with encrypted root partition that includes /boot?

English Install/Boot/Login
1

I have Windows 7 installed on a different drive, so I can’t use Secure Boot.

I want to set up 3 encrypted partitions on the SSD:

/
/home
Swap

After it’s set up I plan to set up keyfiles so that I only need to enter the LUKS password once:

https://en.opensuse.org/SDB:Encrypted_root_file_system

In the above article, it says:

“Warning: Do this only if you have an encrypted root partition that includes /boot (no separate /boot partition)!”

The problem is, I haven’t been able to figure out how to install TW without the separate /boot partition.

I’ve tried going through the guided setup (selecting encryption, separate / and /home partitions), and it creates a separate unencrypted /boot partition. If I keep the current proposal and go into Expert Partitioner and remove the /boot partition, I get a number of warnings saying I won’t be able to boot if I proceed with the install.

I didn’t select LVM because I don’t anticipate needing it - it’s a 1 TB SSD, with 100 GB for / and 16 GB Swap and the rest for /home. I also know how to back up and restore LUKS partitions with Clonezilla but don’t know how with LVM and LUKS.

The weird thing is, I did this successfully a month ago on a laptop (which dual booted with Windows 10) but I don’t remember running into any issues with the install (or maybe I saw warnings that I just ignored and forgot after I saw it worked).

2

I normally use an encrypted LVM. In the past you had to use an LVM to encrypt the root file system. But, starting some time last year (the new partitioner) it should now be possible.

I think I’ll need to experiment with this, and then comment further when I have had a chance to see how it goes.

Are you using “btrfs” for the root file system? Or something else?

3

Thanks for the response, I appreciate you looking into this!

I’m using BTRFS for root and XFS for home.

4

I tried setting this up, and it worked the first try. I went into guided setup, said to use encryption and a separate “/home” and swap. It set those as three encrypted partitions. It did not propose a separate “/boot”.

I think I was misled by your post. You mentioned that you could not use secure-boot (which actually did not make sense). So I setup my virtual machine for UEFI booting without secure-boot.

I now think you intended to say that you were not using UEFI. And I did not test that, though I may test later.

Here’s what I suspect is the problem:

There need to be somewhere for the boot code to go, and the boot code has to include crypto support.

If using UEFI, the boot code goes in the EFI partition, and there isn’t a problem.

If not using UEFI, then the boot code has to go in the MBR. It cannot go in a partition, because the partitions are encrypted. So that leaves only the MBR. When you use the MBR for grub with traditional BIOS partitioning, it puts part of the boot code in the gap between the MBR and the first partition. My guess is that on your computer, that gap is too small. Older computers used cylinder alignment and started the first partition at sector 63. That leaves on 62 sectors (31K) in the MBR gap), which is too small for the crypto. New computers use megabyte alignment, with the first partition starting at sector 2048. That leaves 2047 sectors (almost 1M) for boot code, which should be enough.

I’m guessing that you have the older partitioning scheme with the first partition starting at sector 63.

The easiest choice would be for you to use a separate unencrypted “/boot”. You should still only be prompted once for the encryption key and you won’t have to setup anything special for that. During boot, the system remembers the first encryption key that you use, and tries that for other encrypted partitions. It it works, you are not prompted again.

5

Sorry for the confusion and thanks for explaining things!

My computer is using UEFI with the compatibility support module (CSM) for Windows 7. My understanding when wrote the initial post was that W7 didn’t support Secure Boot, so I couldn’t enable it or boot without the CSM. I thought my only choice was to install Tumbleweed without using UEFI so that I could continue to have the option of booting into W7. I also thought that I had to use Secure Boot if installing TW in UEFI mode.

When I deleted the /boot partition I also moved the / partition to the start of the disk, not realizing it would leave no space for the MBR. This explains why my laptop didn’t give any problems - the MBR was already “reserved” from the W10 install in the “front” of the drive.

If I understand what you’re saying, would an alternative to having an unencrypted /boot partition be to delete the /boot partition and leave the 8 MB space (previously occupied by the deleted /boot partition) empty for the MBR?

I had initially planned to transition to TW (using it is my primary OS and only using Windows for incompatible games or other Windows-only tasks) in the period between now and the end of the year. However, that could mean my permanent TW install being held back by not using UEFI and Secure Boot (I’m not sure how easy it is to switch to it after installing).

I think it would be best in long term if I upgraded W7 to 10 now, enabled UEFI with Secure Boot for it and then install TW with UEFI and Secure Boot.

6

I doubt a Windows upgrade allows a change of boot method. You would need to reinstall

All OS must use the same boot method to chain boot. So if you use Win 7 MBR boot then you need to install openSUSE with MBR boot (legacy)

If you want encryption it is much easier to use an encrypted LVM container.

7

Oops. Another misunderstanding.

There is no such thing as an 8mb “/boot”. I may have used one that small in the 1990s, but that would be far too small today for the size of the kernel.

Almost certainly, you are not talking about “/boot” at all. You are, instead, talking about a “bios_boot” partition. That is not “/boot” and it is not mounted as part of your installed system. That’s just a place where grub can install its boot code. It is only used with GPT partitioning. And the installer defaults to using GPT partitioning on an otherwise unused disk.

So just go ahead and allow that 8mb “bios_boot” partition.

8

I’ve upgraded Windows from 7 to 10 and switched to UEFI booting with Secure Boot enabled (using the default keys that came with the motherboard).

I tried to install Tumbleweed with both the net image and DVD image and neither will boot to the install environment with Secure Boot enabled. In order to install I need to disable Secure Boot.

After doing that and configuring the install with root (BTRFS) and home (XFS) encrypted (without LVM), I notice that by default it creates a 500 MB unencrypted /boot/efi partition. I’m not sure if kernels are stored there, but if they are and I understand correctly, it shouldn’t matter if it’s left unencrypted with Secure Boot is active (which should prevent attacks like getting the kernel switched), so I leave it in place. At the end before the install starts I see the option for Secure Boot enabled.

After completing the install, it works if I leave Secure Boot disabled but if I re-enable it in UEFI, TW no longer boots (same thing as what happened with the USB flash drive when I went to install).

If I go into YaST Boot Options, it says that Secure Boot support is enabled.

Is there something I’m missing?

9

It’s hard to say what you need to do to get Secure Boot working.

You can try to find the manual for your motherboard:

dmidecode -t 2

Here’s what it took for me: https://forums.opensuse.org/showthread.php/537297-Secure-Boot-with-Gigabyte-UEFI-DualBIOS

Here’s the openSUSE documentation for it: https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.uefi.html

10

Secure boot is security theater if anyone can mess with the boot stack then they already own the machine

You should be able to switch it back on if you need the security blanket since the kernel has proper credential.

Sometimes the UFEI does not like the installer but once installed it should be ok.

11

It uses the exiting EFI partition if it is at least 256M. Otherwise it wants to create an new EFI partition. But you can force it to use the existing EFI partition with the expert partitioner. It will complain, but that probably works anyway.

I’m not sure if kernels are stored there, but if they are and I understand correctly, it shouldn’t matter if it’s left unencrypted with Secure Boot is active (which should prevent attacks like getting the kernel switched), so I leave it in place.

Normally, kernels are not installed there unless you add XEN support (for virtual machines).

After completing the install, it works if I leave Secure Boot disabled but if I re-enable it in UEFI, TW no longer boots (same thing as what happened with the USB flash drive when I went to install).

Take a look at this page:

openSUSE:UEFI

Scroll down until you find the heading “Booting the Machine that supports only one signature with vendor provided Keys”

There’s a good chance that applies to your system.

If I go into YaST Boot Options, it says that Secure Boot support is enabled.

Secure boot support enabled is not the same as secure boot enabled.

Secure boot support means that if you enable secure-boot, and if that secure-boot meets the usual standards, then openSUSE can still boot your system. However, your system seems to not meet the usual standards.

12

Thanks for your help with this, I decided to disable Secure Boot.

As a note to those who configure encryption in the future, if you find that booting is very slow (was about 1 min for me, unlocking 3 partitions), you can speed it up by reducing the number of iterations while decrypting volumes. The iterations are in place to reduce the effectiveness of brute force attacks, so if you use a weak password, with a low number of iterations (fast time to decrypt), it will guessed quickly (without iteration restrictions, an attacker can currently guess around 350 to 400 billion passwords per second, nation states can probably guess 1 trillion/sec). If you use a strong password that you’ve very confident in, you can reduce the number of iterations to reduce the decryption time (if you reduce it to 1 guess/sec, it’s still 350+ billion times longer to brute force).

To view the slots being used and the number of iterations per slot for a partition at /dev/nvme0n1p2 (as an example - for yours, you can check with sudo blkid or a GUI partitioner):

sudo cryptsetup luksDump /dev/nvme0n1p2

If you want to change the number of iterations for slot 0, you’ll need to:

  1. Create a new key in another slot
  2. Erase the key allocated to slot 0
  3. Create a new key in slot 0 with the settings/iterations you want
  4. Erase the slot created in step 1

To add a key to slot 3 on /dev/nvme0n1p2 with 1000 iterations:
sudo cryptsetup luksAddKey -i 1000 /dev/nvme0n1p2 -S 3

If you’re using a key file (.root.key in the root directory) and want to add it to slot 2:
**sudo cryptsetup luksAddKey -i 1000 /dev/**nvme0n1p2 /.root.key -S 1

To erase the key in slot 0 on /dev/nvme0n1p2:
sudo cryptsetup -v luksKillSlot /dev/nvme0n1p2 0

To see how long it takes to decrypt dev/nvme0n1p2 with the key in slot 3 (for the purpose of checking how long it takes, it doesn’t matter if you enter the correct passphrase or not):
sudo cryptsetup -v luksOpen --test-passphrase /dev/nvme0n1p2 -S 3

Doing that reduced my boot time to about 20s.