[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LVM passphrase



On Tue, 28 Dec 2021 at 21:06, Pierre-Elliott Bécue <peb@debian.org> wrote:
> Polyna-Maude Racicot-Summerside <debian@polynamaude.com> wrote on 28/12/2021 at 07:39:16+0100:

> > I got two logical volume on my hard disk.
> > One is the swap
> > Other is the root
> > Both have the same passphrase.
> > How can I make grub ask only once ?

> First, for the sake of clarity, I guess you are talking about LUKS
> filesystems on logical volumes?
>
> If so, I guess you're not dealing with grub but with initramfs scripts
> and then init asking for passphrases. Indeed, GRUB only asks the
> passphrase of a potential encrypted /boot to fetch its configuration in
> order to know what to boot.
>
> Now let's move to the initramfs + init passphrases prompts. Initramfs'
> job is to find the root partition and "pivot" on it, ie exec /sbin/init
> which is located on the root partition and which will mount the other
> filesystems, start services, … you know the drill.
>
> To find the root partition, initramfs has a lot of helper scripts, and
> if the root partition is encrypted, it also has access to cryptsetup
> binaries and passfifo. It therefore prompts for a password to recrypt
> your rootfs.
>
> Later on, init wants to make your swap available and therefore also
> needs to ask you for a passphrase.

I am not clear exactly what is being asked here. Is the question
about Grub asking for passwords, or about the initrd asking
for passwords? Grub will ask before booting the kernel, the
initrd will ask after Grub invokes the kernel.

I don't know about Grub asking for passwords, because I don't
encrypt boot partitions. But if the question is about the initrd
password prompt, then ...

If we are talking about somehow using both LVM and LUKS
in combination, then decrypting a single LUKS volume that
has been partitioned into root and swap with LVM will only
require one password given once to the init started by the
initrd, when booting the system.

Maybe providing the output of 'lsblk -f' would help to clarify
the situation, so that we can see what is on the disk.


Reply to: