unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Thomas Albers <tgalbers2000@gmail.com>
To: help-guix@gnu.org
Subject: Typing LUKS passphrase only once and a possible solution
Date: Wed, 07 Jul 2021 18:05:44 +0200	[thread overview]
Message-ID: <87k0m2gld3.fsf@gmail.com> (raw)

Hello everyone,

I recently installed guix on my X200T and through the process I found
some challenges I was not not solve by myself. Its nothing strictly
necessary but I would like to solve them nonetheless.

My current setup consists of libreboot, my main luks partition and a
lvm group inside.

The problem I mentioned is the necessity of typing the passphrase for
the luks device twice. Once for the bootloader and again for the
kernel itself.

In other distributions this is avoided by copying a key file into the
initramfs and passing the kernel parameter "cryptkey" to linux. So
naturally the first I tried after not finding any documentation on
this topic was this, albeit without success.

Reading the relevant files (gnu system linux-initrd) and
(gnu system mapped-devices) I noticed that the kernel parameter is not
really needed, because the one decrypting the luks device is actually
the init script inside the initramfs.

So the question would be: Is it possible to add arguments to the call
to cryptsetup inside the init script without having to redefine the
"luks-device-mapping" variable and without rewriting the definition of
the "open-luks-device" function? - both defined locally inside the
(gnu system mapped-devices) module.

My suggestion would be to add a "extra-options" field to
<mapped-device> structure. This field would be appended to the command
line arguments to the cryptsetup call.

One could also add a "keyfile" parameter but this would be too
specific to the luks device mapper and it would also cause other
problems as well. For example, not everyone would like to store the
keyfile inside the store.

Also, is it possible to modify existing code for such small changes,
without needing to rewrite complete functions? Many of the functions
used are not exposed by the modules and one needs to rewrite the
function one wants to use and also its dependencies.

My last question would be: Why is the file called initrd, when in
reality a initramfs scheme is used?

Thanks for taking the time to read this and for any help you can
provide.

Thomas Albers Raviola


             reply	other threads:[~2021-07-07 16:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-07 16:05 Thomas Albers [this message]
2021-07-07 16:42 ` Typing LUKS passphrase only once and a possible solution Tobias Geerinckx-Rice
2021-07-07 18:29   ` Thomas Albers
2021-07-08 17:29     ` Vagrant Cascadian
2021-07-07 18:12 ` Joshua Branson
2021-07-07 18:30   ` Wiktor Żelazny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k0m2gld3.fsf@gmail.com \
    --to=tgalbers2000@gmail.com \
    --cc=help-guix@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).