@cnbgeren said in PXE boot issue:

I do have a couple of questions during one of my PXE boot test the laptop required me to input the FOG server address but it did work. not sure why that would happen. With the new FOG GUI version I’m not seeing the option to upload image to the server, so is the GUI different than FOG 1.2.0 version? also do I need to syprep each image?

Well lets take this rapid fire questions in order.

During one of my PXE boot test the laptop required me to input the FOG server address but it did work. not sure why that would happen.
A: This typically happens when the dhcp server doesn’t supply the dhcp option 66 {next-server} OR you are using or have running a dhcp-proxy (or dnsmasq) setup on your network OR you have two dhcp servers responding to dhcp requests

With the new FOG GUI version I’m not seeing the option to upload image to the server, so is the GUI different than FOG 1.2.0 version?
Why yes the gui is a bit different. The upload/download functions are there, the developers changed their names because upload/download is point of view dependent. The names have been changed to capture and deploy respectively. If you go into the target host record, you should see menus along the left of the host definition, look for basic tasks the capture and deploy are under there.

Do I need to syprep each image?
There are those that say no you don’t, and technically if you capture an image for a specific model and redeploy that image to the same model then, no its not required (but if you follow Microsoft’s recommendation yes do sysprep always). If you have a single captured image you will deploy to any number of computers and models then yes, you must sysprep to generalize the image. In my case I always require the images to be sysprepped even if they are going to be deployed to the same hardware or not.

@alansopro Why not use CentOS 7? It is free, and newer. We even have this spiffy tutorial for it: https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

Clearly the build you have has issues. These would likely be resolved in CentOS 7.

@kentucky_smith I think I helped you with this via TV today. It was firewalld again.

I know I disabled it from last time - I’m not one to make a mistake with this. Something or someone must have turned it back on.

@Wayne-Workman Sorry but I’ve never heard of anyone netbooting an ARM platform. Not saying that this is not possible but I just have no clue. Seems like the ipxe devs don’t either. At least not back in 2013: http://forum.ipxe.org/showthread.php?tid=6808

@Wayne-Workman
I ran the codes in order that you posted. Unfortunately, it did not work. I will try running the installer but is there something else I should try?

By the way, I am watching your Hitchhikers video. It is quite good. i really enjoyed the guy playing the guitar!

@Tom-Elliott That was the case. This all happened because during os installation, the images partition was created as /Images instead of /images

Solved it! I removed /var/www/fog and /var/www/html/fog and re-ran the FOG installer. I am now able to create and edit snapins.

@george1421 Yeah I learned the hard way about trying to upgrade from v.31 to 1.x.x last week haha. But I’d rather ask to be sure than to waste a bunch of time one way or the other.

@Gary-Kulovics at the end of the day, you have a much better environment with 1.3.0-rcX series FOG.

@Darrin-Enerson I’ve added the warning and an example method to correct the issue, I think, in a more proper method. This warning will be available for the RC6 (Hopefully it can just be 1.3.0 at that point, but meh.)

Have you tried the troubleshooting steps on the wiki yet?

@ITCC You need to run installfog.sh again after updating .fogsettings

#wiki need to work on snapin pack article.

You would just follow the instructions in the fog wiki.
https://wiki.fogproject.org/wiki/index.php?title=CentOS_7

@adamk858 I can probably script a way to change the fog IP, without involving dnsmasq.

@Tom-Elliott

Okay. That fixed it. I had already modified what you told me to type. I just never did the /etc/exports. Once I did that it all worked. 🙂

Thank you!

Ok i have it working on my workstatons, on the vm servers that I am trying to image it does not show the fog screen and picks the tftp server and then reboots.

If i wish to create a image of a windows workstation Is that the upload option?, so upload to server.
Now if i am uploading a windows image from a workstation to a storage node does that storage node need to have a filesystem that windows will recognize like fat32? or will ext3 do?, as I thought it was only storing a iso so the format of the drive would not matter.

@ixll Just be aware I’m not a dnsmasq specialist. I did write my own tutorial on how I setup dnsmasq. This did work. Maybe you can merge what is in your ltsp.conf with this. https://forums.fogproject.org/topic/6376/install-dnsmasq-on-centos-7

In my example the fog server IP goes into two places.

The most important thing to attempt recovery of (other than images) is the ssl directory. If you have fog clients out in the field running, they will absolutely not trust nor obey any fog server that cannot authenticate. The directory is /opt/fog/snapins/ssl
There’s a walkthrough here:
https://wiki.fogproject.org/wiki/index.php?title=FOG_Client#Maintain_Control_Of_Hosts_When_Building_New_Server

If you can do that, and then re-use the old IP, then all the existing clients will report in to the server as pending.