Can you ensure that the timezone listed in the FOG settings is correct, as well as the timezone listed in the /etc/php.ini config file? Lastly ensure the linux clock on the FOG server is accurate.

@Dino_Nerd Were you able to complete the steps that Sebastian requested

@Dino_Nerd Can you access/download the picture (http://192.168.0.15/fog/service/ipxe/bg.png) or the kernel (http://192.168.0.15/fog/service/ipxe/bzImage) from your browser?

If you can then the web bits are in place and correct.

Just to be sure you did set selinux to permissive right?

In regards to #1 when you installed 1.4.3 you will have the latest kernel. There is no need to download again. That doesn’t address your issue, but know that you have the latest kernel.

I have to ask you, did you make any changes to the linux user called fog this is not the default web ui user account, this is the linux account. That account is an internal account used by the FOG application. I’ve seen people attempt to use/change the password on that linux account and use it for system administration. Doing so will break FOG.

As for your isc-dhcp config file, we really need to see it to identify what’s wrong. There is a great example of what the config file needs to be if you review this document (example 1) : https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

@Tom-Elliott Dude everyone here gets it and appreciates what you do! Thanks for everything!

@sjensen said in Moving FOG virtual server to a new server.:

@Wayne-Workman is there a specific process you used? Did you export the VM?

No, I migrated. This is a Hyper-V feature.

@Avaryan That did the trick! I had a feeling it was just a location problem. I can now boot to the ISO. Thanks for the help!

@george1421 Ok, makes sense, except can’t do a Mac VM, but like you said, that’s not as important than expanding the disk…

Thanks

Based on the timeframe that this bug was submitted (may 2017) i’m guessing this is only a problem on Hyper-v builds 1703 (as available in, win 10 ent x64-1703, hyper-v server 2016-build 1703, win server 2016 w/ hyper-v build 1703). Most likely the issues are being caused by the ARP protocol problem found only in Gen 2 vms in the PXE stack of hyper-v build 1703. See this Microsoft forum post for more details on how ARP was broken in this build. Still no resolution to my knowledge, but this post is most likely what will drive the fix from M$'s perspective.

https://social.technet.microsoft.com/Forums/en-US/436c67cb-1c7d-4c5f-8f62-3518a0cfaeb4/hyperv-build-1703-generation-2-pxe-has-faulty-arp-implementation?forum=winserverhyperv

We have several PXE server in the same vlan, three FOG servers and one LanDesk server. We control the access to the PXE using a little daemon in the different FOG servers that update the dnsmasq.conf file with the mac of the computers that have an active task. Is simply but effective.

Historically, this option has been empty and this change may lead to unforeseen side effects.

The “port-security” option is configured enable to avoid the loops and the possibility of using virtual machines without NAT.

@Sebastian-Roth

Yes. In the hour field 0, 23/2

@Benjamin_D It’s probably just easier at that point to just start off with a storage node setup. There are some articles about it on the wiki and we can help you if needed as well of course.

Oh, even simpler, Turn off “Task Reboot” on the hosts client/service settings. Or even better, just turn off the “force” reboot portion from FOG Configuration Page->FOG Settings->FOG Client - Task Reboot->FOG_TASK_FORCE_REBOOT

The hosts won’t magically try to reboot to perform the task in question.

@Tom-Elliott
I am confused,
I have misunderstood how works the plugin. I thought searching users by lhe LDAP Management section enable to check ldap conf is ok.
I will test in the right way.

Thanks Tom

@gnevills said in Fog Client 11.12 not renaming computer/joining domain (Could not authenticate):

To upgrade we installed fog 1.4.0 on a fresh Ubuntu server and then imported the database and upgraded the schema.

If the db came from 1.3 or higher, you must also copy the certs. Info on how to do all of this correctly is here: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@Sunks said in Install problem ubuntu 15.10:

Is it possible to import fog1.2 database to a fog 1.4.x ?

It is, fog will update the db to current. you will need to adjust some settings afterwards. Such as ip, and passwords. Details on these are at the bottom of this article: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@jlouie.smart that’s too difficult and not supported and I will not help you with it. Just migrate the data and images to a new box, leaving the old box untouched. When done, shutdown the old box. https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

@Tom-Elliott
Thanks Tom! I’ll check that out. That sounds like it could be the issue!

I’m rebuilding the FOG Server today!
Everything is set to go. I backed up all of my images locally. We migrated to a new physical server. So this is a brand new install. I’m going with Debian.

@Tom-Elliott It works!

But I get the message of the IP address of the interface eth0 repeated, as if IP search several times with the same itnerfaz.

Thanks a lot!

Are you sysprepping? Was the reference machine previously joined to the domain?

For your images, you should keep them pure - never capture a dirty image because it only causes problems. Pure means NEVER having been on the domain before, and as lean & clean as possible meaning not using old images to make new ones - keep your old images as backups, but build from scratch (installation media) every time - always delete old partitions and remake them, and capture new images.

At my old job, I would include month and year (not day) in my image names.