You are not logged in.
I have a newly installed system with LVM on LUKS. Everything is working great, except that I sometimes seem to type the luks passphrase wrongly upon boot, or resume. I can't be typing the wrong passphrase, I'm thinking of course. Could you? But somehow, maybe I just am. Or maybe, just maybe, there is a small fluke that sometimes prevents the LVM from appearing in time for the boot system to find its partitions? Anybody heard of something like that?
Anyhow, lets assume I'm typing the wrong passphrase. Is there any possibility to have the mkinitcpio encrypt to allow for a retry? I don't know anything about the details of its workings--is this perhaps not feasible at all? But, if I were given exactly 2 chances to type my passphrase, that would also be a good way to eliminate any other problem. And to get me through when I'm indeed typing wrongly! The key issue here is that when I'm resuming my system, I end up losing my whole work setup, when this happens. Since encrypt module is so very unforgiving, and a wrong passphrase doesn't open LVM, root partition is not found, the system reboots, and the next time when I give the password correctly, it is booted into a clean system.
I guess you don't have this problem, and always type correctly.
Last edited by quite (2015-06-03 15:28:14)
Offline
If you enter the incorrect passphrase, you should get another prompt with a message saying (paraphrased): not a recognised passphrase.
Please post more details about your setup.
Offline
Ooh, really? Interesting... What can I report?
/etc/mkinitcpio.conf:
HOOKS="base udev encrypt lvm2 resume autodetect modconf block filesystems keyboard fsck"
/boot/grub/grub.cfg:
linux /vmlinuz-linux root=UUID=deadbeef-... rw cryptdevice=/dev/sda2:foogroup resume=/dev/foogroup/fooswap
Offline
Shouldn't your root line in grub be pointing at /dev/mapper/foogroup-fooroot?
Offline
My system is able to boot as is. I assume you note this for consistency, or otherwise? Or could it possibly affect my issue at hand--that I'm not getting the, supposedly expected, LUKS-incorrect-passphrase-prompt? I'll obviously not try and change something just for the sake of changing it--not break something which does work.
Offline
Well, it isn't exactly working at the moment... and it is not to hard to chroot in and fix it.
Offline
iWell, all right, I should consider it for my next reboot... Currently, my /etc/default/grub has this line:
GRUB_CMDLINE_LINUX_DEFAULT="cryptdevice=/dev/sda2:foogroup resume=/dev/foogroup/fooswap"That is, no "root=". Apparently, this is added by grub-mkconfig somehow? Using /etc/grub.d/* ? I tried adding a root=/dev/mapper/foogroup-fooroot and the result from a run with "grub-mkconfig -o test" is two (2) "root=":
root=UUID=deadbeef-... rw root=/dev/mapper/foogroup-fooroot cryptdevice...I shouldn't have to fiddle in /etc/grub.d/* right...
Offline
The deadbeef thing is superfluous (at least according to the wiki: I don't use grub)...
Offline
Maybe you need to reorder your hooks, mine say: 'HOOKS="base udev autodetect modconf block hddapm keymap encrypt lvm2 resume filesystems keyboard fsck' and so far I never had any problems with being asked the password twice (except when I get it wrong).
You can ignore hddapm which is something of mine and the order of modconf shouldn't matter, but all (or almost all) others do need to come in order for things to work.
As for grub I have stopped using grub-mkconfig, it's just not worth the hassle. Use it once then personalize your grub.cfg and be done with it.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
In the end, I think the problem was the order. But the reboots I was doing at the time to test it didn't show any difference. Now, a month later and with kernel 4.0.4-2, I do get a retry if I type the wrong passphrase.
-HOOKS="base udev resume encrypt lvm2 autodetect modconf block filesystems keyboard fsck"
+HOOKS="base udev encrypt lvm2 resume autodetect modconf block filesystems keyboard fsck"
Offline