View previous topic :: View next topic |
Author |
Message |
Tinfoil_hat n00b
Joined: 01 Feb 2016 Posts: 5
|
Posted: Tue Feb 02, 2016 11:30 am Post subject: Cryptsetup failing with "code 5: Input/output error&quo |
|
|
Code: |
Starting cryptsetup
# cryptsetup 1.6.5 processing "cryptsetup --debug open --header header.img --type luks --key-file text.txt /dev/sda root"
# Running command open.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating crypt device header.img context.
# Trying to open and read device header.img.
# Initialising device-mapper backend library.
# Trying to load LUKS1 crypt type from device header.img.
# Crypto backend (Nettle) initialized.
# Reading LUKS header of size 1024 from device header.img
# Trying to open device header.img without direct-io.
# Key length 64, device size 4096 sectors, header size 4036 sectors.
# Setting ciphertext data device to /dev/sda.
# Trying to open and read device /dev/sda.
# Timeout set to 0 miliseconds.
# Password retry count set to 3.
# Password verification disabled.
# Iteration time set to 1000 miliseconds.
# Password retry count set to 1.
# Activating volume root [keyslot -1] using keyfile text.txt.
# Detected kernel Linux 4.1.12-gentoo i686.
# dm version OF [16384] (*1)
# dm versions OF [16384] (*1)
# Detected dm-crypt version 1.14.1, dm-ioctl version 4.31.0.
# Udev is not running. Not using udev synchronisation code.
# Device-mapper backend running with UDEV support disabled.
# dm status root OF [16384] (*1)
# File descriptor passphrase entry requested.
# Trying to open key slot 0 [ACTIVE_LAST].
# Reading key slot 0 area.
# Using userspace crypto wrapper to access keyslot area.
# Releasing crypt device header.img context.
# Releasing device-mapper backend.
# Unlocking memory.
Command failed with code 5: Input/output error
[ 22.203546] cryptsetup (1049) used greatest stack depth: 6284 bytes left
Something went wrong. Dropping to shell.
sh: can't access tty; job control turned off
/ #
|
I got this after trying to install gentoo on my laptop with an encrypted root and detached luks header, using a custom initramfs as described on the wiki. Any ideas as to what I might have done wrong? |
|
Back to top |
|
|
Roman_Gruber Advocate
Joined: 03 Oct 2006 Posts: 3846 Location: Austro Bavaria
|
Posted: Tue Feb 02, 2016 11:46 am Post subject: |
|
|
i used luks on lvm + ext4 for years.
in short.
genkernel initramfs can be used when you adapt the initramfs + grub2 config + adapted kernel
it is different on each setup.
Step 1: can you open the encrypted volume by hand with a live-cd
essential, so you understand the steps involved to open the volume
step 2: go step by step through the initramfs and check what it does. (the conclusion after i set up this notebook with uefi and kernel 4.0 with encryption)
booting is only possible when using an unencrypted boot + initramfs and kernel in that unencrypted boot. the needed "modules" + "options" need to be in that unencrytped boot.
To get such a setup running is time consuming, and needs a proper understanding on how it works.
Most guys ignore grub2 needed options, the kernel itself and others. Check carefully from scratch any option which is involved.
May i ask which intiramfs you are using.
I really wonder how udev should work when you do not have access to root in the firstplace.
my initamfs do usually use busybox, ... |
|
Back to top |
|
|
Tinfoil_hat n00b
Joined: 01 Feb 2016 Posts: 5
|
Posted: Tue Feb 02, 2016 12:30 pm Post subject: |
|
|
Code: | #!/bin/busybox sh
rescue_shell() {
echo "Something went wrong. Dropping to a shell."
exec sh
}
# Mount the /proc and /sys filesystems.
echo "Mounting proc, sys and dev"
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devtmpfs none /dev
# Unlock the root drive
echo "Starting cryptsetup"
cryptsetup --debug open --header header.img --type luks --key-file text.txt /dev/sda root || rescue_shell
# Mount the root drive
echo "Mounting the drive"
mount /dev/mapper/root /mnt/root
# Clean up.
echo "Cleaning up"
umount /proc
umount /sys
umount /dev
# Boot
echo "Booting"
exec switch_root /mnt/root /sbin/init
|
Yes, it unlocks just fine using the live-cd, with the same command and arguments as used above. The boot partition is of course unencrypted.
As far as I understood it, genkernel's initramfs doesn't allow for detached luks headers.
I included the init above. |
|
Back to top |
|
|
frostschutz Advocate
Joined: 22 Feb 2005 Posts: 2977 Location: Germany
|
Posted: Tue Feb 02, 2016 12:47 pm Post subject: |
|
|
Anything in dmesg?
Post your kernel .config as well, maybe you forgot to add support for some ciphers. For example sha-1 is mandatory.
Also have you verified that the keyfile works? It says text.txt, if it's actually a readable string, it might get confused by a newline character. |
|
Back to top |
|
|
Tinfoil_hat n00b
Joined: 01 Feb 2016 Posts: 5
|
Posted: Tue Feb 02, 2016 1:20 pm Post subject: |
|
|
Nothing wrong in dmesg that I can see, no
I tried several times with a keyfile and with a password - both failed. I tried setting the number of password retries with "-T 10", but it still only gave me one attempt and then failed.
Here is the kernel config: https://bpaste.net/raw/47e4e92dde5e |
|
Back to top |
|
|
frostschutz Advocate
Joined: 22 Feb 2005 Posts: 2977 Location: Germany
|
Posted: Tue Feb 02, 2016 2:17 pm Post subject: |
|
|
Hm, not sure what's wrong.
Just for kicks, try to enable all crypto (block/hash/digest/cipher) that currently are not enabled in the kernel.
You could include strace in your Initramfs and strace the cryptsetup call, maybe it would give a better picture. strace produces a lot of output so you'll probably have to dump it into a file. Also note that strace output might leak your key data; but maybe it will show which syscall(s) actually produce that I/O error of yours.
Just to make sure, /dev/sda itself works? (hexdump -C -n 512 /dev/sda gives data?) |
|
Back to top |
|
|
Tinfoil_hat n00b
Joined: 01 Feb 2016 Posts: 5
|
Posted: Tue Feb 02, 2016 3:12 pm Post subject: |
|
|
Here comes the strace: https://bpaste.net/raw/c7a04e87c96a
Using strace was a good idea. It seems to fail twice when attempting to use open() with O_DIRECT. Could it be that I'm simply missing kernel support for this? |
|
Back to top |
|
|
frostschutz Advocate
Joined: 22 Feb 2005 Posts: 2977 Location: Germany
|
Posted: Tue Feb 02, 2016 3:23 pm Post subject: |
|
|
Interesting, try creating a loop device (losetup) for the header.img and then use the loop device as header. That might trick it into accepting O_DIRECT. Don't forget to remove the loop device afterwards.
Possibly related: http://www.saout.de/pipermail/dm-crypt/2014-August/004228.html |
|
Back to top |
|
|
Tinfoil_hat n00b
Joined: 01 Feb 2016 Posts: 5
|
Posted: Tue Feb 02, 2016 4:06 pm Post subject: |
|
|
Nice! That worked perfectly. After days of messing around it finally boots.
Thank you so much for the help!
I'm surprised this hasn't been up before, because there are certainly other people with this exact setup too. Searching around I only find a blog mentioning it.
If there is no other way of doing it, it really needs to be included in the wiki.
Again, thanks for the help. |
|
Back to top |
|
|
frostschutz Advocate
Joined: 22 Feb 2005 Posts: 2977 Location: Germany
|
Posted: Tue Feb 02, 2016 4:27 pm Post subject: |
|
|
I think only very few people use external LUKS header. I do use external keyfiles (even LUKS-encrypted ones) but the actual LUKS header is still on the encrypted disk itself. |
|
Back to top |
|
|
|