Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED]Custom Initramfs: /dev not populated,LUKS encryption
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Sat Dec 04, 2021 12:27 pm    Post subject: [SOLVED]Custom Initramfs: /dev not populated,LUKS encryption Reply with quote

Hello everyone

I use LVM on LUKS full-disk encryption on my Gentoo machine. Until now, I used the kernel and initramfs generated by genkernel. Now I'd like to have a custom initramfs, and if that's working, a custom kernel. I followed the instructions at the wiki.

My problem is that in initramfs, /dev seems not to be fully populated. There are numerous /tty's, random, urandom, console and basic stuff like that, but there are no disks showing up. Therefore, cryptsetup fails to open the LUKS container. I tried specifying /dev/nvme0n1p2 (my encrypted root partition) and findfs with UUID, as suggested in the wiki. I also tried to manually re-mount /dev, /proc, and /sys in the rescue shell, that doesn't help. I use busybox.

I am not sure if I understand what mdev is for. I see that it is busybox version of udev, so it is needed to populate /dev. But it is a replacement for devtmpfs or do I still need it? I have tried with and without
Code:
 
echo /sbin/mdev > /proc/sys/kernel/hotplug
mdev -s

but no luck. If I run this command manually, it returns an error saying that /proc/sys/kernel/hotplug does not exist.

How can I make the disks show up in /dev in my initramfs, so cryptsetup can unlock them?

My current kernel version is: 5.10.76, I also tried with my fallback setup with kernel 5.10.61.

This is my init script:
Code:

#!/bin/busybox sh

# Based on https://wiki.gentoo.org/wiki/Custom_Initramfs

LINE="************************************************************************************"

rescue_shell () {
   echo "${LINE}"
   echo "You messed up. Dropping shell..."
   echo "${LINE}"
   busybox --install -s
   exec /bin/sh
}

echo "Initramfs started."
uname -r
echo "${LINE}"

echo "Preparing pseudo filesystems..."
mount -t devtmpfs none /dev
mount -t proc none /proc
mount -t sysfs none /sys
 
echo /sbin/mdev > /proc/sys/kernel/hotplug
mdev -s

echo "Changing keymap..."
loadkmap < keymap.bmap

echo "Opening encrypted device..."
cryptsetup luksOpen /dev/nvme0n1p2 volgroup-root || rescue_shell

lvm vgscan --mknodes
lvm lvchange -a ly volgroup/root
lvm vgscan --mknodes

echo "Mounting root..."
mount -o ro $(findfs UUID=dd25cec6-beaa-4109-ab6b-e3e80e37f317) /mnt/root || rescue_shell

umount /proc
umount /sys
umount /dev

echo "All done."
exec switch_root /mnt/root /sbin/init


And I use this script to generate the initramfs:
Code:

#!/bin/bash

# Script to automate initramfs generation

INITRAMFS_NAME="custom-initramfs"
INITRAMFS_DIR="/usr/src/initramfs"

# Check if root
if [[ "$EUID" > 0 ]]; then
   echo "You must be root."
   exit
fi

# Check if /boot is mounted
printf "Checking if /boot is mounted..."
if [[ `df | grep -s "/boot"` ]]; then
   echo "yes."
else
   echo "no."
   echo "Please mount /boot"
   exit
fi

# Assuming initramfs working dir is /usr/src/initramfs
# Checking if that exists
printf "Checking if ${INITRAMFS_DIR} exists..."
test -s ${INITRAMFS_DIR}
if [[ $? -eq 0 ]]; then
   echo "yes."
else
   echo "no. Create initramfs structure at this location."
   exit
fi

# Compress initramfs and move it to /boot
# It is named after the kernel-release
# I modified GRUB config so it uses initramfs for a
# kernel if it has the same name
echo "Generating cpio and compressing initramfs..."
version=$(uname --kernel-release)
cd ${INITRAMFS_DIR}
find . -print0 | cpio --null --create --verbose --format=newc | gzip --best > /boot/${INITRAMFS_NAME}-${version}.cpio.gz
echo "Done copying ${INITRAMFS_NAME}-${version}.cpio.gz to /boot."
cd

# Update GRUB config
grub-mkconfig -o /boot/grub/grub.cfg

echo -e "\e[31mCheck above if correct initramfs was used for each kernel version!\e[0m"
echo "Maybe you also want to delete old ones."


Thanks for your help!


Last edited by regox on Thu Dec 09, 2021 3:36 pm; edited 1 time in total
Back to top
View user's profile Send private message
pingtoo
l33t
l33t


Joined: 10 Sep 2021
Posts: 887
Location: Richmond Hill, Canada

PostPosted: Sat Dec 04, 2021 12:52 pm    Post subject: Reply with quote

@regox

I suspect you missing necessary kernel modules for your devices. How you populate /usr/src/initramfs?

In your initramfs rescue shell you should be able use dmesg to see what kernel report, may be share the dmesg. hopefully we ca spot something.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54098
Location: 56N 3W

PostPosted: Sat Dec 04, 2021 12:53 pm    Post subject: Reply with quote

regox,

You are trying to cross a chasm in two smaller jumps.

The genkernel kernel is a fully modular kernel, so if you want nvme nodes to show in /dev the kernel module/w must be included in the initrd and the initrd init script must load them.
That's why its not working as is.

Consider the alternative approach. Make your custom kernel now that has everything built into the kernel that the kernel needs to mount root.
Then the initrd does not need any kernel modules to get started. You can still use modules but they will be loaded from /lib/modules after root is mounted.

You can still use a genkernel made kernel but you will need to use the menuconfig option to flip things from <M> to <Y>.
genkernel can use a custom config file too, so you don't have to get its right first time.

The kernel and initrd should not be considered as separate stages until the initrd does not need any kernel modules to do its thing.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
spica
Apprentice
Apprentice


Joined: 04 Jun 2021
Posts: 282

PostPosted: Sat Dec 04, 2021 1:33 pm    Post subject: Reply with quote

regox,
I compared with my scripts, the only difference is you call mdev – this is not needed. I agree with pingtoo and Neddy, nvme drivers + crypto stuff must be compiled into kernel.
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Sun Dec 05, 2021 12:45 am    Post subject: Reply with quote

Thank you all for your help.

I started to modify my kernel config so I can modify what is a module and what is built in.
I added NVMe drivers (made drives show up), DM_CRYPT, everything recommended for LVM and crypto stuff.
My complete config can be found here.

I removed "mdev" as suggested from my init script.

In my initrd, cryptsetup does prompt me now for a passphrase, but then fails with "Keyslot open failed."
I re-ran the command with --verbose and --debug flags to get more insight.

(After entering the passphrase)
Code:

...
Detected dm-ioctl version 4.43.0.
Detected dm-integrity version 1.6.0.
Detected dm-crypt version 1.22.0
Device-mapper backend running with UDEV support disabled
dm status cryptroot [ opencount noflush ]   [16384] (*1)
Keyslot 0 priority 1 != 2 (required), skipped.
Trying to open LUKS2 keyslot 0.
Reading keyslot area [0x8000].
Acquiring read lock for device /dev/nvme0n1p2.
Opening lock resource file /run/cryptsetup/L_259:2
Verifying lock handle for /dev/nvme0n1p2.
Device /dev/nvme0n1p2 READ lock taken.
Reusing open ro fd on device  /dev/nvme0n1p2
Device /dev/nvme0n1p2 READ lock released.
Keyslot 0 (luks2) open failed with -22.[/quote]
Keyslot open failed.
...


So I guess something is still missing(?). Someone have an idea what that could be?
dmesg also does not show anything interesting.
Back to top
View user's profile Send private message
pingtoo
l33t
l33t


Joined: 10 Sep 2021
Posts: 887
Location: Richmond Hill, Canada

PostPosted: Sun Dec 05, 2021 7:35 pm    Post subject: Reply with quote

What does luksdump said?
Code:
sh# cryptsetup luksDump /dev/nvme0n1p2 --verbose --debug
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Mon Dec 06, 2021 7:56 pm    Post subject: Reply with quote

pingtoo wrote:
What does luksdump said?
Code:
sh# cryptsetup luksDump /dev/nvme0n1p2 --verbose --debug

Code:

# cryptsetup 2.3.6 processing "cryptsetup luksDump /dev/nvme0n1p2 --verbose --debug"
# Running command luksDump.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/nvme0n1p2.
# Trying to open and read device /dev/nvme0n1p2 with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/nvme0n1p2.
# Crypto backend (Linux 5.10.76-gentoo-r1-x86_64 kernel cryptoAPI) initialized in cryptsetup library version 2.3.6.
# Detected kernel Linux 5.10.76-gentoo-r1-x86_64 x86_64.
# Loading LUKS2 header (repair disabled).
# Acquiring read lock for device /dev/nvme0n1p2.
# Opening lock resource file /run/cryptsetup/L_259:2
# Verifying lock handle for /dev/nvme0n1p2.
# Device /dev/nvme0n1p2 READ lock taken.
# Trying to read primary LUKS2 header at offset 0x0.
# Opening locked device /dev/nvme0n1p2
# Veryfing locked device handle (bdev)
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:21f6a375e5fbb6390c5ac840c770f0406f01a72d30188767b1e6e9ce69971d74 (on-disk)
# Checksum:21f6a375e5fbb6390c5ac840c770f0406f01a72d30188767b1e6e9ce69971d74 (in-memory)
# Trying to read secondary LUKS2 header at offset 0x4000.
# Reusing open ro fd on device /dev/nvme0n1p2
# LUKS2 header version 2 of size 16384 bytes, checksum sha256.
# Checksum:7515b9ac2bf471c4f0699508d3cb0d55b45d0f8487cc609abbce5a5a5595ca9c (on-disk)
# Checksum:7515b9ac2bf471c4f0699508d3cb0d55b45d0f8487cc609abbce5a5a5595ca9c (in-memory)
# Device size 1023940042240, offset 16777216.
# Device /dev/nvme0n1p2 READ lock released.
# PBKDF argon2i, time_ms 2000 (iterations 0), max_memory_kb 1048576, parallel_threads 4.
LUKS header information
Version:          2
Epoch:            3
Metadata area:    16384 [bytes]
Keyslots area:    16744448 [bytes]
UUID:             0a094fef-7708-41c2-8e96-649bfc5a2637
Label:            (no label)
Subsystem:        (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
   offset: 16777216 [bytes]
   length: (whole device)
   cipher: aes-xts-plain64
   sector: 512 [bytes]

Keyslots:
  0: luks2
   Key:        512 bits
   Priority:   normal
   Cipher:     aes-xts-plain64
   Cipher key: 512 bits
   PBKDF:      argon2i
   Time cost:  15
   Memory:     1048576
   Threads:    4
   Salt:       ab 27 b4 9f f2 60 98 17 3d 72 05 fd 58 07 37 f0
               76 78 94 a6 86 f2 5b 90 05 e5 b3 36 db e3 d5 c0
   AF stripes: 4000
   AF hash:    WHIRLPOOL
   Area offset:32768 [bytes]
   Area length:258048 [bytes]
   Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
   Hash:       WHIRLPOOL
   Iterations: 93489
   Salt:       9b 81 13 b5 29 e4 83 2c 45 f5 56 84 00 e9 9b de
               5f 64 8f 36 11 0d 28 e8 44 d7 c8 c9 74 5e 08 3b
   Digest:     3c 1d 9e d7 48 4c 3d 4e 06 5e 6a 4f 43 d7 ac f0
               8d 5e d3 33 55 b6 59 ec 0c a9 82 b7 e7 60 f5 7b
               0f f4 2a 25 0c d6 7d b9 b7 10 8f 9a 2a 9d b5 bc
               68 b3 40 d3 9f 1d 53 bd b3 5d ba 55 70 73 8d 6a
# Releasing crypt device /dev/nvme0n1p2 context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/nvme0n1p2.
# Unlocking memory.
Command successful.
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Mon Dec 06, 2021 8:16 pm    Post subject: Reply with quote

...and the output of dmesg is here
Back to top
View user's profile Send private message
wless123
n00b
n00b


Joined: 27 Aug 2021
Posts: 35

PostPosted: Mon Dec 06, 2021 8:57 pm    Post subject: Reply with quote

Two things that comes in mind:

1) Is your keymap correct?

It has to be binary
Code:
loadkeys -b /your/key.map > key.bmap

You can check it by entering a rescue shell in initram and type your password for that device.

2) Do you have all needed Cryptographic options set to "Y" in the kernel?

esp. CONFIG_CRYPTO_WP512 is needed for whirlpool

Other options can be found here: https://wiki.gentoo.org/wiki/Dm-crypt
They all needed to be compiled into the kernel.
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Mon Dec 06, 2021 9:37 pm    Post subject: Reply with quote

wless123 wrote:

1) Is your keymap correct?
2) Do you have all needed Cryptographic options set to "Y" in the kernel?
esp. CONFIG_CRYPTO_WP512 is needed for whirlpool

Other options can be found here: https://wiki.gentoo.org/wiki/Dm-crypt
They all needed to be compiled into the kernel.


Yes, the keymap seems to be the correct one in the rescue shell.

Yes I do have CONFIG_CRYPTO_WP512=y, as you can see in my config.
When I initially configured the kernel I also checked the Dm-crypt article, so that should be checked as well.
Back to top
View user's profile Send private message
spica
Apprentice
Apprentice


Joined: 04 Jun 2021
Posts: 282

PostPosted: Tue Dec 07, 2021 7:56 am    Post subject: Reply with quote

regox,
Show please
Code:
emerge -pv cryptsetup
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Tue Dec 07, 2021 11:31 am    Post subject: Reply with quote

spica wrote:
regox,
Show please
Code:
emerge -pv cryptsetup

Code:

[ebuild   R    ] sys-fs/cryptsetup-2.3.6-r2:0/12::gentoo  USE="argon2 kernel nls static -gcrypt -nettle -openssl -pwquality -reencrypt -static-libs -udev -urandom" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB
Back to top
View user's profile Send private message
pingtoo
l33t
l33t


Joined: 10 Sep 2021
Posts: 887
Location: Richmond Hill, Canada

PostPosted: Tue Dec 07, 2021 2:44 pm    Post subject: Reply with quote

I am no expert on LUKS so I am guessing.

From what I got on internet, your encryption setting seems to be OK, I can only guess somehow you enter a wrong password.

However I am wondering could it be you actually successfully decrypt and create the device but failed in lvm setup.

Your code
Code:
echo "Opening encrypted device..."
cryptsetup luksOpen /dev/nvme0n1p2 volgroup-root || rescue_shell

lvm vgscan --mknodes
lvm lvchange -a ly volgroup/root
lvm vgscan --mknodes

will create a device node name: /dev/mapper/volgroup-root

Let's assume decrypt successful, try
Code:
root# ls /dev/mapper
root# blkid
What's output?

Also just in case post output of
Code:
root# cat /proc/crypto
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54098
Location: 56N 3W

PostPosted: Tue Dec 07, 2021 4:35 pm    Post subject: Reply with quote

regox,

Now that pingtoo has drawn my attention to it,
Code:
lvm vgscan --mknodes
lvm lvchange -a ly volgroup/root
lvm vgscan --mknodes
looks a bit odd.


The
Code:
lvm vgscan --mknodes
should not be required. Its free with
Code:
lvm lvchange -ay

That scans and activates all volume groups
When you give
Code:
volgroup/root
only the volume group named volgroup/root will be activated. Thats an odd name for a volume group, with a / in it.

Try just
Code:
lvm lvchange -ay


When you have it in rescue mode what does
Code:
vgdisplay | grep Name
tell?
$ sudo vgdisplay | grep Name
VG Name storage
VG Name nvmestatic
Likewise
Code:
lvdisplay | grep Name


What I'm getting at is that you activate entire volume groups and use the logical volumes within. In my case
Code:
ls /dev/mapper/
control  nvmestatic-local  nvmestatic-opt  nvmestatic-portage  nvmestatic-root  nvmestatic-usr  nvmestatic-var  storage-distfiles  storage-home  storage-packages


I have a VG called nvmestatic ond another called storage, as shown above.
They each contain a number of logical volumes.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Tue Dec 07, 2021 8:44 pm    Post subject: Reply with quote

pingtoo wrote:

Your code
Code:
echo "Opening encrypted device..."
cryptsetup luksOpen /dev/nvme0n1p2 volgroup-root || rescue_shell

lvm vgscan --mknodes
lvm lvchange -a ly volgroup/root
lvm vgscan --mknodes

will create a device node name: /dev/mapper/volgroup-root

Yes, this was intentional. After booting with the genkernel-generated initramfs, the volume group is also named volgroup-root.

pingtoo wrote:

Let's assume decrypt successful, try
Code:
root# ls /dev/mapper
root# blkid
What's output?

Code:

control

pingtoo wrote:

Also just in case post output of
Code:
root# cat /proc/crypto

This is quite long, so I put it here.

NeddySeagoon wrote:

Now that pingtoo has drawn my attention to it,
Code:

lvm vgscan --mknodes
lvm lvchange -a ly volgroup/root
lvm vgscan --mknodes   

looks a bit odd.

I got this from here: https://wiki.gentoo.org/wiki/Custom_Initramfs#LVM

I tried it without lvm vgscan --mknodes, but it makes no apparent difference.

NeddySeagoon wrote:

only the volume group named volgroup/root will be activated. Thats an odd name for a volume group, with a / in it.

Actually I thought that was supposed to be that way, so the volume group will be named volgroup-root (again, got this from the above Wiki entry).

NeddySeagoon wrote:

When you have it in rescue mode what does
Code:

vgdisplay | grep Name   

tell?

I would need to get vgdisplay and lvdisplay in the initramfs first, because currently they are not included. Should I do that?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54098
Location: 56N 3W

PostPosted: Tue Dec 07, 2021 9:03 pm    Post subject: Reply with quote

regox,

I was more interested in what it said once you knew that it was properly decrypted.
Hence do the test on the boot media.

From the way you call lvchange, you have all of lvm there.
I suspect that
Code:
lvm vgdisplay
and friends all work.

There are two ways you can put this together. Both work but it has to be done in the right order.
It looks like you have a partition with an encrypted container that once unlocked, shows you a LVM VG.
The other nesting works too.
LVM on the partition then encrypt the logical volumes separately. Passiblf bint different pass phrases, keys etc.
The first way is more popular as there is only once container to unlock.

Do you have a race somewhere and you are trying
Code:
vgchange -ay
before the crypto has done its thing?
If so,
Code:
vgchange -ay
by hand in the rescue shell would work.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Tue Dec 07, 2021 10:58 pm    Post subject: Reply with quote

NeddySeagoon,

thanks for your reply. To be honest I was a bit confused how that whole LVM thing works. When I set up the machine I just followed the Gentoo and Arch Wikis to have "LVM on LUKS".
I used the dolvm kernel parameter and everything was working fine. As you say, I have a LUKS encrypted partition that, once unlocked, presents a LVM VG. That volume group contains one logical volume called root.

I now removed all kernel parameters except for a keymap one and booted from the genkernel-generated kernel and initramfs to do the LVM stuff manually once to understand better what is going on when the disk is unlocked.

From this I learned that my init script has to be changed to
Code:

cryptsetup luksOpen /dev/nvme0n1p2 volgroup
...
lvm lvchange -ay /dev/mapper/volgroup

This will open the logical volume volgroup-root. I think I get it now.
This means I have to correct myself from a previous post: The volume group is called volgroup, and its logical volume is then called root, making it appear as volgroup-root

It makes sense now why NeddySeagoon and pingtoo were confused about my naming, because I was using it incorrectly. Sorry for the confusion.

Anyway, unfortunately my LUKS container still can't be opened (no kernel parameters, "new" init script with commands shown above). It still gives me "Keyslot open failed". I think this leads to the conclusion that the decryption itself is at fault, not LVM right?
Back to top
View user's profile Send private message
pingtoo
l33t
l33t


Joined: 10 Sep 2021
Posts: 887
Location: Richmond Hill, Canada

PostPosted: Tue Dec 07, 2021 11:17 pm    Post subject: Reply with quote

regox wrote:
pingtoo wrote:

Your code
Code:
echo "Opening encrypted device..."
cryptsetup luksOpen /dev/nvme0n1p2 volgroup-root || rescue_shell

lvm vgscan --mknodes
lvm lvchange -a ly volgroup/root
lvm vgscan --mknodes

will create a device node name: /dev/mapper/volgroup-root

Yes, this was intentional. After booting with the genkernel-generated initramfs, the volume group is also named volgroup-root.

Actually you don't have volume group yet, what you got is a dm (device mapper) device. I am sorry I did not made it clear in my previous post.

regox wrote:
pingtoo wrote:

Let's assume decrypt successful, try
Code:
root# ls /dev/mapper
root# blkid
What's output?

Code:

control

I was hoping blkid would produce something but since /dev/mapper only content control is unlikely we will get any luck :(

Since we don't have the decrypted dm device yet, there is no point investigate all those lvm steps.

Here are I got from LUKS FAQ
Quote:
PASSPHRASE CHARACTER SET: Some people have had difficulties with this
when upgrading distributions. It is highly advisable to only use the 95
printable characters from the first 128 characters of the ASCII table,
as they will always have the same binary representation. Other
characters may have different encoding depending on system configuration
and your passphrase will not work with a different encoding. A table of
the standardized first 128 ASCII characters can, e.g. be found on
https://en.wikipedia.org/wiki/ASCII


I think before we going any further I suggest backup :D See FAQ 6. Backup and Data Recovery

Another Suggest I saw on net is use boot CD to get a proper environment up first, than try out manual steps to verify LUKS key slot is not corrupted.

Good luck!
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Wed Dec 08, 2021 10:16 am    Post subject: Reply with quote

Thanks for your reply pingtoo.

I do actually have a running environment, I am jumping back and forth (in GRUB) between an older kernel version with an initramfs genkernel created (that is working fine, I am typing on this system now) and my "experimental" setup with a newer kernel and this custom initramfs I am working on. From this I also know that the LUKS keyslot is fine, because I can unlock and boot from it with the genkernel-generated kernel/initrd.

The password also contains only A-Z and 0-9, nothing fancy. Normally I use QWERTZ layout, but I also tried to switch all Z's and Y's when entering the password, just in case it uses a QWERTY layout for some reason.

I also support making extensive backups :D Recent full-disk and separate data backups are available in case something goes terribly wrong.

Cheers
Back to top
View user's profile Send private message
pingtoo
l33t
l33t


Joined: 10 Sep 2021
Posts: 887
Location: Richmond Hill, Canada

PostPosted: Wed Dec 08, 2021 4:12 pm    Post subject: Reply with quote

regox, Thanks for conformation. I was worry I will provide wrong idea and cause major headaches :)

So if my understand is correct you actually can use same password for older kernel/initramfs pair to open /dev/nvme0n1p2? If I am correct I would like to suggest a experiment.

I still holding the idea that somehow in your new initramfs's rescue shell your input generate different password than while you in old kernel/initramfs pair.

Yesterday I was reading man page for cryptsetup I notice it have an option --key-file to allow passphrase read from a file. So I think if you can use the working system to create a keyfile with the passphrase in the it, then transfer the keyfile to your initramfs build tree, rebuild a new initramfs with the keyfile in it. Use this new initramfs to boot. Once you in rescue shell, Use the --key-file to see if that will open /dev/nvme0n1p2. The main idea here is that by using the known working system generated passphrase to open the encrypted device so no keyboard involve.

In the mean time I will read more about LUKS/cryptsetup.
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Wed Dec 08, 2021 4:38 pm    Post subject: Reply with quote

Thanks for the suggestion. Yes, that seems like a good idea.

I created a keyfile at /boot/key and then tried on the running system
Code:

sudo cryptsetup luksAddKey /dev/nvme0n1p2 /boot/key

Interestingly, this command fails with the same message as the one in the initramfs:
Code:

Keyslot open failed.

(--verbose --debug looks the same too)

First I thought maybe it is a problem that the LUKS container is already unlocked and mounted, but I couldn't find any information on that if that is possible.

It could also be that you are right and the password LUKS expects (and the working initramfs supplies) is not actually the one I thought it was...

Maybe I could also try in a Live CD environment...
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Wed Dec 08, 2021 4:41 pm    Post subject: Reply with quote

Sorry pingtoo, I read your post too fast.

You meant creating a keyfile with the current passphrase in it, instead of creating a new key.

I will try this later and report back...
Back to top
View user's profile Send private message
regox
Tux's lil' helper
Tux's lil' helper


Joined: 12 Sep 2021
Posts: 79

PostPosted: Wed Dec 08, 2021 10:02 pm    Post subject: Reply with quote

I tried it now with my passphrase inside a keyfile.

In the initramfs rescue shell, I called
Code:

cryptsetup luksOpen /dev/nvme0n1p2 --key-file=/mnt/key volgroup


Unfortunately, the output is still
Code:

Keyslot open failed.


Same command with --debug --verbose flags look almost identical to the ones previously posted
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54098
Location: 56N 3W

PostPosted: Wed Dec 08, 2021 10:49 pm    Post subject: Reply with quote

regox,

How did you mount the filesystem at /mnt in the initrd, so that /mnt/key could be read or is /mnt/key in the initrd?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
pingtoo
l33t
l33t


Joined: 10 Sep 2021
Posts: 887
Location: Richmond Hill, Canada

PostPosted: Wed Dec 08, 2021 11:00 pm    Post subject: Reply with quote

I went through some part of cryptsetup source codes and genkernel's initrd script. I think we may be going in wrong direction! 8O

Since you said using genkernel generated initramfs/kernel pair work. Please while in the working initramfs/kernel pair grep /proc/cmdline, share it.
Code:
user$ cat /proc/cmdline
Please hide any sensitive data before post.

The reason I want to know your kernel command line is because I found genkernl could be using GPG to setup. however not knowing how yours setup I don't know where to look.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum