Why would you want to run both clonezilla and FOG? FOG uses partclone which is the same program clonezilla uses. That said, it’s one thing if you wanted to use a CloneZilla Image on a host. We do have support for that, by simple creating the Image definition and setting the Image Manager to Uncompressed. FOG, however, has many more options readily available and configurable via the GUI. Again, this is not to say you cannot use Clonezilla images with FOG. However, FOG manages hosts, inventory, images, and much more through a simple web gui. Running clonezilla is possible, but still means you have the manual tasks to complete.
I guess we need to understand the why of this more so we can try to help you out more.
@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.