Issues with capturing an image with a raid0 array.

[45lightrain]

I am trying to capture an Ubuntu server 22.04 image with a raid0 array set up so that I can roll back to this base image without having to recreate the array.

The OS is on a SATA SSD while the raid array is made from x2 NVMe drives in a dual slot nvme card.
nvme0n1 and nvme1n1
Unfortunately Fog appears to be having issues with my NVMes
Is there a fix for this?

another issue I have is when I deploy an image it gets imaged to the NVMe and not the SATA SSD, is there a solution for this as well?
I have been bypassing this by removing the NVMe card but it would be nice not to have this issue anymore.

[george1421]

@45lightrain how did you create the raid 0 array? From within linux or using the intel rst controller?

FWIW: I have not been able to make the vroc arrays work with FOG, but if you have ubuntu loaded on a vroc array then it has to work and we need to talk.

If you created the array with intel rst or using a software raid created by ubuntu then you have some luck. The first thing I would do is go into the fog global settings and look for kernel parameters field. Then add mdraid-true into that field. That tells the fos linux kernel to look for a raid array.

Next I would schedule a capture or deploy image, but before you hit the schedule task button, tick the debug checkbox.

PXE boot the target computer, after a few screens of text you need to clear with the enter key you will be dropped to the fos linux command prompt. Key in lsblk to see if FOS Linux assembled your array for you. It will probably be listed as /dev/md0, or /dev/md126 or 127. If its there THAT is the device name you need to key into the host record for this target computer in the hard drive field. This way FOG will not try to use one of the nvme drive, but the raid device.

If the device is not automatically detected you may need to assemble the array, but lets first start with making sure you have the kernel parameter set and that fos linux sees the array.

[45lightrain]

@george1421
This did the trick!
Thank you!
My raid array was made with software raid on Ubuntu.

FOS recognized and assembled the raid array!
with that I updated the hard drive field.
I am now able to capture and deploy the OS with no issues!

Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?
While testing the solution you provided I captured and deployed the OS a handful of times but unfortunately the data on the raid array remains intact and doesn’t revert back to the state it was when the OS was initially captured.

Is there a solution for this or does FOG not have the ability to capture and deploy raid array data on a separate drive that isn’t the OS?
Using your solution I created a new image and set the host drive to the raid array from FOS to see if I could capture just the raid array data but it won’t be captured due to it not having linux/resizable partitions

@george1421
This did the trick!
Thank you!
My raid array was made with software raid on Ubuntu.

FOS recognized and assembled the raid array!
with that I updated the hard drive field.
I am now able to capture and deploy the OS with no issues!

Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?
While testing the solution you provided I captured and deployed the OS a handful of times but unfortunately the data on the raid array remains intact and doesn’t revert back to the state it was when the OS was initially captured.

Is there a solution for this or does FOG not have the ability to capture and deploy raid array data on a separate drive that isn’t the OS?
Using your solution I created a new image and set the host drive to the raid array from FOS to see if I could capture just the raid array data but it won’t be captured due to it not having linux/resizable partitions

[george1421]

@45lightrain said in Issues with capturing an image with a raid0 array.:

Also is fog able to capture both the OS SSD data and raid array data on the NVMe drives?

FOG captures disks in block mode. It doesn’t care about partitions (mostly). Also make sure that md0 is the true device for these drives. When you are in the FOS linux shell you can / should create a mount point and then mount /dev/mdX partition to see if you can read the content. I have seen where sometimes md0 is created but the real raid array is /dev/md126.

Also FOG calls a script before imaging starts. Sometimes its needed to assemble the array in this postinit script. Or do other things to prep the system for imaging. So the postinit script (found in the /images directory on the fog server) is a the place to put that code.

Also when you start in debug mode (when debugging the imaging process) you can actually start the imaging process from the command line by keying in fog. The imaging will stop at each debugPause; command in the imaging code as a breakpoint. If you notice something wrong, you can hit ctrl-C to exit back to the command prompt. To restart the imaging process again just rekey in fog.

While it doesn’t exactly apply here I wrote an article 8 years ago about imaging using the intel rst adapter that may contain a nugget of help: https://forums.fogproject.org/topic/7882/capture-deploy-to-target-computers-using-intel-rapid-storage-onboard-raid