unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Emmanuel Beffara <manu@beffara.org>
To: Roman Scherer <roman.scherer@burningswell.com>
Cc: help-guix@gnu.org
Subject: Re: installation on LVM on LUKS
Date: Fri, 3 Mar 2023 18:03:39 +0100	[thread overview]
Message-ID: <20230303180339.GC2153@beffara.org> (raw)
In-Reply-To: <86o7p9vp6w.fsf@burningswell.com>

Hi Roman,

Thanks for the suggestions.

De Roman Scherer le 03/03/2023 à 16:05:
> did you add the cryptsetup-static and lvm2-static packages to the
> packages field of your operating system?

I had not, but I just tried adding them and nothing changed.

> Apart from that, I think you also need to add the dm-crypt module to the
> initrd-modules field of the of the operating system.

Unless I am missing something, tinkering with initrd modules has nothing to do
with my issue. The missing “insmod lvm” is in grub.cfg, it is related to Grub
modules, not kernel modules. The required modules for Grub are properly
installed in /boot/grub (I mount the EFI partition as /boot), it is just that
the generated configuration file does not load enough of them.

> I'm not sure about your other question, but from what I understand the
> reason why the kernel and the initrd live in the store and not in the
> EFI partition might be that you actually would need to put the kernel
> and the initrd for *each* system generation onto the EFI partition, so
> you can boot different system generations. And that would fill up the
> EFI partition pretty quickly.

Indeed, it would require some space, but it would solve the double-passphrase
issue, among other things.

Besides, storing kernels and initrds in the EFI boot partition is how NixOS
proceeds on my system (although it is set up to use systemd-boot and not Grub,
in case it makes a difference). Filling up the EFI partition has never been a
problem in a few years of use, because the partition is large enough to hold a
few generations (512Mib) and I drop old generations often (as soon as the last
one is checked to be functional, essentially).

-- 
Emmanuel


  reply	other threads:[~2023-03-03 17:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-02 10:25 installation on LVM on LUKS Emmanuel Beffara
2023-03-03 14:33 ` Raffael Mancini
2023-03-03 15:05 ` Roman Scherer
2023-03-03 17:03   ` Emmanuel Beffara [this message]
2023-03-03 23:42     ` wolf
2023-03-05 21:39       ` Emmanuel Beffara

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=20230303180339.GC2153@beffara.org \
    --to=manu@beffara.org \
    --cc=help-guix@gnu.org \
    --cc=roman.scherer@burningswell.com \
    /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).