all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Emmanuel Beffara <manu@beffara.org>
To: wolf <wolf@wolfsden.cz>
Cc: Roman Scherer <roman.scherer@burningswell.com>, help-guix@gnu.org
Subject: Re: installation on LVM on LUKS
Date: Sun, 5 Mar 2023 22:39:56 +0100	[thread overview]
Message-ID: <20230305223956.GB1967@beffara.org> (raw)
In-Reply-To: <ZAKF889Ies76aV32@ws>

De wolf le 04/03/2023 à 00:42:
> On 2023-03-03 18:03:39 +0100, Emmanuel Beffara wrote:
> > 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.
> 
> Maybe that is the problem? For me it works out of the box, but I have EFI
> mounted as /boot/efi. Could you maybe either try to do that as well,

I just tried that: mounting the EFI partition in /boot/efi instead of /boot
and adujsting the config.scm accordingly (the entry for /boot/efi in
file-systems and the target for grub). I also cleaned everything there that
was installed by Guix (the Guix folder, the grub folder). Turns out that this
way, the system just cannot start. In the EFI partition, there is
EFI/Guix/grubx64.efi but running this leads to an error:

	error: disk 'lvmid/(the UUID of the root fs)' not found.
	Entering rescue mode...

I cannot do much in this recue mode. Of course Grub cannot find the partition
since its modules for LUKS and LVM are now stored in the system's root
partition under /boot, encrypted…

I'm surprised that it works for you out of the box given what I observe. Where
are Grub's modules stored ? Is the installed EFI binary somehow able to
decrypt the partition and its LVM contents without loading modules for that ?

> or (untested idea I just had) provide (dependencies mapped-devices) for the
> /boot mount point as well (I know, it is not technically required)?

I also tried that and it does not change anything.

> I am using 64M EFI partition, so I could imagine that filling up, especially if
> one does not clean up the generations very often. Since increasing the EFI size
> could be impossible without reinstall, if this is done, it should likely be
> opt-in only.

Certainly.

-- 
Emmanuel


      reply	other threads:[~2023-03-05 21:40 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
2023-03-03 23:42     ` wolf
2023-03-05 21:39       ` Emmanuel Beffara [this message]

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

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

  git send-email \
    --in-reply-to=20230305223956.GB1967@beffara.org \
    --to=manu@beffara.org \
    --cc=help-guix@gnu.org \
    --cc=roman.scherer@burningswell.com \
    --cc=wolf@wolfsden.cz \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.