The init’s up right now have had a minor correction to address the problem presented here.

The issue was a switch from WGET to Curl. As we switched to curl, a piece of extra information was being passed not allowing the request to return the proper data.

I’ve corrected this in the latest, though you will likely need to install the working-1.3.5 branch to see the change. That or you can download the current inits directly with:

wget -O /var/www/fog/service/ipxe/init.xz https://fogproject.org/inits/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz https://fogproject.org/inits/init_32.xz

Two things,

First maybe try RC 12 of 1.3.5? I believe there was an issue with the legacy client on 1.3.4 that I’m pretty sure was addressed during one of the RC’s of 1.3.5.

Second, I’d recommend updating your clients to the new client. The legacy client, while still supported currently, is rather outdated and inefficient, and less stable the “newer” the OS applied to.

The legacy client was designed around when Windows XP was the “big” thing, which was from 2007 until about 2009. It didn’t change much between 2009 and 2013 (which FOG 1.X.X was released.)

With the release of 1.3.X came a new client. This new client is far faster, and less resource intensive to the servers than the legacy clients, and comes with a lot more security factors as well. I would highly recommend updating to the RC’s and even more so suggest updating to use the New FOG Client.

Also, please ensure the /images/.mntcheck and /images/dev/.mntcheck files are present.

These are just empty files but they’re used to detect that the NFS is indeed connected.

This can be done with:

sudo touch /images/{,dev/}.mntcheck && sudo chmod -R 777 /images

Feel I might like to add on.

A lot of work has gone into the resizing and uuid settings of the imaging process and I believe this is what was causing your “blinking cursor”. Would you mind updating to the latest RC (13 as of this writing) to see if your devices are now able to successfully boot?

@Junkhacker Not quite.

The image would need to be recaptured first.

That’s what we are hoping for. All of us IT people being able to go home without a worry and feeling “accomplished”.

Glad it worked.

For what it’s worth, the new client will also enable your hosts to “re-associate” themselves. There is a little involvement as you will have to “approve” the hosts, but you don’t even need to go through the whole registration process.

This REALLY sounds/looks like the “bootfile” in use right now is still set to pxelinux.0

@BardWood This particular error, to me, appears to be trying to place a “larger” partition layout than the current disk can accept.

@cleric.marcos What do you mean?

Is your dhcp server trying to hand out pxelinux.0

@oraniko Either you want us to help you fix the issue or you want to do your own thing.

FOG RC 15 and 16 where both released 15 actually hopefully having a fix to the problem you’re describing.

If you really want to go back to 1.3.3 that’s up to you, but doesn’t help us fix what the problem actually is.

@BardWood What do you mean you haven’t been able to capture? Is it because you want to deploy the image to a system first, then capture, or are you having issues capturing altogether?

@cajos001 It was removed because USB Printers are local to the machine in which they reside.

Managing a printer that is going to be local to a single machine is “out of scope” of management within FOG. Think of it this way:

FOG Manages multiple hosts. Part of the way the client works is based on the communication back to the FOG Server. If a USB Printer is plugged in, regardless of FOG Client being on a machine, the printer is available only to that machine. How should FOG manage this printer (or better why?) It’s going to be available no matter what the FOG Client does in regards to handling the printer. If you take a USB Printer within the FOG Printer management system, and apply that to all of your hosts, the only host that will have access to the printer is the host that actually has it connected.

Now if the only reason you’re wanting USB printer support on the client is to tell the client where to download the drivers for that printer, you may be better off actually telling the System WHERE to look at drivers in general.

I understand that this isn’t necessarily the answer you want to hear. I see it from both sides, but ultimately I have to side with the decision to make “printer management” handled in a more “networking-based” fashion. The client can actually assign a valid and usable printer to any/all hosts and know it will work the same from one host to the next.

While I doubt this will fix the problem, I do hope to have a nicer approach to having a device receive an IP Address now.

As stated before, the current mechanism just waited for “ANY” ip address to be assigned to any NIC as needed. As long as it received an IP address (regardless of if that IP could communicate to the FOG Server) it would break out and try “driving” forward with the tasking.

I’ve added what I hope will allow a more dynamic approach to detecting the real fog network. Would you mind giving a try using the init’s and instructions here:

wget -O /var/www/fog/service/ipxe/init.xz http://mastacontrola.com/init.xz
wget -O /var/www/fog/service/ipxe/init_32.xz http://mastacontrola.com/init_32.xz

With this, you’ll also get the latest fixes from last night in regards to resizing code bits and what not. (This isn’t a bad thing)

@BardWood Progress isn’t new, persay, I just have it always showing now.

Theoretically it’s actually possible to upgrade from all the way back in the 0.9.12 days of the FOG Client.

That said, can you provide the logs of one of the systems who’s failing to update to 0.11.5? Can you provide the logs of the one of the systems that are failing to start their service automatically?

Would you mind updating to 1.3.5 now that it’s been released?

Mind running the installer as root?

The message it’s showing is configure is not allowed to run.

You may also want to try:

mount -o remount,exec /tmp

This should ensure you can execute within the tmp folder. If you do have to do the mount command, restart the server when done installing to ensure all the folders are mounted as they’re expected.

@lebrun78 I don’t understand still.

Size is new from 0.32 to 1.3.5 and should be added once you perform an imaging task.

OS and Type? What do you mean? OS would be defined based on the “hostOS” field. If the hostOS field wasn’t set, the image property probably wouldn’t be set to the image. (This changed, hosts no longer contain the “OS” as it’s image dependent.) Type? I guess you mean Partclone vs. partimage?

Found the issue.

The maxClients field was being scanned for. This only allowed a “maxClients” of between 1 and 9999. The idea for this range was to get nodes that were not set to 0 max clients. I was trying to make the sql handle the return, but this would imply some form of array to search for. I just moved the check to look if it is less than 1.

The “enforce” users item is a host specific setting.

It’s kind of a corrupt representation too.

Make sure the host has the setting defined. Not just by looking, but updating the host in question as well.

In the GUI goto Host->Edit the specific host->Active directory->Check the enforce box AND press to update.

The last part is important. The enforce checkbox selector is “defaulted” based on what’s set in the global settings if it’s not already set. I do plan to try correcting the behaviour, but figured it’d be good to know here as well.

YOU NEED TO UPDATE THE HOST, DO NOT JUST LOOK AND SAY OOOOO IT’S CHECKED. While it displays as such, it does not mean that it actually is set.

@george1421 1.3.5 should automatically be installing php7.1 now for them. Makes me wonder how the program is being started?

Please check your /opt/fog/.fogsettings.

Remove the php_ver and php_verAdd and packages lines, then rerun the installer.