Sorry forgot to mention, the blotted ip is not received from DHCP rather set statically on the server. What is this step trying to do? Is it connecting to the FOG server to pull the menu?

EDIT: I think I see what is happening here. This step is calling the FOG server’s tftp service to retrieve the files to show the menu. problem is that the tftp/dhcp service is running on a different interface that is not on our production network. Maybe I can put the files it needs inside the NFS share and edit the script so that it points to the NFS share?

I followed these instructions at https://wiki.fogproject.org/wiki/index.php?title=USB_Bootable_Media#USB_Boot_UEFI_client_into_FOG_menu_.28easy_way.29
to boot from usb but get this error:

The IP address that I blotted out is the standard production network vlan, not the 10.0.0.0 that is the imaging/dhcp/pxe interface. At the step shown in the screenshot, is it trying to get boot file from the FOG server?

@Sebastian-Roth We have mostly UEFI capable systems, with a small percentage that still use BIOS. Another note, we are a large team and there really isn’t a standard for low-level preparations for image creation. Some people create images without an EFI partition, others do. Ever since I built the FOG server for my team I’ve sort of been in charge of the server. If I find a concrete solution then we can make it a standard. We would use SCCM but our network team doesn’t quite understand pxe booting so they don’t want to dive into it. It would involve configuring many many dhcp servers to hand out pxe boot files upon that packet request. So instead we either image here at HQ or in some cases we throw a WIM onto a usb drive and image that way, or in my case, I boot acronis via usb then connect to my NAS where my images are. I got UEFI pxe boot to work from my FreeNAS box a while ago, its a pain since I have to recompile the ixpe file each time I need to make a change. But I realize that FOG uses UEFI and has a customizable menu without having to recompile the boot image (correct me if I’m wrong). I am actually totally willing to be the guinea pig on this project. What would I need to do first? Like @george1421 suggested, maybe creating a small bootable partition? And from there, a menu would appear with a fog login screen, and a timeout counter, so that it can eventually boot into Windows if no imaging is required. This is all theory obviously. Or if a task to deploy an image is created, then the login screen or menu would not show but instead the task would commence immediately after a reboot.

Is it possible to have a bootable partition that the FOG Client can use to Deploy an image? I read about booting FOG from USB, but it would be really cool to be able to deploy or capture an image from a managed FOG client workstation. Is this at all possible?

I have an image that was created as follows. Convert disk to GPT, Pxe boot (efi) into sccm server, pull stock windows 10 image. Clean it up. Then captured it via pxe booting (efi again) into fog. This happens when trying to deploy it.

you da man!

i removed the gateway from eno2 and tested pxe boot successfully. i forgot that the gateway isnt needed if the clients dont need to get passed the server.

i restored the background file, clicked “Update” on the menu settings page of the WebUI and all is fine now. Weird. One question though, from the main FOG ipxe menu, when i hit Deploy Image, and get the prompt to authenticate with fog/pass, that text is blue, i want it to be white. Where can i change that setting?

after looking in /var/www/fog/service/ipxe, i saw that my custom background png file is gone. i will restore it and check again, but the colors of the text are still off. For example, registered clients show as green, non registered as red, the rest of the menu text was white (background image was black).

I use eno2 for imaging/DHCP and eno1 for management from my LAN

Here is my routing table:

I am wondering if i should just change the netmask on eno2 to 255.0.0.0. Does that sound like a good idea?

so now all of a sudden i can access the FOG Server from the management/LAN interface.

I need to reconfigure ip addresses on my FOG Server. I currently have eno1 configured for management on my LAN and eno2 for imaging/dhcp. both addresses begin with 10 and they both have the same netmask. i cant connect to the server from my LAN, but can from the isolated network on eno2. If i disconnect the cable from eno2, use netplan to apply or just reboot, then plug the cable back into eno2, then i can connect from my LAN. The problem comes back though. So im wondering if there is a way and how to reconfig the interfaces and fog to be as such: DHCP/Imaging on eno1 with a 172 address and a smaller mask, and eno2 to be the management interface for LAN.

custom ipxe menu color and background are no longer applied after updating to 1.5.7. in the webui under Fog Config>iPXE General Config>Menu colors, pairings, settings, all of my settings seem to have been retained, as well as my custom background, but they arent being applied when booting a device into the menu.

ill take a look next time i capture. i make sure the actual image size is the compressed, used data from the drives i capture, in the terminal using dh -u. we use a custom sccm image that is based on the stock windows install, which has bitlocker disabled.

i successfully ran the update to 1.5.7. Now i think there is an issue with the network interfaces. I set eno1 for management, and eno2 for imaging/dhcp. I was told on here that it should have been the opposite, but it has been working fine. now this morning i wasnt able to get to the webui from the eno1 network, but was able to on eno2. the port on the switch is set to the correct vlan. i unplugged the cable from eno2, then i was able to get online with eno1. could this have happened during the update?

UPDATE
so i had to re-apply the netplan file after rebooting the server. everything seems fine now. i can access the webui from both connected interfaces.

Some of my image sizes aren’t being read correctly at the UI. Some are correct, some are showing the full size of the drive or partition that the image was captured from. I upgraded to 1.5.7. Any way to correct this for the current images or should the sizes appear correctly after capturing new images going forward?

i’ve noticed that when creating an image from the ground up, renaming the computer BEFORE capturing an image could cause problems. for some reason the netbios name of the original name that was created by the windows setup process will stick even though you renamed the pc. for example. i imaged a drive from our sccm server with a fresh windows 10 image, it had that minit-xxxx default name (cant remember exactly what it was but similar to that), so i changed the name to LAB-TEST then captured and deployed the image using acronis, renamed the pc to be unique to that workstation, then when the internet was connected, it pulled a major windows update (1607>1803). some of the workstations were automatically renamed back to the original image name that i set LAB-TEST. This caused trust relationship issues when trying to join to the domain. i found this entry in the registry HKLM\SYSTEM\CurrentControlSet\Control\ComputerName\Active ComputerName and ComputerName. The string that reads ComputerName in each of those keys had LAB-TEST. So i disjoined from our domain, and changed both entries to read what the unique name i had set was and was able to join the domain. so the lesson here was to not touch the computer name until AFTER you install windows, capture the image, and then deploy the image. hope this helps.

oh ok. i probably missed that detail on the ordering of ethernet assignments. maybe one day i can redo the server again and make it right.

but the UI is in fact accessible on both interfaces.

forgive me but i just want to clarify that the entire sql database consists of all of those exportable items found in the web ui?