Is there a way to make FOG compatible with LUKS encryption?
I want to manage my company’s computers with FOG and they all use LUKS encryption, If I clone a previously encrypted computer it tells me that the UID of the disk does not match, and if I clone a non-encrypted computer, to encrypt it, it is necessary to format it, so cloning would not make sense if the data is going to be lost. Thanks for any help you can offer me.
The problem I have now is that the original machine is 34 GB and the cloned machine is 54 GB and there is unallocated disk space left. How could I extend the encrypted partition to fill the entire disk?
Now that part will definitely take some more work on the inits as we’d need to rework the resize functions and add LVM support. @Wayne-Workman said her might look into this but will take time.
@luistemporal @Sebastian-Roth @george1421 I solved this error by re-capturing the image and re-deploying with “Single Disk”. The disk decrypts correctly on the cloned machine. The problem I have now is that the original machine is 34 GB and the cloned machine is 54 GB and there is unallocated disk space left. How could I extend the encrypted partition to fill the entire disk?
@luistemporal @Sebastian-Roth @george1421 I have renamed the init and kernel of my FOG server to .backup and added the new files, restarted the Apache service and changed the image type from “Raw Image” to “Single Disk”, and when I try to deploy the image on a new machine, I get the following error:
These are the commands I have executed on the FOG server:
114 locate init.xz 115 locate bzImage 116 sudo mv /var/www/html/fog/service/ipxe/init.xz /var/www/html/fog/service/ipxe/init.xz.backup 117 sudo mv /var/www/html/fog/service/ipxe/bzImage /var/www/html/fog/service/ipxe/bzImage.backup 118 sudo mv /home/administrator/bzImage-luks /var/www/html/fog/service/ipxe/bzImage 119 sudo mv /home/administrator/init-luks.xz /var/www/html/fog/service/ipxe/init.xz 120 sudo systemctl restart apache2.service 121 sudo systemctl status apache2.service 122 sudo chown -R fogproject:root /images/* 123 sudo chmod a+rwx /images/* 124 sudo systemctl restart apache2.service 125 history
@george1421 Thanks! Looking through the kernel config again I saw
CONFIG_CRYPTO_SHA512_SSSE3. Do you think those would be helpful here as well?
The Gentoo wiki mentions TrueCrypt/VeraCrypt compatibility by adding “User-space interface…” as well as “FUSE (Filesystem in Userspace) support” options in the kernel. Anyone keen to use that as well?
@sebastian-roth I started researching this on thursday. i didn’t get very far but stopped after I found some basis info. This is a bit disjointed but it gave me some interesting clues.
linux on ARM https://www.snbforums.com/threads/cryptsetup-kernel-modules.46607/ CONFIG_MD=y CONFIG_BLK_DEV_MD=m CONFIG_BLK_DEV_DM=m CONFIG_DM_CRYPT=m CONFIG_CRYPTO_XTS=m CONFIG_CRYPTO_SHA256=m # Modules for crypto device dm-mod dm-crypt aes twofish sha256 https://wiki.gentoo.org/wiki/Dm-crypt [*] Enable loadable module support Device Drivers ---> [*] Multiple devices driver support (RAID and LVM) ---> <*> Device mapper support <*> Crypt target support [*] Cryptographic API ---> <*> XTS support <*> SHA224 and SHA256 digest algorithm <*> AES cipher algorithms <*> AES cipher algorithms (x86_64) <*> User-space interface for hash algorithms <*> User-space interface for symmetric key cipher algorithms Device Drivers ---> [*] Block Devices ---> <*> Loopback device support File systems ---> <*> FUSE (Filesystem in Userspace) support [*] Cryptographic API ---> <*> RIPEMD-160 digest algorithm <*> SHA384 and SHA512 digest algorithms <*> Whirlpool digest algorithms <*> LRW support <*> Serpent cipher algorithm <*> Twofish cipher algorithm
Yes I remember there was something I needed to do with openssl in the inits and add in dm_crypt I think. I was going to open the init I had from that time to see if I put anything else in there.
I added “CONFIG_CRYPTO_AES_NI_INTEL” version because it can take advantage of the hardware crypto engine built into some intel processors.
Edit: Do you remember why you added
DM_PERSISTENT_DATAand so on? My current config diff looks like this:
diff --git a/configs/kernelx64.config b/configs/kernelx64.config --- a/configs/kernelx64.config +++ b/configs/kernelx64.config @@ -1324,7 +1324,7 @@ CONFIG_BLK_DEV_DM_BUILTIN=y CONFIG_BLK_DEV_DM=y # CONFIG_DM_DEBUG is not set # CONFIG_DM_UNSTRIPED is not set -# CONFIG_DM_CRYPT is not set +CONFIG_DM_CRYPT=y # CONFIG_DM_SNAPSHOT is not set # CONFIG_DM_THIN_PROVISIONING is not set # CONFIG_DM_CACHE is not set @@ -3459,8 +3459,10 @@ CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_NULL2=y # CONFIG_CRYPTO_PCRYPT is not set -# CONFIG_CRYPTO_CRYPTD is not set +CONFIG_CRYPTO_CRYPTD=y CONFIG_CRYPTO_AUTHENC=y +CONFIG_CRYPTO_SIMD=y +CONFIG_CRYPTO_GLUE_HELPER_X86=y # # Public-key cryptography @@ -3495,12 +3497,12 @@ CONFIG_CRYPTO_ECB=y # CONFIG_CRYPTO_LRW is not set # CONFIG_CRYPTO_OFB is not set # CONFIG_CRYPTO_PCBC is not set -# CONFIG_CRYPTO_XTS is not set +CONFIG_CRYPTO_XTS=y # CONFIG_CRYPTO_KEYWRAP is not set # CONFIG_CRYPTO_NHPOLY1305_SSE2 is not set # CONFIG_CRYPTO_NHPOLY1305_AVX2 is not set # CONFIG_CRYPTO_ADIANTUM is not set -# CONFIG_CRYPTO_ESSIV is not set +CONFIG_CRYPTO_ESSIV=y # # Hash modes @@ -3551,7 +3553,7 @@ CONFIG_CRYPTO_SHA512=y # CONFIG_CRYPTO_AES=y # CONFIG_CRYPTO_AES_TI is not set -# CONFIG_CRYPTO_AES_NI_INTEL is not set +CONFIG_CRYPTO_AES_NI_INTEL=y # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_BLOWFISH_X86_64 is not set # CONFIG_CRYPTO_CAMELLIA is not set
Edit4: Looks like we also need openssl binaries in the inits (ref. I will add that to the official inits.
@LuisTemporal I will add this stuff to the official kernel/init and push out a new test build soon.
I’ll start digging into the kernel modules and what needs to be added to the inits to support LUKS. I did it once, so I’m guessing I can repeat the process.
Thanks heaps, that’d be great!
I suppose I need to write a tutorial to that the content doesn’t get lost with time.
Not sure if it’s worth it as I plan to add this stuff to the official configs.
@sebastian-roth I’ll start digging into the kernel modules and what needs to be added to the inits to support LUKS. I did it once, so I’m guessing I can repeat the process.
I suppose I need to write a tutorial to that the content doesn’t get lost with time.
The link that I referenced was an OP who solved the issues. I do still have the kernel and inits i created back then if you want to test them.
Found a bit more time to actually read through the other topic. Didn’t think we are that close to it already. Well at least the very basics of reading from a LUKS encrypted partition. All the fuzz about LVM creation and setting up LUKS on deployments is a whole new story though.
You are right, the forum files were lost and so we don’t have the configs you uploaded back then. But I think it shouldn’t be too much of an effort to re-work what was needed to get this to work. Using your old kernel/init binaries is fine for a quick test but I can offer to add this to the official kernel and init.
@Wayne-Workman You are more than welcome to tackle this as a whole!! Not sure if you want to start with deployment of simple LUKS setups (no LVM) and then add LVM as well. Or take if the other route and dig into LVM first. Whatever suites you best.
@wayne-workman The link that I referenced was an OP who solved the issues. I do still have the kernel and inits i created back then if you want to test them.
Wayne Workman last edited by
For what it’s worth, I’d be interested in this also. I use nothing but LUKS at home. DD and RAW is slow, would be great for FOG to handle the creation of the needed LVM pieces /w encryption. I’d like to figure it out, but that’s probably a year or more away for me.
@LuisTemporal What exactly is your aim with LUKS? You should be able to use dd-style cloning.
There was someone else in the forum that used LUKS encryption. At that time I had to make a one-off kernel that supported the encryption process, to where it would open and read an encrypted volume.
Through some google-fu I did find that thread here: https://forums.fogproject.org/topic/13845/error-decrypting-luks-partition-prior-to-capture-imaging?lang=en-US&page=1
Unfortunately I don’t have access to the dev environment i used to create the kernel in 2019 and the FOG Project forum had an issue last year where it lost all of the attachments so I don’t know what I posted in the kernel changes at the moment. I’m pretty sure I have the kernel and init from that time though in my google drive.