Will you create the blank page again and then tail the apache error log to see what happened.

For red hat based systems
tail /var/log/httpd/error_log

I (think) for debian based its
tail /var/log/httpd/error.log

Then post the error here.

Lets check a few things. You say you were able to install a SVN trunk the other day correct?

Do you still have the environment variable set to point to your proxy server? Can you confirm you still have them set?

While this is an old URL, can you run the following command from the console of your FOG server.

wget http://downloads.sourceforge.net/project/freeghost/FOG/fog_1.2.0/fog_1.2.0.tar.gz

I’m interested to see if the download starts vs the file actually being downloaded.

You may has why do we need this?

UEFI PXE booting is a bit different than BIOS based PXE booting. Some of the early UEFI systems like the Dell Latitude e6420 and the OptiPlex 790 do not support PXE booting in UEFI mode. But through testing they do support USB booting in PXE mode. So knowing this I’m going to set out a simple solution to PXE boot these devices in UEFI mode. I can say for sure this method works with the previous mentioned systems. YMMV with other hardware platforms.

The process steps are not hard at all (actually even easier than USB BIOS PXE booting). You will need to acquire these things.

1. A 2GB (min) flash drive
2. A UEFI pxe boot image from a functioning FOG server.

Boot image creation process

1. Insert your flash drive into a Windows based computer and format it with FAT32 disk format
2. On that flash drive create a folder called EFI
3. On that same flash drive create a folder called BOOT in the EFI folder creating this path “x:\EFI\BOOT”. Note: I have not tested if case is important or not, I used upper case for everything and it worked. That is as far as I tested.
4. From a functioning FOG server copy /tftpboot/ipxe.efi to your windows computers. (pscp from putty tools works great)
5. Copy that file to the flash drive in the EFI\BOOT folder. That file MUST BE RENAMED to bootx64.efi (note the case difference. I did not test to see if case is important)
6. At this point remove the usb thumb drive from the build up computer and insert the drive into a target computer
7. Power on the target computer and press F10 or F12 (depending on the mfg) to call up the EFI boot menu.
8. Select the USB boot device under the EFI section of the EFI menu
9. You should see the iPXE boot banner and then after about 30 seconds it should be prompted for the IP address of your FOG server. Key in the IP ADDRESS of your FOG server and press Enter.
10. At this point you should boot into the FOG iPXE menu.

8. Insert your flash drive into an open USB port. Use the computer browser to ensure you "know" the Drive letter of this flash drive. The next steps are destructive and we don't want to erase a drive that has important data on it.
9. Once you know the drive letter launch the Win32DiskImager with “Run as Administrator” (you need to have admin credentials on the computer to be able to write the raw image to the disk. I you don’t have the rights you might as well stop here.) Accept any UAC prompts to show the Win32DiskImager user surface.
10. Select the folder icon next to the edit box for image name.
11. Change the drop down listbox next to the file name filed from “Disk Images (.img)" to ".*”
12. Navigate to the location where you downloaded the “ipxe.usb” from step 7 above.
13. Select the file and press open
14. Back in the main application, make sure the drive listed in the drop down list for Device is correct.
    Warning: If you get this part wrong you may end up overwriting something important
15. When everything is set and you know what will be overwritten press the Write button.
16. The write happens really fast. I do have to warn you once you write the linux boot kernel to the flash drive windows will no longer see the drive as a windows compatible drive and will want to format it every time you insert it into the computer. Don’t worry because the format is correct for pxe booting from a flash drive.
17. At this point remove the usb thumb drive from the build up computer and insert the drive into a target computer
18. Power on the target computer and press F10 or F12 (depending on the mfg) to call up the boot menu.
19. Ensure the network cable is attached to the target computer and then select the USB boot media.
20. You should see the iPXE boot banner and then the target computer pick up the dhcp address and connect to the fog menu. This should be a fast action.
21. Once in the fog menu remove the USB boot drive and you are done.

(default placeholder)

(default placeholder)

(default placeholder)

Why do you need this you may ask?

I can think of two/three situations where you may not be possible to PXE boot computers into the FOG PXE menu.

1. The computer is so old or has a really broken PXE boot loader
2. Some third party manages your DHCP server or the DHCP server you use doesn’t have the ability to set dhcp options 66 and 67
3. Your build in network device (or USB dongle) doesn’t support PXE booting.

The process steps are not hard at all. You will need to acquire these things.

1. A 2GB (min) flash drive
2. A pxe boot image from https://rom-o-matic.eu/
3. Win32 Disk Imager from sourceforge http://sourceforge.net/projects/win32diskimager/

I do have to add this caveat, in that the rom-o-matic servers include the most of the common network drivers. They may not have every possible driver built into this kernel. If you know how to build kernels you may have to download the ipxe source code and build a custom kernel with the specific drivers for your application. In general this method will work for most applications

One time actions for this process

1. Download and install the Win32 Disk Imager.

Image creation Process

1. From a browser access the rom-o-matic web site at https://rom-o-matic.eu/
2. Ensure that “Standard, for most common use” is selected (default)
3. Set the “Choose an output format” to “USB Keychain disk image (.usb)”
4. Set the “Embedded script” to (in the past your script section).
   Be sure to change the ip address of **192.168.1.88** to the actual IP address of your FOG server.

#!ipxe

dhcp
set next-server 192.168.1.88
set filename undionly.kpxe
chain tftp://${next-server}/${filename}

5. Set “Which Revision” to “Master” (default)
6. Press the Proceed button at the bottom of the page. It may take up to 2 minutes to build this kernel depending on how busy the rom-o-matic servers are at the time you submit your request.
7. When your kernel build is done the system should prompt you to download the “ipxe.usb” file. Go ahead and download that file to a known location.

(continued below)

The only issue I can see for dnsmasq is that the fog server is not on a subnet by itself. From what I think I understand the fog server is on the same network as the clients and the dhcp settings are coming from a remote location. Unless I’m off on this you can not run dnsmasq and dhcp-relay for the same subnet since both will respond to the dhcp request

@Wayne-Workman I though you would know of a wiki for that.

Just off the top of your head, do you know of a wiki that talks about pxe booting from usb flash. I know how to do it for uefi, but not bios. If not I can work on a process tomorrow.

@bacelo said:

@george1421 and the thing that bugs me more is that they have this working in other schools. They say that they don’t have a firewall. And I don’t think that they will let me manege the dhcp

Are they unable to update the dhcp settings for you? All they need to do is to change dhcp settings 66 to point to the ip address of your fog server and dhcp option 67 to point to the boot file. That is all the action they need to do for your dhcp scope. Nothing else needs to be managed.

Unfortunately, if your DHCP IP addresses are coming from this cisco device you are at the mercy of the owner of that dhcp server. No configuration that you can do with fog will help since the cisco dhcp server tells the client what to do next. Now if you want to pxe boot from a usb flash drive then you can regain some level of control and not need to make any dhcp server setting changes, but this will also require a special boot drive any time you want to boot into the pxe menu.

The other option is to shut off the dhcp relay between the network where the FOG server is and this other network, Then you will need to ensure that fog is setup to issue IP addresses for your local network. I see this as being a risky step because now FOG will supply all IP addresses for your side of the firewall.

@Atech Thank you for the feedback. So the ultimate solution was to update to the latest trunk version.

If that is accurate and the issue is resolved, can I mark this issue resolved?

@Matthew-Bostdorff If you have time to test this. See if removing the FOG client, reboot, do the in place upgrade, reinstall client resolves the issue. Also if you could sanitize and post that log file that jbob mentioned that will help trying to diagnose the issue. But the days of that old client are numbered. As soon as FOG 1.3.0 is stabilized, I’d recommend that you update so you can take advantage of the new client.

@Matthew-Bostdorff Thanks for the clarification and the additional info.

Just so I understand. If you had the RTM release in place and then fog client installed, then you did the in place upgrade to v1511 the FOG client stops responding to FOG tasks. But if you install RTM clean, install v1511 then install fog client everything works as expected.

If that is the case it sounds like the in place upgrade is stepping all over the fog client (I won’t go into how I think MS made a mistake with these in place upgrades). One thing that comes to mind is that the firewall settings has been reset blocking communication or the dlls the fog client registers to are no longer valid after v1511 is installed. BTW, did I mention how this new MS process is going to bite.

I wonder if @Jbob can give a little insight to what the 1.2.0 stable fog client hooks into when it installs. We need to drive a solution here because you are only the first one to come across this issue. More will follow.

@Tom-Elliott The new client was under my suggestion.

If I understand the OP he was running fog 1.2.0 stable with the client at that time. Something through windows update has now broken the older client. I asked what version of the client the OP was using because I knew the client was just updated, but not aware that it wasn’t backwards compatible to 1.2.0 stable. My mistake.

Is this issue solved? I see the thread is marked solved, but I don’t see a clear solution for you.

What version of the fog client are you using?

And for clarity, are you having an issue with the first release of windows 10 or is it the new release from November (v1511)?

I don’t have an answer for you on your problem, right now just trying to collect some additional details.

I know that they just updated the fog client to 0.9.8 or 0.9.9 to address several issues.

@Tom-Elliott You know I’ve been using the trunk version for so long I forgot all about the default file size limitation/setting in php. When I did the import / export test on the 1.2.0 instance I spun up so I could help with 1.2.0 questions. I downloaded, deleted a host reference and uploaded the saved copy and the host came back. But this system only has 2 images and 5 hosts. So the exported database wasn’t very big at all. If the OP has many systems or images I could see how it might reject the import as you stated. Good catch, I think you are spot on.

@Wayne-Workman said:

For me - a 6TB drive is awful cheap, and I can update an existing image before lunch. We have 22 images, one or two for each model. Keeping an image per model is simple to me, and deployment is more simple for both myself and co-workers. We can afford the drive-space and we have the time to make images.

See the key/trick to this is that there is only one or two images for all systems. I don’t have to keep track of what the target computer is, because there is only one image. In our case we release a new golden image every quarter with all of the latest windows and application updates. If you have 22 images that would be almost impossible to do. In my situation I can tell you that a Dell 790 or 9020 have the same image on it as a e7404 or e7550 (sans the model specific driver). If there is an issue impacting a 790 I’m almost assured that it will impact all models, so I fix it one, I fix it for all (in theory).