new LUKS installation 1st boot "crypt: Error decoding and setting key"

a7ch · 2013-08-03 17:43:23

New install to a solid state drive. At this time I am not using swap (16gb RAM) and have simplified my partitions in an attempt to diagnose my current problem booting up.

When I boot up, grub2 loads, I choose the first option and it asks me for my LUKS password for /root. Once I type the password I get the error device-mapper: table: 254:1: crypt: Error decoding and setting key

Here is my partition setup.

/dev/sda1 = vfat /boot partition for UEFI
/dev/sda2 = /root LUKS encrypted partition

I tried a couple different things with /etc/defaults/grub (and each time grub-mkconfig afterwards) and they all return the same error as above. It is worth noting that when you do grub-mkconfig the script will add the line root=/dev/mapper/root to the grub.cfg for you automagically.

3 different ways I've tried /etc/defaults/grub

GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root:allow-discards"
GRUB_DISABLE_LINUX_UUID=true

GRUB_CMDLINE_LINUX="cryptdevice=/dev/disk/by-uuid/227d9a84-cb82-4864-84cf-94cd1369c7c2:root:allow-discards"
#GRUB_DISABLE_LINUX_UUID=true

GRUB_CMDLINE_LINUX="cryptdevice=UUID=227d9a84-cb82-4864-84cf-94cd1369c7c2:root:allow-discards"
#GRUB_DISABLE_LINUX_UUID=true

Here is the applicable part of the grub.cfg

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Arch Linux, with Linux core repo kernel' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-core repo kernel-true-931315f5-fe99-4d09-a16d-69a5f0d91ab0' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod fat
	set root='hd0,gpt1'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1  4270-9641
	else
	  search --no-floppy --fs-uuid --set=root 4270-9641
	fi
	echo	'Loading Linux core repo kernel ...'
	linux	/vmlinuz-linux root=/dev/mapper/root ro cryptdevice=/dev/sda2:root:allow-discards quiet
	echo	'Loading initial ramdisk ...'
	initrd	/initramfs-linux.img
}

Here are the applicable lines from my mkinitcpio.conf. I went a little overboard with the modules, but I was hoping maybe I was missing something so I just loaded everything I could think of.

MODULES="dm_mod dm_crypt ext4 vfat aes-x86_64 sha256 sha512"
HOOKS="base udev autodetect modconf block encrypt filesystems keyboard fsck consolefont keymap"

Here is my fstab

# /dev/mapper/root
UUID=227d9a84-cb82-4864-84cf-94cd1369c7c2	/		ext4		rw,relatime,data=ordered,discard	0 1

# /dev/sda1
UUID=4270-9641      	/boot     	vfat      	rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro	0 2

My crypttab is empty.

My latest theory is that maybe I'm not loading up ext4 properly as needed by my root partition? Any help is appreciated.

a7ch · 2013-08-03 18:51:43

If I boot into a livecd enviornment then reboot sometimes when I type in the LUKS password it will immediately give me the login screen as if I did boot successfully. The cursor will flash for about 1 second then it will stop flashing. A Control+Alt+Delete will invoke a restart. Then when I type in the LUKS password on the second boot since the livecd and chroot environment then I will get the same as the screenshot in my first post. When it does give me the login, the screen says:

Arch Linux 3.10.3-1-ARCH (tty1)

username login: _

I also tried removing the trim support on fstab and in grub. No difference.

Last edited by a7ch (2013-08-03 18:54:40)

cfr · 2013-08-03 21:39:54

Welcome to the forums.

Are you certain that the password you are entering is correct? If you boot into the live environment, can you open the LUKS container successfully? On the other hand, if the password were wrong, I'd expect it to just ask for it again - that's what mine does if I mistype it, for example.

Have you double checked the fstab line for /? I think you need to pass it the mapped root e.g. /dev/mapper/root but I'm not sure about this as I can't find any definite information in the wiki. Certainly the UUID should not be that of sda2 so I would at least check what it is the UUID for. I'm not quite sure because I seem to have UUIDs all over the place (I use LVM-on-LUKS) but I specify /dev/mapper/... in fstab.

You also might try specifying the file system type - see https://wiki.archlinux.org/index.php/LU … bootloader.

a7ch · 2013-08-03 22:53:47

cfr wrote:

Welcome to the forums.
Are you certain that the password you are entering is correct? If you boot into the live environment, can you open the LUKS container successfully? On the other hand, if the password were wrong, I'd expect it to just ask for it again - that's what mine does if I mistype it, for example.
Have you double checked the fstab line for /? I think you need to pass it the mapped root e.g. /dev/mapper/root but I'm not sure about this as I can't find any definite information in the wiki. Certainly the UUID should not be that of sda2 so I would at least check what it is the UUID for. I'm not quite sure because I seem to have UUIDs all over the place (I use LVM-on-LUKS) but I specify /dev/mapper/... in fstab.
You also might try specifying the file system type - see https://wiki.archlinux.org/index.php/LU … bootloader.

Thank you for your reply. I've been using arch for years now but I haven't had to ask a question.

I'm certain the password is correct. I can open it successfully in a livecd environment. If i do type the password incorrectly it prompts me again.

With regards to specifying the file system type, that is for using a cryptkey, which this encrypted container currently does not have.

I tried changing the fstab line for my root device to /dev/mapper/root and I get the exact same behavior, same error: crypt: error decoding and setting key.

Here is what blkid returns in regards to my UUID naming:

/dev/sda1: UUID="4270-9641" TYPE="vfat" PARTUUID="b5258703-77ed-4720-822d-be25588ae174" 
/dev/sda2: UUID="227d9a84-cb82-4864-84cf-94cd1369c7c2" TYPE="crypto_LUKS" PARTUUID="b65678ee-b911-4c2d-bb72-4611e8a0f98e" 
....
/dev/mapper/root: UUID="931315f5-fe99-4d09-a16d-69a5f0d91ab0" TYPE="ext4"

I'm not sure what you mean by this: "Certainly the UUID should not be that of sda2 so I would at least check what it is the UUID for."

Perhaps you are suggesting that I use the UUID of /dev/mapper/root. When I try that I get the exact same behavior, same error: crypt: error decoding and setting key.

I think I'm going to redo the partitions and start over with the install. I screwed something up.

cfr · 2013-08-03 23:24:32

I actually meant specifying rootfs on the kernel command line.

EDIT: But my wiki link was really misleading. Sorry about that.

Yes, I did mean use the UUID of /dev/mapper/root or just use /dev/mapper/root. The same applies to fstab where you are also trying to mount the encrypted container at / rather than the file system, I think.

This is a bit more obvious, maybe, if you think about how this would work if you had LVM on top of LUKS because then it would be obvious that you shouldn't try to mount /dev/sda2 to /, /home and /var, say, and that your kernel command line needed to reflect this, too. I really think it is easier to avoid UUID here and there is no real need for it because /dev/mapper/root, for example, is unique in any case.

Last edited by cfr (2013-08-03 23:27:10)

a7ch · 2013-08-03 23:52:43

I started over from stratch. I've been troubleshooting this for at least a week so I was very familar with the configs and this time instead of messing with fstab too much I just let genfstab take care of it.

I got rid of that error, but I guess that error wasn't the problem.

I boot up, EFI grub loads, i choose the first option then I'm prompted for my LUKS root partition password. I type in the password, then /dev/mapper/root is mounted cleanly. The cursor blinks for a few seconds, then the cursor goes away. The boot doesn't continue. I'll type it out.

A password is required to access the root volume:
Enter passphrase for /dev/sda2:
/dev/mapper/root: clean, 30276/1433600 files, 299898/5731072 blocks
<cursor flashes for about 2 seconds then disappears>

A control+alt+delete will force a reboot.

cfr · 2013-08-04 00:56:36

Can you boot to the command line? That is, specify the target on the kernel command line to stop it trying to boot straight into X.

a7ch · 2013-08-07 01:29:52

It wasn't trying to boot into X. The problem was it was loading up the nouveau frame buffer and it wasn't having any of that. I added nomodeset to my kernel line in grub and it no longer "froze". Thanks for your help, I appreciate it.

Arch Linux

#1 2013-08-03 17:43:23

new LUKS installation 1st boot "crypt: Error decoding and setting key"

#2 2013-08-03 18:51:43

Re: new LUKS installation 1st boot "crypt: Error decoding and setting key"

#3 2013-08-03 21:39:54

Re: new LUKS installation 1st boot "crypt: Error decoding and setting key"

#4 2013-08-03 22:53:47

Re: new LUKS installation 1st boot "crypt: Error decoding and setting key"

#5 2013-08-03 23:24:32

Re: new LUKS installation 1st boot "crypt: Error decoding and setting key"

#6 2013-08-03 23:52:43

Re: new LUKS installation 1st boot "crypt: Error decoding and setting key"

#7 2013-08-04 00:56:36

Re: new LUKS installation 1st boot "crypt: Error decoding and setting key"

#8 2013-08-07 01:29:52

Re: new LUKS installation 1st boot "crypt: Error decoding and setting key"

Board footer