Deployment stuck in a loop, never finishes imaging?

[salted_cashews]

@Sebastian-Roth Interesting, so a simple update to the latest build seems to be a solution? I remember you saying (about a month ago no less) that you guys were releasing a new version. Interesting, I really need to keep hounding my superiors lol.

[Sebastian Roth]

@salted_cashews No, we have not included this patch to FOG yet. This is new to me as well. Just stumbled upon this when looking for a solution.

A new version (1.5.6) was released a couple of days ago but as you see we are always on the edge of trying to solve all the issues that arise. So new releases will come… You need to know that we don’t have a strict release schedule. We are a very small team of developers and sometimes there is very little time while we have a bit more at other times. So sometimes there might be a new release in just two weeks and sometimes it takes months.

[Sebastian Roth]

@salted_cashews Would you be keen to test new init files (manual download of inits and possibly kernel binaries) if I provide those for you? Should find enough time by the end of this week.

[salted_cashews]

@Sebastian-Roth Certainly so! I won’t have to worry about these new kernels breaking any working images would I? Would making a backup beforehand be a wise choice?

Also, I appreciate the work you guys do here very much. I understand you’re all doing this in your own time and that changes might come sooner or later. I’ve learned quite a lot from using FOG as a whole and speaking with you and everyone on the forums. Anything I can do to help I’m willing to jump in.

[Sebastian Roth]

@salted_cashews Ok, just finished building new inits with Zstd 1.4.0 that you can try out. I’d suggest you put the kernel and init binary alongside with the original ones instead of swapping those. This way you can test without causing any harm.

On you FOG server run (suppose you have 64 bit machines here):

sudo su -
cd /var/www/html/fog/service/ipxe
wget https://fogproject.org/kernels/Kernel.TomElliott.4.19.36.64
wget https://fogproject.org/inits/init_zstd-1.4.0.xz
chmod 666 Kernel.TomElliott.4.19.36.64 init_zstd-1.4.0.xz

Better if you do a chown ... on the files but as I don’t know your OS webserver username I thought I’d do it this way.

Now go to the FOG web UI, edit the hosts settings of the machine you capture the image from and set Host Kernel to Kernel.TomElliott.4.19.36.64 and Host Init to init_zstd-1.4.0.xz. Now schedule a capture task, let it grab the whole image and then try to deploy that new image again.

Not sure if you need to set Host Kernel and Host Init on the deploy host as well. From my point of view it’s the capture that breaks the image and deployment using the old-fashioned kernel/init might still work.

[salted_cashews]

@Sebastian-Roth Unfortunately the machine in question has been imaged over, so the original image that is now broken no longer exists aside from the copy on the FOG server. Should I still try using those Kernels on deployment? I know you said the capture might’ve been the problem though.

[Sebastian Roth]

@salted_cashews I am fairly sure the image was corrupted when capturing it already. So I don’t think that deploying with the new init/kernel will help. But you might still give it a try. You never know.

[salted_cashews]

@Sebastian-Roth True, I’ve elected to at least give it a go. I did notice the image progress screen was a bit off, is this the init/kernel?

[Sebastian Roth]

@salted_cashews Strange, no idea why that is?!

[salted_cashews]

@Sebastian-Roth Haha, no worries. Unfortunately it didn’t work but this certainly was an interesting learning experience. This has made me curious: Does the task via the GUI and task on the client both have to be restarted (i.e. the computer rebooted and the old task killed, new task created) in order for an image to be deployed? I only ask because I’ve been using debug mode quite a bit but noticed I couldn’t start a new task without rebooting the client first. I would try to schedule a new task via the GUI but it would only take the old one when I ran “fog” at the CLI. From my perspective this makes sense as the FOS is deployed after PXE boot and that FOS contains only the information it was given from that correct?

[Junkhacker]

@salted_cashews i think the issue you’re describing is because the FOS hits the problem and bails before the step where it checks in with the web interface to say it’s done.

[salted_cashews]

@Junkhacker Ah, that makes sense now that I think about it.

[Sebastian Roth]

@salted_cashews So the master installation is lost? Too bad. Think there is nothing we can do as the last image capture is incomplete and we can’t get that extracted. Hmmmmmm

[salted_cashews]

@Sebastian-Roth Yeah, it was honestly my fault. Normally I’d capture and deploy immediately after to test, but these past few weeks have been ridiculously insane for me and my machine to image allocations haven’t been as up to date as they normally would’ve been.

I noticed this happened once before with a Windows image, but it was related to the dirty bit and another issue I found here. All in all I wanted to at least report and give this a go, I apologize for taking your time but as always appreciate the help. If this does happen again, I’ll be sure to give those kernels a go and report back here the results.