You are not logged in.
Pages: 1
What I did:
Okay, so I wanted to compile kernel 3.0.1 myself. I followed the Arch Wiki on how to do so, and downloaded the bZipped tarball from kernel.org. I untarred it and ran 'make menuconfig' from within the newly created directory. I did a totally clean compilation, and didn't import my current config file. I wrote a correct grub entry, and rebooted. I thought that I selected sane options for my system, but I messed up somewhere.
What happened:
On next reboot, my system picked up that /dev/sda2 was a LUKS-encrypted partition (which is correct) and asked me for the passphrase as usual (I didn't use a keyfile). Problem is, regardless of the passphrase I enter, the boot process explicitly fails with the message:
device-mapper: reload ioctl failed: Invalid Argument
Failed to setup dm-crypt key mapping for device /dev/sda2.
Check that kernel supports aes-xts-plain cipher (check syslog for more info).
Failed to read from key storage.Did I miss an option for dm-crypt or the cipher in the initial config, or is this capability somehow not implemented? /lib/modules/ contains an entry for the new kernel, with the driver files present in the same places as my previous kernel. Does the new one expect different names or locations? Thank you all for your time; any replies would be appreciated. I know it annoys potentially helpful people when insufficient info is submitted, so I'll include everything that I can think of as relevant. Let me know if I need more.
Install medium: Arch live disk (05-2010 upload on the website)
Architecture: x86
Original kernel: 2.6.33-ARCH (default kernel from the disk)
New kernel: 3.0.1 (latest stable from kernel.org)
gcc version: 4.5.0
cryptsetup version: 1.1.0
glibc version: 2.11.1
cipher type: aes-xts-plain (256 bit)
root partition type: ext2 (whole disk on one partition, no swap)
lsmod shows: dm_crypt, dm_mod, aes_i586, aes-generic, xts, and ext2 modules (are these not getting loaded w/new kernel?)
Computer: Dell Inspiron 15, AMD Athlon II 64-bit (32-bit OS installed, though)
Last edited by kaftenae42 (2011-08-17 02:53:34)
Offline
lsmod shows: dm_crypt, dm_mod, aes_i586, aes-generic, xts, and ext2 modules (are these not getting loaded w/new kernel?)
I assume this lsmod output is from the previous kernel, since you can't successfully boot the new one?
See if you can get lsmod in the recovery shell that you drop to when the boot fails. Put it in the BINARIES (as /bin/lsmod) in mkinitcpio.conf to make it available in the recovery shell, if it isn't already. Maybe throw the dm_crypt and aes_i586 modules in the MODULES line too while you're at it; that might even fix the problem. Also double check that the "encrypt" hook is definitely present in the mkinitcpio.conf file that you're using.
Also, you can still get the detailed boot messages (which might show which module is missing) with the dmesg command at the recovery shell.
Hope some of this helps,
~Felix.
Offline
@Felix
Thank you for the tips; I will try them soon and report back. I assume that after I edit mkinitcpio.conf that I'll have to rebuild the kernel image?
Offline
@Felix
Thank you for the tips; I will try them soon and report back. I assume that after I edit mkinitcpio.conf that I'll have to rebuild the kernel image?
Yes -- just re-run mkinitcpio with the same options you used before (don't know offhand what the switches are for a custom kernel image, but I assume it's the ones in the wiki).
~Felix.
Offline
Okay, I made absolutely sure that the Encrypt hook was parsed into the new kernel, and added dm_crypt and aes_i586 to the MODULES line in mkinitcpio.conf before rebuilding again. When I re-ran mkinitcpio, everything went fine. I re-copied the new(est) kernel to /boot, under a different name, and added another grub entry. Like I said earlier, the first attempt at building this kernel resulted in one shot at entering a passphrase and then a dump into a recovery shell. With mkinitcpio.conf edited to include a few new crypto modules, I still get the same error as above, but it simply loops with the passphrase prompt without dropping to an emergency shell. Could there be a new problem now?
Offline
Pages: 1