[Tutorial] Convert to systemd-boot

[Echoa]

@dalto Im trying this out, how are the kernel command line options discovered? It seems to have properly added all the ones i want but is there a specific conf file for it? Is it using the one from the old sdboot-manage? Ive been looking through the git trying to find it

edit: found it in /etc/kernel/cmdline

[dalto]

@Echoa

how are the kernel command line options discovered? It seems to have properly added all the ones i want but is there a specific conf file for it?

It first looks for /etc/kernel/cmdline, if it doesn’t exist, it takes the parameters from the running kernel. In this case, it took your running parameters and then the hook wrote /etc/kernel/cmdline. The reason I am writing that file is so that if you need to rescue your system in a chroot, you don’t usually want the kernel options currently in-use.

[josh4trunks]

This tutorial using the “kernel-install” worked perfectly for me on a fresh EndeavourOS installation!

But this is what confuses me…
I enabled whole partition encryption during installation. So initially I had to enter my encryption passphrase into grub during bootup. This makes sense to me, since grub needs to decrypt /root to get to the login screen.

But, now that I followed this tutorial, a computer boot goes straight to my login screen (GDM). Checking disk-utility shows my disk is still encrypted. How is this possible? I’m worried this somehow stored the disk decryption key on the EFI partition.

Thank you

[dalto]

@josh4trunks

I’m worried this somehow stored the disk decryption key on the EFI partition.

It did. By default there is a keyfile in the initramfs. With systemd-boot, the initramfs is now in the ESP.

Someone else noticed this in the last couple of days and I was planning to put a disclaimer in the instructions but haven’t had a chance to do that. For now, here is how you can remove the keyfile from your initramfs.

Carefully follow the following steps:

• Edit /etc/mkinitcpio.conf and remove /crypto_keyfile.bin from the files section.
• Rebuild your initramfs with sudo mkinitcpio -P
• Reboot and make sure everything is still working. You should get asked for your password.

If you no longer need the keyfile at all, you can remove it completely. Be aware, if you have more than one luks partition, removing this keyfile may cause you to be asked for your password more than once.

• Assuming it is, you can optionally remove the key and keyfile
• Use cryptsetup to delete the key from the luks partition

  sudo cryptsetup luksRemoveKey /dev/sdxy /crypto_keyfile.bin 
  

  Replace /dev/sdxy with the partition you have luks installed on.
• Delete the keyfile from the disk - sudo rm /crypto_keyfile.bin

While I have done this a couple of times without issue, keep in mind that whenever you mess around with your luks partition you run the risk of locking yourself out so it is wise to have a backup.

[josh4trunks]

Thanks it worked!

[josh4trunks]

So another LUKS related question. I was hoping to enable TRIM on my NVMe SSD, which is apparently disabled by default on LUKS partitions.

https://confluence.jaytaala.com/display/TKB/Enable+periodic+TRIM+-+including+on+a+LUKS+partition

How would I go about adding the below using the kernel-install method…
:allow-discards to the end of the cryptdevice argument?
rd.luks.options=discard as a kernel parameter?

My guess is have the following in /etc/kernel/cmdline? But I was hoping to ask first before bricking my laptop. Thanks!
cryptdevice=UUID=:allow-discards
rd.luks.options=discard

[dalto]

I have a couple of appointments this morning and I will write a more thorough response later which includes how to test a change like that but the short answer is, “yes”, modifying /etc/kernel/cmdline will work.

[josh4trunks]

Great, I’m seeing that I can add persistent flags to my cryptdevice (which is what I would prefer). So trying to go down that route to add “allow-discards”. So at this point my issue is pretty for off topic… But I would still love some help either here or on another thread.
I’m trying cryptsetup --allow-discards --persistent refresh root which is documented here. But am getting the error Device root is not active.

I assume rd.luks.options=discard will just work as expected in /etc/kernel/cmdline.

[dalto]

@josh4trunks

I’m trying cryptsetup --allow-discards --persistent refresh root which is documented here. But am getting the error Device root is not active.

You need to use the name of the luksdevice. root was just an example.

[josh4trunks]

I think I figured that part out, lol. Now my issue is…

This operation is supported only for LUKS2 device. Device activated but cannot make flags persistent.

Those sentences are on different lines. I’m not sure if the first line is just a general statement or is saying my device is LUKS1? Also not sure if the two lines are related.

[dalto]

You might want to post a separate topic for this. I am not really a luks expert and I am not sure the people who are would be reading this topic.

[dalto]

I updated the first post with a description of how kenrel-install works and specific guidance on how to change the kernel options.

[josh4trunks]

Thanks, I gave up for now on trying to make my changes persistent to the LUKS partition (since I believe it is LUKS1). I just edited my entries files, rebooted, and “fstrim” is working as expected now.

My understanding, based on what you wrote is any future kernel installs will pickup the running parameters so in a way my edits are persistent.

[dalto]

@josh4trunks

My understanding, based on what you wrote is any future kernel installs will pickup the running parameters so in a way my edits are persistent.

If you used the manual method that is true. If you used the kernel-install method you should also delete /etc/kernel/cmdline and let it be regenerated.

[Feakster]

@dalto

title   EndeavourOS 
linux   /vmlinuz-linux 
initrd  /initramfs-linux.img 
options root=UUID=5aa3e4e1-7e37-4bd6-95ce-7324a040785b rw loglevel=3 nowatchdog 

If one wanted to turn off the CPU mitigations, would mitigations=off go in the options line?

[dalto]

@Feakster

would mitigations=off go in the options line?

Yes.

Keep in mind, that is meant to be an example, you shouldn’t copy it verbatim unless through some bizarre cosmic coincidence you happen to have the same UUID for your root volume as I do.

[manyroads]

I probably missed this but is there an easy way to declare or establish a default kernel by either use or selection? I seem to recall reading that precedence is established by kernel install sequence (not last use as you can do in grub).

[dalto]

@manyroads

I probably missed this but is there an easy way to declare or establish a default kernel by either use or selection?

I don’t know that there is a perfect solution but there are couple of things you can do to get close

• When you are booting you can select the one you to be the default and press the d key.
• The default entry in loader.conf supports wild cards so you can usually get close by creative naming or use of wild cards. As an example, if I want to always boot the latest LTS kernel, I can do something like *lts.conf

@manyroads

I seem to recall reading that precedence is established by kernel install sequence (not last use as you can do in grub).

I think precedence is set via an alpha sort of the entry files with Windows and the Firmware options at the bottom.

[manyroads]

@dalto Thank you… the ‘d’ did the trick for me.

[SirAsker]

By the way, would this method also work with other Arch-based distros, or is this tutorial only for EndeavourOS?