You are not logged in.

#1 2018-09-29 18:33:48

KairiTech
Member
From: Toronto, Canada
Registered: 2011-06-04
Posts: 238

encrypt hook - "Keyfile could not be opened. Reverting to passphrase."

I have been modifying my encrypt hook as indicated here, Modifying encrypt hook, for quite some time with no issues. However, over the last several weeks it can no longer find the keyfile specified in the kernel parameter below and I get the passphrase prompt.

cryptkey=UUID=D4C1-41C0:vfat:/boot/lxK/k_64SSDx3

However, when I force the ckeyfile variable to the same keyfile as below it works and there's no prompt.

run_hook() {
    modprobe -a -q dm-crypt >/dev/null 2>&1
    [ "${quiet}" = "y" ] && CSQUIET=">/dev/null"

    # Get keyfile if specified
    ckeyfile="/crypto_keyfile.bin"
    ckeyfile="/boot/lxK/k_HDD"
    if [ -n "$cryptkey" ]; then
        IFS=: read ckdev ckarg1 ckarg2 <<EOF
$cryptkey
EOF

For completeness here's the sylinux boot menu item (same thing happens if I go the UEFI route):

        MENU LABEL ]HDD 
        LINUX /EFI/HDD/vmlinuz-linux.efi
        APPEND root=/dev/mapper/HDD cryptdevice=/dev/md1:HDD:header cryptkey=UUID=D4C1-41C0:vfat:/boot/lxK/k_HDD init=/usr/lib/systemd/systemd pcie_aspm=force rootdelay=3 quiet loglevel=0 rd.udev.log-priority=3 
        INITRD /EFI/HDD/initramfs-linux.img

This is how I format the partition holding the keyfile:

mkfs.vfat -v -s2 -F32 -n lxK_boot /dev/sdf1

This confirms the UUID I specify in the krenel parameter:

/dev/sdf1: LABEL="lxK_boot" UUID="D4C1-41C0" TYPE="vfat" PARTLABEL="lxk_boot" PARTUUID="aa7281c7-a586-4eb6-abb4-a2e5146ad8b2"

I've been looking over my LUKS setup for a while now but just can't see anything that might explain this.

Am I missing something so bovious that I should go out and buy myself some brown paper bags?

Last edited by KairiTech (2018-09-30 03:54:03)


-=[ LIVE enabled UEFI with redundant syslinux pure systemd detached LUKS header partitionless encrypted GPT SSDx3 RAID0 because I can.  ]=-

Backward compatibility is for the masses. There's no dual-boot here...

Offline

#2 2018-10-11 23:07:56

jecki
Member
Registered: 2018-10-11
Posts: 1

Re: encrypt hook - "Keyfile could not be opened. Reverting to passphrase."

I had a very similar problem: A week or two ago, the system suddenly could not open the keyfile from my usb-stick any more. I was able to solve the problem by adding uas and usb_storage to MODULES in /etc/mkinitcpio.conf :

MODULES=(uas usb_storage ...)

Offline

#3 2018-10-14 04:03:03

nyn
Member
Registered: 2015-05-27
Posts: 11

Re: encrypt hook - "Keyfile could not be opened. Reverting to passphrase."

jecki wrote:

I had a very similar problem: A week or two ago, the system suddenly could not open the keyfile from my usb-stick any more. I was able to solve the problem by adding uas and usb_storage to MODULES in /etc/mkinitcpio.conf :

MODULES=(uas usb_storage ...)

Thank you very much. I encountered the same problem after updating my system yesterday and this fixed it.

Offline

#4 2019-01-17 22:38:33

KairiTech
Member
From: Toronto, Canada
Registered: 2011-06-04
Posts: 238

Re: encrypt hook - "Keyfile could not be opened. Reverting to passphrase."

jecki wrote:

I had a very similar problem: A week or two ago, the system suddenly could not open the keyfile from my usb-stick any more. I was able to solve the problem by adding uas and usb_storage to MODULES in /etc/mkinitcpio.conf :

MODULES=(uas usb_storage ...)

I've been trying this since you suggested it and even after a few upgrades to the mkinitcpio package I still get prompted for the passphrase.


-=[ LIVE enabled UEFI with redundant syslinux pure systemd detached LUKS header partitionless encrypted GPT SSDx3 RAID0 because I can.  ]=-

Backward compatibility is for the masses. There's no dual-boot here...

Offline

#5 2019-01-17 23:25:50

frostschutz
Member
Registered: 2013-11-15
Posts: 689

Re: encrypt hook - "Keyfile could not be opened. Reverting to passphrase."

Now this is just wild guesswork... but does the file you specified even exist?

mkdir /mnt/tmp
mount -o ro -t vfat UUID=D4C1-41C0 /mnt/tmp
stat /mnt/tmp/boot/lxK/k_64SSDx3

However, when I force the ckeyfile variable to the same keyfile as below it works and there's no prompt.

It would make sense if you have usually mounted that key filesystem to /boot/lxK of your running arch, and added /boot/lxK/k_64SSDx3 to FILES in your mkinitcpio.conf

In that case the key is embedded into the initramfs itself and the physical key device no longer matters at all...

Offline

#6 2019-01-18 01:08:29

KairiTech
Member
From: Toronto, Canada
Registered: 2011-06-04
Posts: 238

Re: encrypt hook - "Keyfile could not be opened. Reverting to passphrase."

It would make sense if you have usually mounted that key filesystem to /boot/lxK of your running arch, and added /boot/lxK/k_64SSDx3 to FILES in your mkinitcpio.conf

Which confirms that the keyfile on the keyfile device I copy into the initramfs is valid.

Is it that dm-crypt doesn't like UUIDs anymore?

My current install has the following characteristics -

The keyfile:

-rwxr-xr-x 1 root root 2048 Dec  8 14:17 /boot/lxK/k_64SSDx3

The keyfile device mounted on /boot:

├─sdf1        8:81   1   256M  0 part  /boot

The UUID of the keyfile device:

/dev/sdf1: LABEL_FATBOOT="lxK_boot" LABEL="lxK_boot" UUID="2492-8796" TYPE="vfat" PARTLABEL="lxK_boot" PARTUUID="2518fe82-35be-42a0-93e6-8be2713ea7f5"

The vfat module is included in the initramfs:

MODULES=(dm_mod dm_crypt aes_x86_64 raid0 nls_iso8859_1 vfat ext4 zram ext2)

The kernel boot parameter for the keyfile:

cryptkey=UUID=2492-8796:vfat:/boot/lxK/k_64SSDx3

-=[ LIVE enabled UEFI with redundant syslinux pure systemd detached LUKS header partitionless encrypted GPT SSDx3 RAID0 because I can.  ]=-

Backward compatibility is for the masses. There's no dual-boot here...

Offline

#7 2019-01-18 02:07:29

frostschutz
Member
Registered: 2013-11-15
Posts: 689

Re: encrypt hook - "Keyfile could not be opened. Reverting to passphrase."

KairiTech wrote:

Which confirms that the keyfile on the keyfile device I copy into the initramfs is valid.

The keyfile may be valid, sure. Putting it in the initramfs would likely defeat your security concept regardless. ;-)

KairiTech wrote:

Is it that dm-crypt doesn't like UUIDs anymore?

What I was trying to point out is that you're likely using the wrong path. You have to specify the path relative to the filesystem itself, not to whatever you mount it to because that doesn't matter. (The initramfs mounts it elsewhere. The mount path is not specified anywhere.)

So I'm guessing you do not have a boot directory on that vfat filesystem. And maybe not a lxK directory either. Depending on that you'd have to change the supplied path (remove /boot or /boot/lxK).

cryptkey=UUID=2492-8796:vfat:/boot/lxK/k_64SSDx3

Yeah, try that without /boot/

And if that works, make sure /boot/lxK/k_64SSDx3 is no longer included into the initramfs.

( Or maybe that's what you really want to achieve here - is this a stick that only supplies a keyfile, or is this the stick you're actually booting from? If you want it to boot without passphrase, just including the key as /crypto_keyfile.bin will do. That works without modification to the encrypt hook at all and without cryptkey parameter then. Low safety though. )

Last edited by frostschutz (2019-01-18 02:11:24)

Offline

#8 2019-01-19 04:01:57

KairiTech
Member
From: Toronto, Canada
Registered: 2011-06-04
Posts: 238

Re: encrypt hook - "Keyfile could not be opened. Reverting to passphrase."

Depending on that you'd have to change the supplied path (remove /boot or /boot/lxK).

cryptkey=UUID=2492-8796:vfat:/boot/lxK/k_64SSDx3

Yeah, try that without /boot/

I tried just that a while back and just to be sure I tried it again but I still get the passphrase prompt.

The oddest thing though is that even when I do have the ckeyfile variable in the encrypt hook set to '/boot/lxK/k_64SSDx3' if I do not also have the cryptkey kernel parameter set to the keyfile on the USB thumb drive I get prompted for the passphrase.  I would have thought that the keyfile in the initramfs and the keyfile on the USB were totally independent of each other.


-=[ LIVE enabled UEFI with redundant syslinux pure systemd detached LUKS header partitionless encrypted GPT SSDx3 RAID0 because I can.  ]=-

Backward compatibility is for the masses. There's no dual-boot here...

Offline

#9 2019-01-19 11:12:55

frostschutz
Member
Registered: 2013-11-15
Posts: 689

Re: encrypt hook - "Keyfile could not be opened. Reverting to passphrase."

Well, no idea.

You could enable shell debugging ( set -x to enable, set +x to disable ).

You can remove what output is suppressed explicitely ( get rid of > /dev/null 2>&1 ) .

That way maybe you can see what it is doing in the encrypt hook up to the passphrase. Helps if the console is already in high res mode at that point (if it's intel graphics, might have to add i915 to MODULES)

Offline

Board footer

Powered by FluxBB