Best posts made by george1421

@mosi For you to get the system info page something has to be going wrong in the master fog script.

specifically around this line https://github.com/FOGProject/fos/blob/e3e7e93cc249a92b512862f308481f1ee055740d/Buildroot/board/FOG/FOS/rootfs_overlay/bin/fog#L63 mode needs to be quickimage for “image deploy”, but just below quickimage is sysinfo (the screen you see). If the only change you do is enable a nic or not, we need to understand how this impacts the script. In general it shouldn’t but we need to understand why.

Sorry to hear that your fog server went sideways on you.

Im a bit of a Luddite, but I’ve had great success with Centos 6.7. I’ve installed FOG and Centos 7 without issue either. Fedora works as well as Ubuntu. I find there is the least about of messing around with Centos. But mainstream linux platforms are supported.

If you have a mobile phone, you can grab the error message on the client if you are quick.

If you are using the unattended.xml file then you can dynamically have a FOG post install script update the unattend.xml file with the proper OU. This is instead of having the FOG Client connect the device to AD. If your FOG post install scripts are location aware (such as based on an IP address range) and that range can be associated with an OU then your OU structure can be calculated. I use something similar for my company. I also take it one step more, I determine if the device is a desktop, laptop, or tablet and factor that into the device OU assignment. Update the unattend.xml file and let it connect the device to AD.

You could also use the (unsupported) persistent groups in FOG 1.3.0 to set an OU based on group membership. In this case you would create a template host with the proper AD assignment and the during registration (I think) assign the host to that group. The template host values will be applied to the new host during registration.

Rob, you have a couple of options here depending on how you want to manage your FOG install and how fast (big) is your UK to US link.

One option is to setup a storage node in the US. If you are using FOG 1.3.0-RCx then the storage nodes already have the tftp kit built in. In this case you will surely want to use the location plugin with FOG and then define a location for the UK and a second one for the US. Actually I would create a location for every physical location you have. That way the FOG clients will always connect and image from the storage node that is closet to them. The down side to this is if you are using the FOG client on the target computers they will check into “ping” the FOG server every 5 minutes for new instructions. If you have a vary large number of computers this check in may consume all of your site to site communications.

The other method is not currently supported in fog but works very well and what I use at my company. This is called a multi-master node setup. In this case each location has their own FOG server that the local IT techs use like a stand alone server. But in our case the images are managed at HQ. So what we have is at HQ a development FOG server (where we create and test the new images). ON that HQ development server we have a storage group setup. In that storage group we have the HQ development server as the master and each site’s FOG (master) server setup as storage nodes. So when we approve and release a new image at HQ it is replicated to each site’s FOG server automatically. As long as you are only updating master images this process works flawlessly. If you add a new image to the Development FOG server at HQ, you must export the image definitions and then import them on each of the sites fog server. Understand that replication will happen automatically, just the sites will not be able to see this new image until you upload the image definition on the remote sites FOG server. While this process sounds a bit complicated its not. Plus it has the advantage that each site’s IT logs into their own local FOG server so they can’t accidentally deploy an image to a remote sites computer (i.e. Site A tech can’t deploy an image to site B’s computer by accident).

Update the installer script to add the logic to automatically install the tftp boot files onto a storage node. I understand that not all storage nodes will be used for pxe booting. But add the required files just in case the node will be used for PXE booting. There is no risk to having the boot files or the tftp service installed if not used (xinetd managed the starting of the tftp process anyway). By adding this function to the storage node you can avoid having to enter into the host os to manage the files, or setup rsync to copy the files from a pxe boot server as new versions come out.

@bacelo said:

Ok , Yes the DHCP is not controlled by the fog server it is the network configuration it my be a router I am not sure. I do know that the DHCP server that hey are using in as it is in the Wiki fog page as it is for the cisco setup. Know sould I tell them to change the 10.1.8.254 to 10.1.8.1 will this help??

No what they have is fine, as long as you can set the options 66 and 67 for your 10.1.8.x scope to point to your FOG server and the boot file undionly.kxpe on that dhcp server. That is what’s missing here. That is why we are trying to figure out what 10.1.8.254 is.

@RobTitian16 The next time you build a reference image I suggest that you use a generic unattend.xml file even if you have FOG do everything. It make it easier to extend the capabilities of FOG if the unattend.xml file is referenced during Windows OOBE.

@Sebastian-Roth I also saw that too (dhcp server sending out the next-server). The main dhcp server (Linksys WRT54GS, yes I know its old but it is a nice friend) is sending out the next-server pointing to itself. I thought this was strange since there is no option to change/set this in the wrt54’s firmware. I could reflash it with DD-WRT but it hasn’t been a problem until now.

As for the 6230 hanging. If I remember right that series was the first to fully support network pxe booting in uefi mode. I need to check to see if there is a firmware update for that. I also plan on building an ipxe usb boot disk to check to see if its the ipxe kernel or something else. The last bit is I might try the old ipxe kernel that Tom added back into fog, the one for getting the Surface Pros to boot. I think my issue is with ipxe and not dhcp/dnsmasq at this time since the ipxe kernel is making it to the target computer.

@Wayne-Workman That’s what I thought. There is no need to do extra stuff (again, trying to stay out of the OS as much as possible) for the non-technical / wiki following FOG installers. Its a simple change (in my mind) to the installer script that would make the storage nodes a bit more versatile with little to no expense in time or effort. I’m not seeing a performance or security issue by installing the pxe boot files or tftp service (other than every service that is installed is a potential attack vector). Everything we do out of band (i.e. doing a full install then hacking it later) risks brining in errors and extra work to maintain: IMO)

@FlareImp Just be aware, it is more than just sourceforge.net. (If I wasn’t clear in my previous posts. You need access to a bunch of sites for your OS, so it would be easier to white list the fog server IP address instead of the remote sites)

@mr626 We will setup a VM to build our reference image. With MDT you have it build a boot ISO image to kickstart MDT on the reference vm. We transfer that mdt boot iso to our SAN where our VM hosts can access. Then we setup the VM Client to boot from that ISO image into MDT.

From there we are in MDT and select the MDT task sequence to build the reference image. We have several (many) custom task sequences to configure the reference image with our branding, and applications. Our applications are setup to do an unattended install in MDT. When the process is done we have a complete reference image with all of the changes we defined and the applications installed that are universal. You have to install GUID based applications like Anti-virus and other after deployment, but most applications can be installed directly in your reference image.

From there we then run sysprep and have sysprep power off the VM. Then we pxe boot the vm into FOG (the vm has already been registered). We have FOG capture the reference image and upload it into the FOG server for deployment. We don’t have to deal with the rearm or rearm count since we build the reference image from the beginning each time.

Since we have a universal image when fog deploys our sysprep’d image we also have a FOG post install script that copies the model specific drivers into the target image just after FOG copies the disk images back to the target computer. When the target computer boots it finds the drivers during OOBE and loads them.

First let me say that if you are using FOG 1.3.0-RCx servers then the storage nodes includes the bits (tftp, pxe) to support this. If you are using 1.2.0 then you have some manual work to get these services installed.

You only need dnsmasq when your dhcp server can’t supply the dhcp options 66 and 67 for pxe booting. Adding in dnsmasq adds a bit of complexity but it is manageable.

Yes in your example above this is totally possible. You will have your remote dhcp servers point dhcp options 66 and 67 toward your storage nodes at the remote locations.

You will also need to use the location plugin so that you can direct the target computes towards their local storage node. You will create one storage group and then place the FOG server in that storage group as a master node and then add the remote storage nodes to that same storage group. This will then start the images and snapins replicating right away.

@Tom-Elliott I got sucked into fixing a downed business system tonight, so I haven’t had a chance to test this new build out. But while I was working on the outage I started thinking about this new setting. When you upload an image in the new environment, does it come in published or unpublished (may not be the correct term)? If it comes in published, then depending on the replicator cycle I have no more than 10 minutes (probably less depending on where the replicator is in its cycle) to unpublish it before the replicator. Once the replicator starts sending the file then unpublishing it after the fact is a bit moot. I just want to confirm that when an image is captured it enters the system in as unpublished. It will be up to the FOG admins to publish the image for replication. I can see that we would still want local deployment of the image, we would just want to kill replication of the images and snapins until they are published. (hopefully I didn’t make that too confusing)

Just be aware that because the hard drive has data on it today, doesn’t imply it doesn’t have a broken (soft) sector. Since all but for systems imaged OK, it probably safe to say that your image is in good shape. Then you have to ask what is different with these 4 systems. It is either bios version, bios settings or something physical. Since the systems are 4 years old, I’m suspecting the hard drive, but that is only a guess.

Since you are using bios and not uefi the 1.2.0 stable version will and does work fine. If you were using uefi, I would have recommended that you upgrade to a pre1.3.0 release. But you should be good with 1.2.0.

@RobTitian16 Tom is right about enabling the network booting stack in uefi mode. On our Dell systems, network booting in uefi mode is disabled by default.

I’m not sure what/why your server OS is important here, you are installing windows 10 on a target computer, this has nothing to do with the server, can you explain?

<edit> unless you are referring to the uefi/bios coexistence. In that case your dhcp server needs to be running windows 2012 or you have dnsmasq running on your fog server to supply the dhcp pxe booting options.

@george1421 I was finally able to update that 6230 from firmware A11 to A15. Without changing my FOG-Pi / dnsmasq setup the 6230 now pxe boots in uefi mode (whoot!!). The kernel stayed at initializing devices for about 15 seconds, I started to panic after 8, I figured it was hung and reach for my FOG GRUB usb boot drive. When I turned around the 6230 was sitting at the FOG iPXE Menu. I timed it again and it was bout 15 seconds to init the devices and display the FOG iOXE menu. I was able to quick register the system and everything worked fine.

Below is my final dnsmasq configuration for dual booting bios (legacy) and uefi systems on dnsmasq version 2.76

# 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

# 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

# The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
# Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI, ARM_EFI and X86-64_EFI
# This option is first and will be the default if there is no input from the user.
# PXEClient:Arch:00000
 pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe
# PXEClient:Arch:00007
 pxe-service=BC_EFI, "Boot UEFI PXE-BC", snp.efi
# PXEClient:Arch:00009
 pxe-service=X86-64_EFI, "Boot UEFI PXE-64", snp.efi

dhcp-range=192.168.112.24,proxy

According to the change log for dnsmasq there are issues with certain uefi firmware for displaying the dnsmasq boot menu so for uefi firmware dnsmasq will just pick the first matching service entry that matches the arch type, as long as there is only one and only matching service. You will not see this menu displayed for uefi firmware, where for bios you will see the menu entry for 1 second.

I did note in the iPXE bootloader that it did say duplicate next server values presented (or something like that). And that is in line with what we were seeing in the earlier pcap where both dnsmasq and the soho router were sending conflicting next-server values.

Here is the pcap of my last and working test. Note: I see I left the snp.efi kernel configured in dnsmasq too!!.

0_1475719888587_output.pcap

Add the field names to the export hosts csv file. Add logic to ignore first row on import assuming the first row is the field names.

This is to allow the IT technician to see the expected input information based on the column (field) names. Right now it is not clear what fields (columns) are supported and the expected order for the data to be imported correctly.

Expected workflow: Export hosts to csv spreadsheet (blank or populated), fill in new data in correct column order, and then import the csv.

@FlowLive Hey that’s great to hear that someone can repeat my madness…

@Wayne-Workman Le me see if I can clean it up a bit. I need to see if I can integrate what @Sebastian-Roth noted in this thread about using a logical to represent the fog server IP. I think I can make it work.

@Wayne-Workman Sorry we went to DM chat to work through the issues.

The .0 thing was because his primary dhcp server was still handing out dhcp 66 and 67 and there was a dhcpProxy server (dnsmasq) sending out an Offer packet, so the target computer switched over to dhcpProxy mode and my configuration did not have that part configured (because its almost never used, except in conditions like this).

We had to add this section.

# PXEClient:Arch:00000
pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe

# PXEClient:Arch:00007
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi

# PXEClient:Arch:00009
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi

To create the complete config file here.

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

# inspect the vendor class string and match the text to set the tag
dhcp-vendorclass=BIOS,PXEClient:Arch:00000
dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
dhcp-vendorclass=UEFI,PXEClient:Arch:00007
dhcp-vendorclass=UEFI64,PXEClient:Arch:00009

# Set the boot file name based on the matching tag from the vendor class (above)
dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,10.1.0.102
dhcp-boot=net:UEFI,ipxe.efi,,10.1.0.102
dhcp-boot=net:UEFI64,ipxe.efi,,10.1.0.102

# The boot filename, Server name, Server Ip Address
dhcp-boot=undionly.kpxe,,10.1.0.102

# 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

# PXEClient:Arch:00000
pxe-service=X86PC, "Boot BIOS PXE", undionly.kpxe

# PXEClient:Arch:00007
pxe-service=BC_EFI, "Boot UEFI PXE-BC", ipxe.efi

# PXEClient:Arch:00009
pxe-service=X86-64_EFI, "Boot UEFI PXE-64", ipxe.efi

dhcp-range=10.1.0.102,proxy

@george1421 Last and final comment. Just for grins, I move the original Raspian Jessie version of dnsmasq (v2.72) back in place and restarted dnsmasq. With 2.72 running and the same configuration as before the Dell 6230 failed to pxe boot in UEFI mode, but would boot in bios (legacy) mode. So if you are going to use dnsmasq AND require pxe booting uefi systems you must upgrade dnsmasq to 2.76 or it will fail.