@george1421 We did get this working.

ALthough the problem specifically here with not network booting had to do more with the fact the keyboard was not recognizable.

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.

@Wayne-Workman I updated to RC12 yesterday. Captured using multi partition and single disk, re-deployed to test both and everything is now working! Thanks for all your hard work on this @Tom-Elliott!

@Tom-Elliott already done 🙂

@Wayne-Workman I got it working. I must have messed up the passwords. I fixed it so the user pass matched the .fogsettings password and replication started working. Thank you.

@rbaldwin Sounds like you found and fixed the issue. Yes PIM (modes) is definitely a good keyword. Marking this solved now. Hope that others might stumble upon this and find it helpful as well.

@Tom-Elliott Thanks, it works!

Thanks,
re-ran through the change over process and all seems to be working, just need to test a deployment etc, Thank You all for your help.

Well if it’s not harmful then that’s great. Wanted to make sure I didn’t break anything.

Ok - found my problem - those dates in the Fog log got me to wondering why there weren’t any recent entries… Service was not starting - I had not updated my SetupComplete.cmd for the new client that I included in the new image:

Old client SetupComplete.cmd command to start the service:

sc config “Fog Service” start= auto

New Client SetupComplete.cmd command to start the service:

sc config “FogService” start= auto

Voila! Working again! Thanks for your input - I will probably rebuild a clean image at some point, but this got my old patchwork image going!

@Jaymes-Driver @Tom-Elliott

Thank you so much for your help. I am up and running now on 1.3.5 RC 11.

@Grizzly Also tested this on an Lenovo X230 image I created in 1.2 that works as well. Thanks for the fixes!

@Tom-Elliott Worked Great!!!

@ozraelised I should probably have read more into this thread, Fedora 25 at the moment has issues with rcpbind, it doesn’t even run the installer correctly. It’s an official bug, and I think the Fedora devs are swamped at the moment (think they are secretly working on RHEL 8).

@lesliebright We all do dumb stuff, but only the men among us admit it.

@Wayne-Workman Wayne thank you for the reply. I used the that Junkhacker posted. It worked very.
https://blog.vbonhomme.fr/extend-a-lvm-partition-after-increasing-its-virtual-disk-on-virtualbox/

@Tom-Elliott this fixed the issue!

Thank you very much!

@george1421 Thanks for clarifying. The ftp server was the problem. The “Updating Database” confused me into thinking, the fog database fails to update.

@bmick10 yes. I’ve been working pretty hard on the units lately I’ll try to figure this out tonight.

@butch2861 As the Church Lady once said, “Well isn’t that special…”

Now that we know its a hardware class specific error. I wonder if this hardware is having a problem with the 64 bit kernel. We have seen some specialty hardware that has a 64bit CPU but externally its 32bit. I’m not saying this is specialty hardware, it could be similar in function.

I wonder what the results would be if you went into the host definition (You may have to manually register it if the kernel is panicing) set the kernel to bzImage_32 and the inits to init_32.xz This will force FOG to send the 32bit kernels to the client no matter what it reports to iPXE.

From your other screen shot I see 2011. Is the firmware the latest version available for this hardware. Lenovo has been known to have flaky early release firmware.