# How to get dracut to read luks key-file from initramfs?

## msst

So far I am using an unencrypted kernel/initramfs and have the initramfs query for the password to unlock the luks-dmcrypt protected root filesystem. This works.

Now I am trying to ramp this up one step further and have the linux kernel and initramfs reside inside the encrypted rootfs. This is possible thanks to grub2 bootloader, which has some modules to unlock the rootfs as well. And that part works, grub2 asks in its clumsy way for the password and loads kernel/initramfs from the encrypted root. Jay.

But then grub2 closes the rootfs and hands over to the kernel and initramfs, which then asks again for the password. Works also, but is super clumsy and unnecessary.

As grub2 seems to be unable to leave the rootfs open or hand over the password the only obvious solution is to create a rootkeyfile, add this to one of the luks password slots and include this in the initramfs. This is perfectly safe as the initramfs resides inside the encrypted root. So far I managed, I get dracut to include my /etc/rootkey into the initramfs and I learnt about the rd.luks.key=/etc/rootkey kernel command line option for dracut.

Sadly, this does not work. Dracut scans about every %!%!%!%! external device to not find the keyfile on them and does not check its own initramfs where it safely resides. Does anyone know how to force dracut to look at the right place?

By the way, I am not using systemd, so no crypttab / systemd work-arounds will work.

----------

## Roman_Gruber

I had to adapt the initramfs myself.

When you can achieve your task with the bootloaders "rescue" shell, you should be able to adapt an initramfs.

boot up your bootlaoder, check what is accessable at that stage, find a way around it

--

i do not htink its wise to keep the passphrase somewhere on the drive, regardless if its consdiered safe or not

----------

## msst

You mean hacking the dracut scripts? That should do but is very unhandy as one has to redo it every time one regenerates after an update of dracut?

 *Quote:*   

> i do not htink its wise to keep the passphrase somewhere on the drive, regardless if its consdiered safe or not

 

Well the passphrase (in the form of the decrypted key) is always in the ram when the encrypted disk is mounted. And only when the disk is mounted can the keyfile be read, as it is on the encrypted disk and 0400 root readable only. So one has to know the key and have root access to read the keyfile. Then one can also read the key in memory...

----------

## szatox

Well... The very first thing is to find out whether dracut allows you to include some pre-defined script during an automated build. I don't know that, never used dracut. If it does, you may find it very handy.

If it does not... Well, you can start with initramfs generated by dracut. It's a cpio archive, so you can extract it, adjust to your needs and pack again.

Whether you have to rebuild it every time or not depends mostly on your kernel config. Take care to build essential stuff into your kernel. If you do, you will be able to re-use the same initramfs forever. Otherwise... Yes, rebuild it every time you update your kernel.

Versions of dracut itself is not an issue in any case. It creates stuff that helps you boot: if it ain't broken, don't fix it, and if it is broken, don't use it. There is basically no room for improvement in this area beside implementing another corner case

----------

## khayyam

 *Roman_Gruber wrote:*   

> I had to adapt the initramfs myself. When you can achieve your task with the bootloaders "rescue" shell, you should be able to adapt an initramfs.

 

Roman_Gruber ... so, if you've done what the OP is asking then you should provide the solution, but you haven't so the above advice simply amounts to ...

 *Roman_Gruber wrote:*   

> boot up your bootlaoder, check what is accessable at that stage, find a way around it

 

... "fix it", which of course is of no help whatsoever, as the OP knows there is a problem, what they are looking for is a solution (or at minimum some pointer toward that solution).  

 *Roman_Gruber wrote:*   

> i do not htink its wise to keep the passphrase somewhere on the drive, regardless if its consdiered safe or not

 

Yes, because storing a key/passphrase on a luks encrypted volume is unwise ... because?

best ... khay

----------

## L29Ah

Add ":/" to your rd.luks.key to tell dracut it needs to look for the key file on the initramfs itself.

----------

## finalturismo

 *L29Ah wrote:*   

> Add ":/" to your rd.luks.key to tell dracut it needs to look for the key file on the initramfs itself.

 

You mean add to kernel parameter or the key file it self?

----------

## DespLock

 *Quote:*   

> You mean add to kernel parameter or the key file it self?

 

Kernel parameter. 

```
rd.luks.key=/etc/rootkey:/
```

Assuming you have incldued your key file like this in dracut

```
install_items+=" /etc/rootkey "
```

EDIT: Make sure only root can read and/or write the keyfile and the initram.

----------

