You are not logged in.
Hi there,
I recently purchased a Huawei Matebook D laptop, and have installed Arch Linux with LVM on top of LUKS, with a GPT partitioning scheme, and grub as a bootloader. My problem is that upon boot, when I type my password to decrypt the drive (in this case, /dev/sda3), the decryption process only works some of the time, seemingly randomly. I know the password I'm typing is correct, since I've tested it repeatedly while the machine is booted and it unlocks successfully every time. However, on the initial decrypt, it tends to be 50/50, saying "No key available with this passphrase" sometimes, and other times booting into the system no problem. It isn't crucial since I can always get it to decrypt after a few attempts, but it is rather bothersome and would be a problem if I needed to boot up in a hurry.
I'm quite stuck on this one, so any ideas or suggestions are appreciated.
Offline
Are you sure that your keyboard is working perfectly fine? Can you try to reproduce the issue with an external keyboard?
Offline
Thanks for that idea! I think you're onto something - when I plugged in an external keyboard, it worked 100% of the time.
I'd guess that some key inputs aren't being read on occasion, since I can usually get the disk to decrypt in less than 10 attempts. However, I notice no effect like this while actually booted into the OS. Any ideas as to what could cause something like that during boot? For reference, in my mkinticipo.conf, I did load the modules 'keyboard' and 'keymap'.
Offline
This may be a long shot, but do you have any unicode characters in your password? If yes, then that *might* have something to do with the issue.
Offline
I do not - just letter and numbers.
Also, if I drop into a shell right from grub, the issue doesn't exist there either. It only seems to be while entering the password.
Offline
Does it matter how long you wait before you attempt to unlock the drive?
(And for that matter: is your /boot partition on the same disk or in the ESP)
Offline
Hmm, I think that does matter actually. If I wait 10-15 seconds before the first attempt, the problem is still reproducible, but happens far less often than if I was to attempt the decryption immediately. After having waited that long I can usually get it within 3 tries, but if I start immediately it can take up to 10.
Boot and EFI are on separate partitions, both unencrypted (though efi is mounted on /boot). The layout is as follows:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 238.5G 0 disk
├─sda1 8:1 0 200M 0 part /boot/efi
├─sda2 8:2 0 500M 0 part /boot
└─sda3 8:3 0 237.8G 0 part
└─luks 254:0 0 237.8G 0 crypt
├─vg-swap 254:1 0 8G 0 lvm [SWAP]
└─vg-root 254:2 0 229.8G 0 lvm /Offline
Hmm, what if you pass "random.trust_cpu=on" to the kernel? ("lscpu | grep rdrand" to ensure it's supported at all, Ivy Bridge and newer)
Offline
Thank you, I think that may have helped. It still is reproducible, but it seems to be happening less frequently now, and I can pretty much always unlock it within 2 or 3 attempts (especially if I wait a few extra seconds).
Offline