How to install on encrypted root with unecrypted boot with Calamares?

Support
, , , ,
1

(TL;DR: see title :slight_smile:)

Hi all, I recently tested Manjaro a bit and I look forward to switching to it! (coming from Linux Mint Cinnamon) :slight_smile:

Of course I first managed to step into the encrypt system trap set by the Calamares installer, which also encrypts boot and leaves you with veeery long decryption times at boot, as GRUB apparently cannot make use of hardware acceleration(?) and thus takes much longer to decrypt than the kernel. (Reducing luks iterations is obviously not the solution as I do not want to weaken the encryption of my data at rest. I do not care about encrypted boot (and as far as I understand it is mostly snake oil anyway?) as I mainly want to encrypt to protect against theft.)

Can anybody tell me how to get the Calamares installer (ideally, if possible) not to encrpyt boot? I already tried a couple of combinations. E.g., following suggestions like [in this post](ugh, cannot include links: forum.manjaro.org/t/which-guide-do-i-follow-for-pre-boot-encryption-that-isnt-the-slow-one/112798), I used gparted to generate a fat32 partition sda1 for boot (with boot and esp flags) and left the rest, sda2, unpartitioned (optionally then already created either ext4 or luks w/ ext4 there before starting the installer), pointed the installer to the sda2 partition (and the installer recognizes sda1 as the place for the bootloader). But then the installer does not seem to care about the existing partitions and just seems to recreate them and either encrypt both or neither, depending on whether you select the option :frowning:

Potentially important: I have Win10 on a seperate SSD and would like to keep a dual boot system. In principle everything works with the installer but I do not want to wait a minute every time I switch on the PC (and be thrown into grub rescue mode (after one minute!) if I have a typo in the password).

I am a bit surprised that I cannot find the concrete solution to this issue, despite the many reports of the issue with GRUB decrypting super slowly – did my search foo fail me? :grimacing: – I did see the guide to manually install(forum.manjaro.org/t/root-tip-do-a-manual-manjaro-installation/12507) and also the hints to use systemd-boot (altough so far w/o guide, just suggestions to “do it”) but as there are also some replies that mention “use a seperate boot partition” and that sounds quite simple, I was wondering how to do it precisely.

Any hints are very much appreciated! :sunglasses:
Cheers!

2

you could use the manjaro architekt install method and iso - not sure how well it is supported currently
or you could do a lot of work circumventing this limitation of Calamares

essentially, in my opinion, it’s just way easier to just use something that does support your wanted way of layout

any distro using Calamares will have the same issue - can’t do it, not easily

I know that Archlabs can.
(not an advertisement - just sharing knowledge and a statement of fact)

But when Manjaro with this setup is your goal - you have a lot of work to do. :wink:
There is a wiki post on how to do it, if I remember correctly.

1 Like
3

Hi @Nachlese thanks for your reply! By wiki do you mean here in the forum? (“tutorial”?) Or in the Manjaro wiki? Searching for encrypt root and other combinations did not yield any results there :thinking:
About architect, they warn that " Do note that Manjaro Architect is [currently unmaintained!] (https://forum.manjaro.org/t/maintainer-s-wanted/19502) You may need to resolve a package conflict" – before I take a gamble there, I would just “simply” (haha) go with above-mentioned guide on how to install manually.

I created this post to find out how exactly you would achieve my goal with “just create a seperate boot partition” that people sometimes advise but never explain in more detail :confused: – or are they just wrong and it is not possible with Calamares after all?

4

I second @Nachlese’s post, but with additional considerations:

You could technically just install a fully encrypted system (using Calamares without any tweaking), but make sure to have a decently sized EFI System Partition (at least 300 MiB). Then afterwards, you switch to using systemd boot instead of Grub.

It will require more knowledge, manual maintenance, and user intervention, however.

In the case of systemd boot, your plain (non-encrypted) EFI System Partition (FAT32) will house your boot files, kernels, and initramfs’s.

1 Like
5

Manjaro-architect is kinda in maintenance mode atm

Edit: nevermind, it hasn’t been updated since 12/16/21

You can either use a regular Manjaro ISO and run manjaro-architect in the terminal there, or you can download the architect ISO from this mirror and boot using that.

I still use it personally, it still works for me.

1 Like
6

yes.
I think it was a post under the “how to” or “wiki” category. But not sure.

I know from experience that (for instance) Google is much better at locating even recent posts here
vs. trying the forum internal search.

Strange - I know.

I did not take the time to locate that wiki or how to post (which certainly is here) for you.
I just know that I saw it once …

1 Like
7

No, they are not wrong.
You’ll need that later in the conversion process you’ll need to do.
… the tedious one I mentioned, to circumvent the limitation of the Calamares installer.

… in the end, you want to have a separate, unencrypted /boot partition

It’s just in preparation for that next step. … and quite a few more … :wink:

When you locate that guide, you’ll see that following it is not trivial.
If you are nor familiar with commands and command line, if don’t know what the process does that is described, you might fail.

AFAIR it was not exactly a - (excuse the term, no “downtalking” intended) recipe.

But it tells you what needs to be done.

If you can (and do) pull this off
you’ll not have any trouble to do a pure Arch install :wink:
where this is very easy, btw …

1 Like
8

I think what you are asking is fairly simple using the custom partition setup in Calamares

  • remove all partitions

Create

  • an efi partition fat32 - 512 M - boot flag - mount on /boot/efi
  • a boot partition - 1G - ext4 - no flag - mount on /boot
  • a root partition - the rest of the space - root flag - mount on / - encrypt the partition

This will put your kernels on unencrypted space and the rest encrypted - no need to mogrify to sd-boot.

Yes - previously the decryption phase was a long wait - I think this has been resolved with the latest iteration of the grub boot loader.

On my playground - I installed a system yesterday using btrfs - swap and hibernate using full disk encryption - and yes the unlocking takes a little time but that is expected and it is nothing compared to what I remember.

There was one small caveat with my test though - which has been reported

2 Likes
9

Hi @linux-aarhus – thanks a lot! Especially for the clear instructions (see my OP: from the “make extra boot”, which people sometime advised, I did not understand that you need both efi and boot partition and therefore ONLY created an efi partition w/ boot flag in my attempts… I assumed that this was meant by boot partition).

I might try it again, although I now already used your instructions Install Manjaro using CLI only and https://archived.forum.manjaro.org/t/howto-install-encrypted-manjaro-using-cli/110553 in parallel yesterday and I think I managed to set it up as intended. (using 500MB ext2 for /boot – any issues to expect compared to 1G ext4?)

It is faster now than with encrypted boot(/efi?), though still “kinda slow” compared to the, e.g. POP!_OS that I installed w/ encryption on an older computer. On my current PC, booting Manjaro with only encrypted root now still takes some 15 s longer than booting unencrypted Mint :confused:

Yes - previously the decryption phase was a long wait - I think this has been resolved with the latest iteration of the grub boot loader.

Cannot confirm. Just checking the “encrypt system” option of the installer added a 50 s wait time only for decryption (directly at the POST screen), compared to ~5 s when decrypting the same disc with a live system (i.e. not with GRUB). Thus my post here :wink:
Is it possible that the maintainers of the Manjaro Cinnamon edition did not implement these changes that resolve the issue yet? Not sure whether this is helpful but the disk was encrypted with luks1 when using the option of the installer.

10

Yes but were you using the very latest ISO?

And make sure you are not comparing apples and oranges - the content are not the same. There is a marginal difference between the decryption of a device when the system has loaded and decryption when the device is needed to continue.

I build the ISO myself using a default base Manjaro with a custom selection for the desktop.

Perhaps your system is different than mine - for an encrypted system the load time will be longer - my reference system

Machine:
  Type: Laptop System: Notebook product: N14xWU v: N/A
    serial: <superuser required>
  Mobo: Notebook model: N14xWU serial: <superuser required>
    UEFI: American Megatrends v: 1.05.02 date: 03/26/2018
Memory:
  RAM: total: 15.51 GiB used: 1.05 GiB (6.8%)
  RAM Report:
    permissions: Unable to run dmidecode. Root privileges required.
CPU:
  Info: quad core model: Intel Core i7-8550U bits: 64 type: MT MCP cache:
    L2: 1024 KiB
  Speed (MHz): avg: 1029 min/max: 400/4000 cores: 1: 800 2: 800 3: 1860
    4: 1535 5: 841 6: 800 7: 800 8: 800
Graphics:
  Device-1: Intel UHD Graphics 620 driver: i915 v: kernel
  Device-2: Chicony USB2.0 Camera type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 21.1.4 driver: X: loaded: modesetting
    gpu: i915 resolution: 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel UHD Graphics 620 (KBL GT2)
    v: 4.6 Mesa 22.1.3
Drives:
  Local Storage: total: 942.67 GiB used: 11.13 GiB (1.2%)
  ID-1: /dev/nvme0n1 vendor: Samsung model: SSD 970 EVO Plus 500GB
    size: 465.76 GiB
  ID-2: /dev/sda type: USB vendor: Milan model: II 512G size: 476.91 GiB

$ systemd-analyze
Startup finished in 3.931s (firmware) + 57.121s (loader) + 9.547s (kernel) + 2.905s (userspace) = 1min 13.506s 
graphical.target reached after 2.861s in userspace.

A second test gave me - here I was ready to input the passphrase and the result was < 1m

Startup finished in 3.893s (firmware) + 42.386s (loader) + 9.533s (kernel) + 1.764s (userspace) = 57.577s 
graphical.target reached after 1.662s in userspace.
1 Like
11

Hey, thanks again for taking the time! :+1:

were you using the very latest ISO?

I downloaded the cinnamon edition from the manjaro website directly – so supposedly yes?

Anyway, I must have either made a mistake in the manual installation or it is not the same as what Calamares does when you set up the partitions as you mentioned above. → I redid the installation with Calamares as you suggested and lo and behold: Almost instant GRUB menu (as I was used to from before), then very quickly asked for passwort to decrypt root, which then only takes 2 s (I might actually increase the iter-time w/ a new key now :rofl:), and after that just another few s until I am (auto-)logged into my user account.

So thanks a lot again! I will mark your post above as the solution

PS, also @Nachlese, @winnie note that it is the solution to what I asked, so maybe you have some out-of-date info? :grimacing:

12

@Nachlese and @winnie is not using outdated info.

Systemd boot only works when kernels and initrd is stored within the efi partition and that is what our friends suggested.

And that is what I call the long way home - because the manjaro-tools used to build the ISO does not support sd-boot.

With custom partitioning you accomplish the same goal - as end result being the kernel and initrd stored outside the encrypted system.

Whether you decide to take long way home or you decide to use the shortcut (custom partitioning) the result is - measured by functionality - the same - only the colour is different.

13

just in case this was obviously not meant as criticism … i was referring to

But when Manjaro with this setup is your goal - you have a lot of work to do.

which, as it turns out, is not the case… which is great :smiley:

14

That is good to know - and I shall try it out in a VM.
I last tested this more than a year ago
and, probably more importantly,
used Grub as the bootloader, instead of systemd-boot
… not because I have a need for it, just out of habit

15

For future reference - I will do a short write-up in the #contributions:tutorials section on how to achieve this.

16

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.