SOLVED Server Migration PXE Boot Issues
- FOG Version: Running Version 1.4.3 SVN Revision: 6075
- OS: Debian 8.8 Jessie
- Service Version:
- OS: WIN7
I just finished migrating our old Ubuntu box over to a new VM running Debian 8.8. I followed the wiki – https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG. Everything seems to have worked very smoothly. I moved our images off of our old physical server to a Windows box along with the SSL directory and database info. Then I copied all of that over to the new physical server running our VMs. All of this went fairly well.
The new server is up and running. FOG is installed. The database is migrated. I just tried to remotely wipe a few machines and noticed that the PXE was not activating WOL.
I did copy over the entire SSL directory. Than I followed this as per the WIKI…
@Wayne-Workman The wiki was a little unclear on the part listed below. I was a little confused how the new SSL settings were supposed to make it to the new server based on the commands. Please correct me if I’m misinterpreting things. Thanks!
rm -rf /opt/fog/snapins/ssl # mv /images/dev/ssl /opt/fog/snapins -- I replaced this to my needs. I ran the below command instead... <<<<< cp -R /new/new/ssl/ /opt/fog/snappins #Debian, Ubuntu, and Ubuntu variant users should use this command to set permissions: chown -R fog:www-data /opt/fog/snapins/ssl
The only step that I had to modify in my project was that I copied all of my files to a directory I created on the new server entitled new. Then when I moved all of my files over they were in a directory entitled new as well. So my directory structure is this : /new/new/ssl/. See the above code…
Also, I did re-run the fog installer after I completed moving the SSL directory…
Anyhow, if you all have any suggestions please let me know!
Townsend K-12 Schools
Yes sir! Things are working well! I’ve multicasted several machines this afternoon without a hitch. Yay! Thanks!!
So it’s safe to solve?
We discovered the issue… DNS was not set properly on the FOG server… Don’t ask why this made a difference but when I reset things and restarted the server WOL works again. Ugh!
Settings on our switch ports were identical. So that was likely not the issue.
You were correct! I apologize! I forgot we moved my test lab to a different switch. I can use WOL just fine now in one of my other labs on a different switch. Having the network admin adjust the port settings on that switch. I’m certain that’s the issue!
Everything else with our upgrade is working! Yay! Now I’m on Debian on upgraded hardware.
Sounds like it must be a setting on my VM. I’ll check it out and post a fix when I figure it out. The only things that have changed are the OS and the OS the VM is running in and the new enclosure. It must be one of those things.
@Joe-Gill This is not a problem with WOL or this would be reported ALL over the place. Something on your network is not sending the WOL Packets (or should I say not allowing the packets to start the device you’re hoping to turn on).
Well I updated to 1.4.4. I ran back through everything to make sure I had all my usernames and passwords changed on the server. I found a few that were not correct. That seems to have resolved the non-PXE boot issues…
The WOL issue is still there though. Now I task it and it doesn’t show up in tasks. But nothing happens on the hosts I’m tasking.
One thing that did change on this install is that I eliminated a password on our mysql database and I eliminated the FOG user on the server and FOG itself. I have gone through and done the best I could to change those things throughout FOG.
I will update to 1.4.4.
FOG server is on the same subnet as the hosts. I haven’t changed any of my addressing from old FOG server.
@Joe-Gill WOL was fixed in 1.4.4 as there was an issue with WOL not being cleared.
That said, the information seems conflicting. Are these systems on the same subnet as the FOG Server? If not, are you using WOL Broadcast plugin to steer the WOL traffic to the broadcast addresses of the network they’re to be booted to/from?
I created a WOL task and the hosts are non-responsive.
I PXE booted one of those hosts just now and got this message…
What do you mean they will not task? Are the looking at the wrong server?
Changing permissions made no difference. The machines still will not task.
Any suggestions would be helpful!
The following command listed above:
cp -R /new/new/ssl/ /opt/fog/snappins is misspelled here. I ran the correct spelling…
Secondly, I checked the /opt/fog/snapins directory and it appears the permissions were not set correctly. I adjusted that and am re-running the fog installer.
I’ll keep you posted!