Best posts made by jpmartin

@george1421 I restored the image as multicast and it errored on one machine after the image was downloaded. I forget the error it threw specifically but it complained about not being able to mount or unmount a partition.

That machine rebooted, then advanced to the same spot that the other was sitting.

It was a partclone screen saying “restoring image (-) to drive/device (/dev/sda1)” and I wasn’t able to hangout long enough to see if it advanced.

I’ll be back in the office in an hour or so, I can give an update then and provide any additional information that may be helpful if the imaging process didn’t finish. I’m hoping it figured itself out after I left for a meeting.

I’m an intern exploring Fog Project as a potential solution to some of our imaging issues, I’ll be sure to make the point that if we end up implementing Fog Project that we should make a donation to support the efforts.

@george1421

@george1421 said in Intel Raid0 Image Capture:

@jpmartin How many of these systems are you trying to restore at one time?

Just 2 right now. If it makes it to production it could easily be 25+ at a time.

Understand that each of these systems will need to be registered in FOG and their “Host Kernel Arguments” and “Host Primary Disk” updated to the new settings. I would recommend you create a new group assign these hosts to that group and then use the group update function to set these parameters for all hosts in that group. That way you can be sure they are all the same.

This is actually what I did. When I tried to edit those settings for the group, the Primary Disk and Bios Exit Type (Grub_First_HDD) didn’t “stick”. I’d click update and those fields would return to default values. When I viewed the 2 hosts individually, the values above were also cleared/reset to default so that very easily could have been the problem right there.

I just set them back to the correct settings individually and just finished a unicast deployment to the machine the image was created with.

I deleted the existing RAID0 array on that machine and renamed it to something different as well. Fog didn’t care. So I don’t think that was the issue.

Please also understand we are waking the bleeding edge here. We did just prove that unicast imaging worked. Throwing multicasting into the picture may expose some other bugs (since that wasn’t tested). The random /dev/sda1 is troubling. Now I didn’t go in and change the volume name to see if it messed with the /dev/md126 naming (I’ll do that later for completeness) I did notice under /dev/md/ there was a device with the name of the volume I created Volume0_0, but again we are referencing the logical names of /dev/md126 so the actual volume name should not matter.

Good to know. I’ll do what I can to break stuff and report what happened.

EDIT: Just to update, I corrected the settings for each host individually instead of using group management, created a multi-cast task for the group (I didn’t change any host settings on the group management page hoping it would use the host specific settings) and successfully imaged both hosts via multicast.