Image Captures correctly seemingly, but deletes itself when deploying.
-
I just captured an image via Windows 10 sysprep (I have captured many before in the exact same way). It shows on the fog server as being 18GiB. Then immediately when I try to deploy it (multicast if that matters) I get a GPT partition error (see attatched) and then the image shows 0iB from the web management! I’ve never had this happen before and am capturing this image the same way I always have (including several in the past few weeks) the only difference is installed programs. This has happened twice in a row with the same image and same multicast deploy task. I’m posting here because I really don’t want to go through the trouble of creating this image a 3rd time if there’s something bigger going on.
-
I see you are using an older version of FOG. I don’t think that is the issue here, but just note is 4 minor releases behind current.
Now can you look in fog host server in the /images/Lab directory is there files in there, specifically d1.mbr?
-
Yes d1.mbr is there
-
@TBCS The target computer, does it have a sata disk or an nvme disk?
-
It has a SATA disk, I did capture it from an nvme machine though. Do I need to be sure to capture from the same type of disk?
-
@TBCS said in Image Captures correctly seemingly, but deletes itself when deploying.:
Do I need to be sure to capture from the same type of disk?
I don’t have a solid answer for you on this. The developers might know better than I. Just to be clear the target driver is exactly the same size or larger than the source disk?
BTW there is another thread active right now with exactly the same issue as yours but with a newer version of FOG.
-
@george1421 said in Image Captures correctly seemingly, but deletes itself when deploying.:
Do I need to be sure to capture from the same type of disk?
No. We have successfully captured and deployed across different disk models (SATA, ATAPI, NVMe, …). What’s causing the issue is mostly the partition layout itself.
Please schedule another deploy task for this machine but this time make sure you enable the checkbox for debug just before you hit the create task button. Boot the host, hit ENTER twice to get to the shell and start deploying using the command
fog. Step through till you hit the error again which should bring you back to the command shell. Then run this manually:sgdisk -gl /images/Lab/d1.mbr /dev/sda, take a picture of the screen and post here. -
I’m sorry I haven’t had a chance to do that yet, I can soon and I’ll get that file. But I do know the issue happens on all multicast attempts (even though we normally use them) and not any normal image install attempts. Unfortunately we have 300+ computers to image and not using multicast to do them in larger groups is very slow. Do you know of any common issues where normal image deploy works and multicast throws that error? Also now the error is slightly different. It’s getting to the part clone screen but just hanging before any progress bars show up.
-
@TBCS said in Image Captures correctly seemingly, but deletes itself when deploying.:
Do you know of any common issues where normal image deploy works and multicast throws that error?
No! The scripts for “normal” aka unicast deploy and multicast are the same when it comes to partition layout stuff. There is really no difference and I can’t see multicast causing this issue.
Also now the error is slightly different. It’s getting to the part clone screen but just hanging before any progress bars show up.
Ahhh, here we go. You need to be very precise in your error description because otherwise we’ll all go down the wrong road. The “hang” on the blue partclone screen is because it cannot start the multicast session. This has nothing to do with the aforementioned
sgdiskeror whatsoever. I ask you to always take a picture of the most current error screen and post here. If you just say there is still an error we assume it’s exactly the same and will give the wrong advice. Even if you think it’s the same you might still take a new picture and post that here because sometimes it’s just nuances that we see in pictures leading to the right answer. It’s up to you to provide information as good as you can for us to be able to help.Ok, how do you fix the blue partclone screen hang?
- Cancel all old multicast tasks in the web UI, check
/var/log/fog/multicast.logto make sure there is no task left and then reboot your FOG server just to make sure! - Be aware that multicast defines a number of hosts (either through group multicasting or if you start a named multicast session manually) and it won’t start if a single one of the hosts is missing!
- Cancel all old multicast tasks in the web UI, check
-
Unfotunately the last time I tested it I rebooted the server, and used only 2 machines to test the multicast and it still hung at the part clone screen. The way I “fixed” the first error was remaking the image under a different name. I’ve tried multiple multicasts after multiple reboots even prior to your suggestion and it still hangs at the part clone screen. I can take a picture when I go in and test it again today, it seems to hang earlier than even when waiting for all members to join the session.
-
The forum is actually giving me an error when I try to upload the image, but the box in the middle of the part clone page doesn’t even show up, nor do the progress bars. I have updated fog, restarted fog, and am testing multicast with only 2 devices. I’m very confused at this point. @Sebastian-Roth
-
-
@TBCS This is exactly the point where hosts seem to “hang” (actually wait) if the cannot join the multicast session. Please check the log file mentioned before und post the full log here.
-
I do want to post the log file as we’re still working on this, I’ve checked all the settings on my network I can think of related to multicast and can’t find anything that will fix it (especially since this has always worked until a week ago) But when I schedule a debug task, it’s not for a multicast session which is the only thing we’re having problems with. Is this log still useful when the image deploys fine normally?
-
@TBCS You are right, can’t do debug in multicast mode. I should have stated more clear. The debug was only meant to figure out the
sgdisk ....issue. Not the multicast one. This happens when we talk about different issues in the same topic…Logs are always welcome. More information is always better than none.
