SOLVED Error decrypting LUKS partition prior to capture/imaging

  • @george1421 thanks for uploading this! I just got a chance to try it out. It fails but a different error this time, so I think we’re getting closer.

    [Mon Oct 21 root@fogclient /]# cryptsetup luksOpen /dev/md126p3 crypt
    Enter passphrase for /dev/md126p3:
    device-mapper: table: 251:0: crypt: Error allocating crypto tfm
    reload ioctl on    failed: No such file or directory
    Failed to setup dm-crypt key mapping for device /dev/md126p3
    Check that the kernel supports aes-xts-plain64 cipher (check syslog for more info).

    From /var/log/messages:

    Oct 21 21:03:16 fogclient user.err kernel: device-mapper: table: 251:0: crypt: Error allocating crypto tfm
    Oct 21 21:03:16 fogclient user.warn kernel: device-mapper: ioctl: error adding target to table

    Doing some research, it looks like a module may be missing (“No such file or directory”). Could it be that the module for the cipher is missing? I’m currently using cryptsetup default options (which uses aes-xts-plain64 as cipher). When I try cat crypto | grep aes on this FOS build, I only see aes-generic whereas I see ~20 options when doing the same on my Ubuntu server (including xts-aes-aesni).

    Let me know if I can do anything to help debug further.

    Some links referencing similar error messages out there:

  • Moderator

    @humoss233 I recompiled the kernel last night after my post with the dm_crypt enabled. Give me a minute and I’ll upload it where you can get to it.
    Note to future readers I may remove this file at any time so the link may not be valid in the future

    To use this new kernel, download it from the link and save it in /var/www/html/fog/service/ipxe directory on the fog server as bzImageCrypt Then manually register one host and then go into the web ui in the host management for this target system. Update the kernel field with bzImageCrypt (watch the case because it IS important). Save the host management page and then schedule another debug capture. Then test your commands again with the modules loaded into the kernel.

    ref Kernel patch file for differences between standard config and dm_crypt added config

    --- kernelx64.config    2019-08-29 12:46:58.222184653 -0400
    +++ .config     2019-10-20 00:20:29.579817034 -0400
    @@ -1273,12 +1273,17 @@
     # CONFIG_BCACHE is not set
    -# CONFIG_DM_MQ_DEFAULT is not set
     # CONFIG_DM_DEBUG is not set
    -# CONFIG_DM_UNSTRIPED is not set
    -# CONFIG_DM_CRYPT is not set
    -# CONFIG_DM_SNAPSHOT is not set
     # CONFIG_DM_CACHE is not set
     # CONFIG_DM_WRITECACHE is not set
     # CONFIG_DM_ERA is not set
    @@ -3424,8 +3429,6 @@
     # CONFIG_KASAN is not set
    -# CONFIG_KCOV is not set
     # CONFIG_DEBUG_SHIRQ is not set

  • @george1421 Thanks for your comprehensive treatment of this topic! Absolutely re: getting it working manually before automating with init scripts.

    It sounds like dm crypt is not something that can be enabled with a flag? If not, I could try to rebuild the kernel if it’s a simple one-liner tweak somewhere here for example?

  • Moderator

    @humoss233 There are a couple of things at play here.

    First of all (if everything else is setup) you can automate this with a fog post init scripts. These scripts are run just after the FOS Linux engine starts but before any imaging take place. These scripts are intended for bringing up raid cards, or any other hardware related activities before imaging starts. So once you can get things working manually then we can focus on automation.

    Secondly, if you setup a debug capture or deploy you can debug or bring up hardware prior to imaging. Once the hardware is setup you would key in fog to start imaging (this would be done on the target computer). In debug mode the FOS scripts will pause between each step to wait for an enter key press. This allows you to read or react to error messages. If you need to break out of the imaging script just key in ctrl-c, fix what was needed then restart the imaging process by keying in fog again.

    Now that we have some of the basic debugging processes out of the way we can think about the root of the problems.

    In the linked article the FOS Linux kernel will need the dm-mod kernel driver loaded. FOS Linux doesn’t support dynamically linked modules, so it will need to be compiled in. The vchange command is part of LVM. I don’t know off the top of my head if vchange is part of FOS Linux. If not the inits will need to be recompiled to include lvm commands.

    Understand I’m researching this as I write the post so it may seem a bit disjointed.
    As for the LUKS code bits, those will probably need to be compiled into the inits using buildroot. This is not something that is native to FOS Linux, but I assume could be added. Looking at the FOS Linux buildroot compiler I see a “cryptsetup” package that is available. So that’s a good sign. Looking into the FOS Linux buildroot config file the cryptsetup option is enabled BR2_PACKAGE_CRYPTSETUP=y so the binaries should be in the inits.

    So the only question then does the kernel have the required modules built in.
    Looking into the FOS Linux kernel config, dm crypt is not enabled. So this is going to be a problem.