Hi, this is my first time posting to a mailing list, I hope it is OK to share this here. TL;DR: Faulty RAM caused systemd-cryptsetup service to 'silently' fail. After encountering a system freeze, my laptop stopped accepting my disk password. From my point of knowledge, all error messages looked as if I was just mistyping the password (and after setting up a keyfile, it seemed not to have the right content). >From a live usb system I was able to decrypt everything just fine though. I spent the whole day trying to find issues with my configuration and trying to understand how the boot-time cryptsetup execution differs from the manual execution but to no avail. I saw 4.3 in your FAQ about RAM issues, so I decided to check If taking out one RAM module would do something, but didn't really think it would do something, as 'will not accept password in some circumstances' wasn't listed as a symptom. To the contrary, after taking out the apparently faulty RAM, everything just worked again. In hindsight the preceding system freeze should have led me to try this much earlier. Apart from thinking, that there could be better error messages if this type of failure is detectable at all, I would be interested in how that could be explained. Is the live system using the Ram in a different way for decryption than the boot procedure? Below I'll copy my help-seeking post to the internets from today for more description of what I encountered: > My Laptop froze and after a hard shutdown the boot process won’t accept my disk encryption password anymore. I have a ‘standard’ LUKS-inside-LVM setup, generated while installing fedora, split in a /root, /home and /swap partition, which worked for several years. > > Using a live USB system I can access the encrypted volumes and the data seems fine. I haven't had problems using it via chroot. > I ran fsck on the partition for good measure, fstab and crypttab seem fine and haven't changed compared to my backups. > "cryptsetup --debug isLuks" seems fine(Luks headers etc.). > As far as I can tell the boot messages don’t report anything, except for the errors related to the ‘wrong’ password. > > I tried to look into journalctl, but the entries stop hours before the system freeze occured (using journalctl -D mounted-root/var/log/journalctl) but maybe I’m doing it wrong. > > While trying to use a keyfile to unlock (which, again, works manually but not on boot, although the keyfile and the LUKS volume are found), I regenerated the initramfs, so that shouldn't be the problem aswell. > > I honestly don’t know what else to look for, any help would be appreciated. kind regards, luroc _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
