@thebrennan47 said in Fog freezes on boot at kernel_thread_helper:

We want to avoid upsetting our production environment if at all possible

I can understand your concern about not wanting to destabilize your environment.

But realize that the Windows 10 train is heading towards your environment very soon, so you WILL have to upgrade sooner or later. Also the 7040 is the last of the sky lake models the next generation are on kaby lake. Microsoft has intentionally crippled windows 7 to not run on kaby lake hardware (even though it ran fine earlier this year). So moving forward you will have to install win10 if you purchase new hardware. That day is coming. I’m only telling you what is coming down the road so you can plan for it.

As for ubuntu 12.04 that reached end of support in April of this year. So you will not receive any security updates for it if any are detected. That is also a pressure for you to upgrade.

The kernels that Tom posted about may work on the newer hardware, surely FOG 1.4.2’s kernels will run on that hardware. It might not integrate with FOG 0.3x very well, but it should run on the 7040 ok (I’m doing that today).

@FlareImp It looks like the TVNE-Fog server didn’t have the whole image. The pic on the left is larger (at least the d1p2.img is) than the one on the right.

@george1421 said in Remote node on different DHCP and subnet:

Not being able to alter the remote dhcp server is a problem but you can fix if you install dnsmasq on your storage node. Dnsmasq will then supply the pxe boot options you need.

It wouldn’t be a problem if the DHCP server didn’t have any 066/067 options. In this case it does. I think it’ll be hit or miss for proxy-dhcp working in this case. And if it works, it might intermittently work.

@UWPVIOLATOR said in Snapin Hash Issue:

But if we use any snapin from out master FOG the hash fails. In the temp folder it downloads 1KB

If the file on the server is whole, but not being downloaded to clients - this has to be some sort of network or security problem. It could be a content filter, a firewall, antivirus, anti-malware. You know your environment better than us - spend time thinking about what could possibly block the download.

@george1421 I have left work for the day, but will do so tomorrow morning. Thank you.

I forgot to mark my changes permanent across reboots. It’s chugging right along now. Thanks!

With FOG 1.3.x and newer there is a change in the process that is required for sysprep. You can install the fog client into your golden image before sysprep. But you must set the service to disabled. And then add to your golden image a setupcomplete.cmd batch file that enables the service. What happens is that the fog client doesn’t know that OOBE is still running so it starts doing its job too early in the imaging process causing OOBE to fail because the fog client reboots the system at an unexpected step in OOBE.

ref: https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#FOG_Client_with_Sysprep

Also you should consider upgrading to FOG 1.4.2 if you are still running on FOG 1.3.X

@sanman Well done. Thanks for letting us know. Might be helpful for other users as well. Marking this solved.

Yeah, the 1.3 RCs had lots and lots of bugs. Please update to the latest stable release.

@george1421 said in Replication Timing?:

First the generic recommendation. Please update FOG you are several versions behind and on an RC release that has a known bug with image resizing.

More than a generic one, this is a very strongly recommended and needed. We could end up wasting days on an issue in an RC that’s already fixed in the next stable release. Imagine asking Microsoft to help you fix something on a Windows 7 Beta copy.

@Wayne-Workman

Thanks!!

@ECRTechZ said in Copy images from dead 1.2.0 server to new 1.4.0 server:

The problem with those articles is that they assume the old server is accessible.

The guide only requires that ssh is accessible. The web interface can be nonfunctional. If you don’t have ssh, then yeah the only thing to do is mount the disk on another box as you’ve done and just copy the needed things from it.

Thanks to you for your responses so fast.
So I will not re-do a VM with bigger disk space since the installation.
Thus I will avoid endless recursive loops.

Tom and I chatted about this issue a little this morning. I think I have an explanation of why it worked when you removed one of the disks from the array.

Understand these are only anecdotal understandings of what might be going on.

Tom said you shouldn’t be able to image any array that is degraded or rebuilding. I said that the error was representing the hardware can’t keep up with the processor causing a thread to timeout. You created the array using the built in Intel Raid firmware and then attempted to image the computer. You couldn’t image because the inits were missing a critical utility. Your raid controller is one of those “fake-raid” controllers otherwise known as a hardware assisted software raid. Hardware assisted software raid relies on the main CPU for array activities. Unlike a hardware raid which has its own processor to manage the array, a software raid uses the main CPU’s extra processing capacity. Once the inits were fixed you booted into FOG and attempted to image the computer with an array. At the time FOS loaded on the target computer, it saw the array was uninitialized so linux started to rebuild the array.

This is where things went sideways.

Now consider what is going on here. The linux OS is trying to rebuild the array that wasn’t initialized using the main CPU. At the same time FOG is trying to push the image to the disk subsystem as fast as it can. So this is where you have a chicken and egg situation.

The OS is busy building the array at some rate of build, for the sake of argument lets say 70MB/s translate that over to 4.2GB/min. My fog server and target computer can push images at 6.2GB/min. At some point we are going to have a data collision between the array being built and FOG laying the image down on the disk. This may explain why it gets to about 5GB deployed and it crashes.

The other side of this is that the array is being built the same time FOG is laying down the image and the FOG thread has to way too long for the disk subsystem to complete and times out.

Understand the above is just based on noodling about this issue all day and not really based on any hard evidence.

In my case and on my test system. I found the utility was missing so I copied it from another server. Once the array came up the OS started building the array. Tom patched the inits and wanted me to confirm they worked before he pushed them to the production server. I was in debug mode just watching the array rebuild so I updated the inits and rebooted the test box (mind you I’m doing this debugging remotely). The box rebooted, but I forgot it was in debug deploy mode, so I lost access to the box remotely. Deciding to call it a night I logged out of the dev system. Now that dev pxe target computer was running all night. Since the OS was up it was rebuilding the array. When I came in, in the morning I keyed in fog on the console and it started to deploy. Since I was only pushing out a 5GB image AND the array was already built it deployed correctly.

So what to do for the next time?

I guess if you are building an array and its initialized, pxe boot the target computer into hardware compatibility mode and let it sit until its disk activity is done. If we run across a lot of raid systems we might add a function to the hardware compatibility tests to report the percentage of array synchronization. I wouldn’t want to ask the developers to spend time on this for just a one off situation. But its something to consider.

I had an IM session with the OP.

this is what was posted in chat as the error message [when i say Perform full host registration and inventory, i get "Error parsing PCC subspaces from PCCT]

This seems to be a linux kernel issue with the lenovo and not specifically FOG.

ref:https://askubuntu.com/questions/670509/error-parsing-pcc-subspaces-from-pcct-acpi-pcc-probe-failed
ref: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1528684

target computer in question: Lenovo E440

@cjesso Yes please.

Updated the file on sourceforge. Unfortunately something’s not working on my scripts, though having it say a weird number is not really the end of the world. I’ve updated the file from the tags and all appears to be correct.
I cannot upload into github at the moment due to some service outages apparently.

@george1421 said in Upgrade from Trunk to 1.4.2 Failed:

@Avaryan Now that you know your password attempt to log into your database from the linux command line mysql -u root -p fog then provide your database password.

Our live FOG server is now on 1.4.2, revision 6072. Thanks! Now to figure out how that password got changed…

edit: You can mark this as solved.

@Tom-Elliott
Hey Tom saw your post in the other thread earlier. Working now thanks!

@Junkhacker said in Installed FOG, what now?:

fog isn’t used for “installing” operating systems.

I would highly recommend hashicorp’s Packer for that. They need to support fog. Maybe I can help make that happen.