@ddeatrich The php fatal error in your snap would be interesting to see the full error message. That may give the devs a clue to at lest what point it failing.
I just upgraded my dev server from 1.4.0 to 1.4.1 and created a new vm client to test registration and it worked as it should. But that is not a like for like test. If you installed 1.4.1 fresh. I’ll start building a new install of FOG on Cento 7 to see if its a fresh install thing or something else.
I’m thinking this is possible.
There is a fog plugin called tasktypeedit. This allows you to create new task types. These tasks you can define a kernel and parameters to call. In this case you will create a new task called “BootWinPE” enter the proper parameters to boot your iso. Make that task visible to both hosts and groups “both”.
Then create a new FOG group with all of your members. Once the task has been created you should now have a <group_name> -> Basic Tasks -> Advanced -> Advanced Actions (section). In theory you should be able to launch the “BootWinPE” custom task to that group of computers.
https://forums.fogproject.org/topic/7765/pxe-booting-into-ms-windows-7-setup
FOG 1.2.0 and the legacy fog client does not support windows 10. You need the newer version of fog (1.3.0-rcX at the time of this post) and the new fog client (0.9.X or newer) for win10 support.
For sure you will need the 1.3.0 series for native FOG server support for uefi firmware, gpt disk format, NVMe disks, and Win10 support running on current hardware (i.e. latests FOS engine running linux 4.7).
Part 1 (The Back story)
FOG has the built in capabilities to talk to almost all direct attached storage media. One caveat to that is storage media that is behind some type of storage (RAID) controllers. Since FOG (more precisely FOS) is targeted for workstation capture/deployment the FOS engine has limited support for every flavor of RAID storage controllers. We have to remember that the FOS engine is a customized high performance linux operating system developed by the FOG Developers specifically for imaging. The FOS engine does not support the multitude of hardware that a commercial linux operating system might. But within the desktop/workstation realm FOS does support the Intel Rapid Storage (onboard) RAID controllers. These RAID controllers are typically found on the mid range desktop targeted at the workstation class market. I’ve been known to reference this class of computers with a snobbish reference of “fake RAIDs”. In reality a more accurate description would be hardware enhanced software raid. These Intel onboard raids are typically referenced by their ICHXX chipset design that offer several different RAID designs. http://www.intel.com/content/www/us/en/support/boards-and-kits/000005807.html
FOG typically references local storage through its built in storage drivers. These drivers will typically connect to local storage through the /dev/sdX interface. As I stated before the FOS engine does support the Intel Rapid Store RAID as long as you do a little setup that tells the FOS engine to enable its build in raid functions. Once the RAID functionality has been enabled in the host configuration page you will be able to capture and deploy images to the storage located behind these “fake” RAID controllers. What is confusing is that without enabling the RAID functions in FOG, the FOS engine will see the disks as /dev/sdX and let you write to them, no problem. But, this kind of breaks your RAID setup, so I would advise against writing directly to the sata disks.
Ref: Thread that started the discussion about FOG and onboard raid: https://forums.fogproject.org/topic/7851/intel-raid0-image-capture
@psycholiquid Pssst… to adjust the small font size try this FOS kernel parameter vga=792
vga=792 should be 1024x768x24 video mode, and clean your monitor, please!!! 
ref: https://unix.stackexchange.com/questions/71231/grub2-and-kernel-vga-parameter/114980
Just be aware the computer that you are using to retrieve the files from must be a linux computer. Windows doesn’t understand ext4 disk format.
Have you taken 2 of these systems (one that imaged and one that has not) and done an actual side be side comparison to ensure the model, included hardware, bios, bios settings are all consistent?
As I said before I’ve also seen this action with a bad windows driver. When you did the shift-f10 trick and was able to boot into windows, did you review the OOBE logs in either windows\panther or windows\sysprep folders? Those logs should tell you what was going on when the system rebooted.
One thing that is also not clear, are you using one image for all, or do you have one image per hardware model?
There has been a brilliant bit of code added to dnsmasq 2.76 (May 2016) to provide / fix support for sending uefi boot information to uefi systems. The issue is that most linux distributions do not have this latest version of dnsmasq available for install. It may take quite a while to get this version into the mainstream linux distributions. As always the case with FOSS environments you can download and compile your own software as long as the author releases the source code.
In this tutorial I’ll outline the steps required to compile and install this latest version of dnsmasq for common distributions of linux. I don’t have access to every version and/or flavor so I’ll only document what I’ve personally perform. I would encourage other, that can, document their experiences here with flavors/versions of linux that I don’t cover.
Before you compile this updated version of dnsmasq be sure that you install the version of dnsmasq from your linux distributions, package repository. This way you will be sure that all of the supporting scripts and dependences have been installed. In the steps below we will just replace the dnsmasq binary with the latest compiled version.
@george1421 I’ve been able to boot into ipxe now, register the system with the fog server and capture an image from a raspberry pi. I have not tried to deploy an image to the pi because I’m using the sd card to boot the pi into ipxe and if it doesn’t deploy correctly I’ll have a broken boot device. I’m working on some other options right now, but basically FOG is imaging a raspberry pi running an ARM processor.
I need to look into this a bit more, but when partclone ran the background was RED and not normally BLUE. I don’t know what this means but that is the only thing out of normal I found so far. The rest of the imaging environment seemed. Normal. The FOG iPXE menu screen displayed the background image normally and the text was colored appropriately. So the RED in partclone is the only abnormal thing I found so far.
I did have to build a custom FOS Kernel for this Pi because the standard linux kernel could not see the USB keyboard, but using the Pi version of the linux source code did. I also had to build a ARM version of init.xz with no changes except one.
For both bzImage and init.xz I needed to remove the compression on the files. For bzImage the bzip compression is only an x86 feature. For other architectures you need to use gzip to compress the kernel. The other thing, especially for the PIs, is that they are somewhat CPU bound so this dynamic compression takes longer to download and run than just transferring a larger uncompressed image and running it. So for both the kernel and initrd.img I’m not compressing the images. For the initrd.img I’m sending it in cpio format to the Pi.
Development naming convention I’m using is
kernel: ImagePiARM64
initrd: init_arm64.cpio
The kernel is unique to the Raspberry Pi and not intended for any other ARM architecture.
For FOG 1.6.x we probably should add 2 new fields in the FOG Configuration -> FOG settings for the ARM kernels too just like we have for bzImage and bzImage32. But in this case ARM64 and ARM32. I can see one fog server imaging both x86 and ARM processors so we will need to make accommodations. I’m not sure how to handle the kernel field in the host configuration manager though.
Is this a uef system? If that is the case you may not get the pretty FOG background in the iPXE menu.
Also did you remember to disable selinux (actually set to permissive)? You should also disable firewalld.
I agree with Sebastian, call that url with a browser and post it here.
Also confirm that bzImage exists in /var/www/html/fog/service/ipxe directory.
@RobTitian16 Please move this file to a safe place and use my config file as it is complete and the order the dhcp-boot as they were. What you have should work, but you have the dhcp-boot for undionly first, which may skip the uefi tets since it would be the first match. also you don’t need the dhcp-options settings. What I posted is a complete config file.
I’ve spent several hours (more than I’d like to admit) of changing, restarting, capturing and reviewing the dnsmasq booting process. The results of this testing is outlined below. I did some minor review of the documentation but the majority of what I learned, I learned the hacker way. There may be official recommendations that differ from what I’m going to post here, this is information is based on my first hand experience with dnsmasq 2.76 (NOTE: DNSMasq 2.76 was specifically compiled on my target computer. It is NOT the version that is available from most linux distribution’s repositories. If you want to follow these instructions you MUST compile your own dnsmasq 2.76 for your FOG server).
Resources used for testing
FOG Server: FOG-Pi (Raspian Jessie)
FOG/DNSMasq IP: 192.168.112.24
Router: WRT54 (soho router) @ 192.168.112.1
DNSMasq: v2.76 (compiled on FOG-Pi server)
Wireshark
Target computer: Dell e6230
Debug computer: Dell T3510
Base ltsp.conf file
# Don't function as a DNS server:
port=0
# Log lots of extra information about DHCP transactions.
log-dhcp
# Set the root directory for files available via FTP.
tftp-root=/tftpboot
# Disable re-use of the DHCP servername and filename fields as extra
# option space. That's to avoid confusing some old or broken DHCP clients.
dhcp-no-override
# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,192.168.112.24
# PXE menu. The first part is the text displayed to the user. The second is the timeout, in seconds.
pxe-prompt="Booting FOG Client", 1
dhcp-range=192.168.112.24,proxy
I am not a Mac person (I have seen one once), I can say that others have been able to get them to pxe (netboot) boot.
There are some additional steps required to netboot these boxes. Understand this isn’t a fog problem, but rather a Mac problem with pxe booting.
https://wiki.fogproject.org/wiki/index.php/FOG_on_a_MAC
Additional discussion on netbooting.
https://forums.fogproject.org/topic/5790/boot-pxe-macbook-imac
I also suggest that you read these threads because there are other useful tips.
https://forums.fogproject.org/topic/9278/fog-1-3-0-pb-with-mac-netboot
https://forums.fogproject.org/topic/8955/blessing-fog-server-doesn-t-work-on-macmini7-1
And finally one of the devs has first hand experience with this things called Mac, that may have some insight to netbooting these things. @Sebastian-Roth
Also make sure there are no extra white spaces before or after the undionly.kpxe prompt. We did see that happen once that caused the same error message.
If the fog server and pxe booting client are on the same subnet we might have you grab a pcap file to tell us what is actually being sent from your dhcp server. The instructions are here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
Post the pcap file on a google drive or dropbox and share the link with either one of us by FOG Forum IM or just post the link here. You can pull down the files once we have a chance to look at them.
Well first the bad news, the OEM EULA doesn’t allow you to create a master image and then replicate that image to multiple computers. That is not allowed. You need to purchase a Volume License Key for that. You are only allowed to install the OEM version from the original OEM media unaltered.
The better news is that you only need to purchase 1 volume license key per OS version you plan on cloning. For example, if you want to deploy Win10 pro and Win10Edu, you need 2 VLK keys regardless of how many of each you want to deploy. You need this vlk key if you want windows 10 to activate. MS changed this to protect against OS pirating.
With the release of 1.3.0RC16 basic persistent groups have been added to the system via a plugin. The developers were kind enough to write a plugin wrapper for the mysql trigger I created in this post: https://forums.fogproject.org/topic/6902/fog-1-3-persistent-groups
Please understand that persistent groups are not officially supported by the developers since they only wrote the plugin wrapper for the sql trigger. With the use of this plugin wrapper its no longer necessary to go into mysql and paste in the trigger as it was defined in the link above. This plugin is already installed in RC16 and should be added the norm way plugins are added into fog.
This plugin started out as a need to have persistent groups in FOG. I was a bit confused about the built in grouping in fog when I started using it as many others. I would create a group in fog, set a parameter for that group, press OK and the parameter would disappear. After banging my head against the wall thinking that I was doing something wrong I reached out to the developers to say something was broken with fog groups. The developers explained how FOG groups really worked. (These are my words not theirs), The groups in FOG are what I might call set groups, in that you can assign hosts to a group and then key in a parameter and then that parameter is copied to all hosts in the group. That setting does not stick in the group definition. If you add a host later to the group the setting I created yesterday will not be applied to this new host when its added to the group. This is not what I needed for my FOG environment. I have 3 or 4 classes of computers, each of these classes have their own specific OU settings, their own combination of snapins and other unique settings. I wanted to add a new computer to the CAD group and have all of the settings specific to the CAD group applied to that new system. The same would go for the production class and the office class. Each have their own individual characteristics.
Since I didn’t know how to program in FOG or create plugins I reverted back to something I’m quite familiar with SQL. I though that if I could create a sql trigger that when a host is added to a specific template group that database trigger event could then update the inserted host with a predefined host template. I could do this without having to program fog or change the programming in any way. This hack is done outside of the scope of fog and its management control since it executed at the database level.
Before we get started here we need to get some terminology defined.
Host template := is a non deployable host where you set the predefined values you want copied to your destination hosts. At this time a template host may only be associated with a single template group.
Template group := is a group that is associated with a single template host. A template group can contain many hosts, but may only be associated with a single template host.
The way the sql trigger works is when you add a new host to a template group, the sql trigger fires and erases all existing snapin, location, (and and) parameters from the new host and then copies the settings from the template host to the new host. Understand the way the trigger works is that it only fires when the host is first added to the group. If you change a parameter in the template host, this value is NOT automatically copied to all hosts in the template group. If this is what you need you should use the traditional fog (set) groups for this. Also note when you remove a host from a template group the settings are not removed from the new host. So in a way the template groups and template hosts are a set only group (which functions the same way as the traditional FOG groups, except the settings are remembered in the template host).
@Tom-Elliott I just did what was needed on my FOG-Pi server. I have the info, it looks like we need to call iPXE from Grub because of the questions it asks. I need to go and get ready for work, but I have what I think we need. I need to test an idea I had with usb booting to see if I can call iPXE from grub.
@Sebastian-Roth said in FOG 1.4.2 TFTP Open Timeout:
@cassie_280 There is one step in the installer where it tells you to go to the web interface. This is not the end. You need to hit enter after that to proceed. Not to sound rude just wanted to make sure…
I don’t know how many times I’ve reached that step and when to copy the url and hit ctrl-c to copy the url, which then aborted the install. So it does create a botched install. It does happen.
You have a WDS/SCCM server that is taking over your pxe boot process. I assume this server is 10.125.4.27. WDS/SCCM will override pxe boot information listed in your dhcp server.
@Jamaal You can join the machine to the domain by:
I use the first option because based on the image used, type of computer, site deployed to, our post install script will choose the correct OU and update the unattend.xml file accordingly. That is something the fog client isn’t designed to do.
Many people use option 2.
As for why your setup is not connecting to the domain. Is the network driver being loaded so the client can reach the domain controller? If I had a system that wouldn’t connect to the domain, I would log into it and then manually connect it to the domain. Be sure you use the user ID and password you defined in fog, that user account must have computer add rights. The other thing may be that you are defining a destination OU that doesn’t exist? Also you may be able to glean some information by looking at your DC’s security log to see if its a permission issue.