You are not logged in.
Pages: 1
so i had set up this config
which did not survive reboot(
lvm on luks encrypted root was lvm
cached to nvme device; also lvm on luks..
for total security of course. how can we
keep root cache in plaintext..
apparently grub refused to activate root lvm
coz nvme pe had not been decrypted itself..
even when i uncached root in livecd
it still shared the same vg so i had
to vgsplit the whole thing too..
how can another nvme luks be
decrypted along with the root crypt
device with single passphrase?
or how to figure out any other
similar crypto lvm cached config?
i actually had luks on lvm root
before & didn't like it so anything else.
or should we resort to lvm on luks on lvm..
Last edited by Xelvet (2023-08-25 17:43:03)
Offline
If I understand this correctly, you have 2 LUKS encrypted drives, a fast one and a slow one and you are trying to use GRUB to unlock the LUKS partitions, but as you have already seen, it will only unlock one drive and I don't think GRUB can unlock more then one, you should move the unlocking to initramfs where you can actually unlock multiple encrypted luks devices and then correctly mount the LVM.
Last edited by Project579 (2023-08-23 18:57:00)
Offline
how we can move decrypting to
initramfs with just single pass input?
-- xmm with sd-encrypt we gather..
Last edited by Xelvet (2023-08-24 09:37:27)
Offline
Yes, sd-encrypt will handle the unlocking via the same key for multiple drives, the notes in this section of the wiki explain how to do it: https://wiki.archlinux.org/title/Dm-cry … -generator
Edit:
You can also keep the unlocking via password in GRUB by having an encrypted /boot partition with your password and then putting a keyfile in the initramfs and using that for your encrypted rootfs.
Last edited by Project579 (2023-08-24 21:30:08)
Offline
looks like it did the trick..
the only question remains --
is it possible to lvmcache to
another VG or why not..
Offline
I don't think you can cache to multiple vg unless maybe you partion the fast drive first, I'm not sure about the reason but it seems to be a limitation of the dm-cache kernel implementation, but in the case of multiple cached drive pools (volume groups) I don't think using LVM is the right solution, you should be looking to either use bcache or just change over to a zfs filesystem instead (most common solution).
Offline
Pages: 1