FOG 1.5.2 TFTP OpenTimeout
I’ve read through many of the forum posts and wiki and am still stumped. I’ll do my best to give as much background as possible, but I’m sure more will be requested and I’ll supply that.
- Windows10 Enterprise host (192.168.190.40) running VirtualBox 6.1.
- Debian 10 Buster VM (minimal install from cd iso with updates from debian.org during install- ssh server, system utilities, etc.), “fogserver”, 192.168.190.100) with FOG 1.5.8 default install
- CentOS 7 VM (192.168.190.182) set up just as a test for pxe boot
- sophos utm 9 firewall/router w/ DHCP options 66/67 set to 192.168.190.100 / undionly.kpxe respectively
- both win10 host and centos7 VM can ssh into fogserver
- neither win10 host nor centos7 VM can tftp to fogserver; win10 times out (connect request failed); centos7vm says it connects, but downloads a 0 length file
- I’ve gone through https://wiki.fogproject.org/wiki/index.php/Tftp_timeout… and everything matches from what I can see (config files, iptables, etc… no selinux installed)
- I’ve run tcpdump per https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue and will attach output.pcap. This was taken from attempting to pxe boot the centOS7 vm (192.168.190.182) and hit ctrl+C after 20 seconds once “pxe-e32: tftp open timeout” error appeared on centos7vm. The output definitely doesn’t seem right, so I did it a second time and got the exact same thing.
Any screenshot or config or dump file you want to see, please let me know. Each VM is using bridged adapter so it has access directly to the Sophos. Any help is appreciated. Thanks in advance.
@george1421 When the user gets the computer, it boots into Windows. But, it doesn’t just boot directly into Windows. It will go through a setup process before it hits the login screen with no user input required, just a network connection (preferably on our network for domain join). This process includes adding the machine to the domain, creating local user accounts, etc. Once the user logs in, a few other programs will load. But, for all intents and purposes, the machine is ready to go when the user gets to the log in screen.
So, my thinking is similar to yours in that I should be able to run FOG to capture what is there before it does any of the initial set up and use that on every machine without worrying about service tags. Admittedly, I’m not completely in the know on the Dell boot process with our image since I’ve not worked on that part of the imaging and will need to talk to the people who do. But, again, like you said, it seems like it shouldn’t capture that service tag until it goes through OOBE/Winsetup, thus getting it before booting the first time should work.
I’ll talk to the head of that team on Monday and keep you updated.
@jvenus While I haven’t used Dell preloaded image. My bet is that they are using a utility to pull the asset tag on first boot. So if you capture the image with FOG as delivered from dell you should be able to clone it to last years model. When the system boots it going to run through OOBE/Winsetup and pull the proper asset tag.
Now the exception I don’t know is that if Dell as they are loading the image onto the computer writes the system name into the unattend.xml file. And that is where the name is set. Its kind of unlikely but possible.
So when you turn on a new out of box dell with your golden image on it does it run through OOBE like an new OEM version of windows or does it boot right up to a login screen?
When we get a new model we will capture the as delivered state from dell in FOG. Understand this will be an OEM build. But when its time to retire the system, we will wipe the disk with the proper tools and then reload the as delivered dell OEM image back onto the disk and then dispose of the computer (trade in, sell, donate, etc). When the recipient turns on the computer for the first time the original dell OEM install will run and build the system.
So in your case I would surely capture a new out of box system with your company standard image on it for 2 reasons.
- You can freshen older hardware of the same model.
- If you need to reset the image back to a known state you have a baseline image.
While this is a bit off point, a 25GB image can be pushed out in about 4 min. over a 1GbE network. With a 10GbE core network and a 1GbE link to the workstation in just under 2 minutes. So reloading a base image back to the hardware is trivial where it really not work fixing a broken/knackered system.
@george1421 Let me ask you this, hypothetically…
If I have a fresh 5510 from Dell, never booted into Windows, if I use FOG to capture just the boot/primary partion, that should essentially do the same thing as in the previous post, no? The drivers will already all be installed b/c Dell Image Assist already put them on there.
Clarification The specific use case here is that we have several machines that have last year’s image on them because Dell didn’t update as they said they would. So, using a USB (with this year’s image) to update the image on a 5510 that has the old image, including infusing updated drivers, would put the new image on the 5510 in a sysprep’d state. If I used FOG on that machine to capture the image (specifically the primary partition) before that computer was ever booted into Windows, it should work as desired, no?
I ask this because of the previous post about the service tag being captured and deployed to another machine. This made the machine have the same logical name even though the service tag was different. I guess I’m trying to figure out what part of the process is copying that service tag over.
- Our team used Hyper-V to create their image.
- That’s about the size they used.
3-6) The current “solution” is USB drives. The team developed a sysprep’d Win10 .wim and uses Dell’s Image Assist to restore the image and infuse drivers. (We provide Dell with an annual .wim to include on all of our purchases.) Since all of our machines are Dell, including the CAB files on the USB for Image Assist to pull from is easily updateable. But your question about the recovery partition is very valid. Most of our clients are remote. So I think the logic there is that in worst case scenarios, the user could at least have “something”.
I know that FOG won’t use .wim. I think I’ll explore the route of creating a .vhdx out of the .wim, then capture the image with FOG, and then load the drivers (with your helpful link if I could get it please) post image push.
@jvenus I will give you some suggestions now that you have it working.
- Develop your golden image on a VM. You can use VB but its not my preference. The logic is the vm is hardware agnostic and generic. You will get a cleaner end product if you build it in a VM.
- Create your VM golden image on the smallest disk possible. With that said, most reference images will fit onto a 70GB virtual disk just fine.
- Since you have an imaging solution right now, decide if the recovery partition adds any value in your environment. We are seeing with Windows 2004 that the recovery partition is causing issues with resizing the partitions. So I would pose the question, do you really need the recovery partition? In my golden image I’ve been deleting the recovery partition. If you feel you need the recovery partition make sure the main partition (the one you want resized) is the last partition on the disk.
- Create a single image for all hardware. I have a tutorial on how you can load the hardware specific drivers post image push. You will then load them during the oobe/winsetup phase in the setupcomplete.cmd batch file.
- Sysprep your image.
- Either use sysprep to power off your image, or use
shutdown -s -t 0, or disable fast startup then shutdown your virtual machine for capture with FOG. If you don’t you will get a windows dirty bit warning because windows was not powered off correctly for image capture.
@george1421 The 5510 connected. The FOG server captured the image and was able to deploy it to another 5510. There’s a hiccup with the image containing the Dell service tag, but that’s something I’ll work on with our image creator. The image that I’m capturing from shouldn’t have that information in it. FOG is capturing that information, but from where I don’t yet know. Maybe the recovery partition? More reading to be done. Probably just need to restrict the partition that is being collected/deployed. However, as far as this post is concerned, FOG is working in our environment because of your help. Thank you for all your help.
@jvenus I’m not sure I understand your question, but the linux user
fogprojectneeds to have a password set. That password is set by the fog installer and “no one shall touch it”, is the commandment by the developers. If you change it, then you need to then update the .fogsettings file and then change it in all of the places it hides in the web ui.
You are not the first person to mess with the password, that is why I already have a tutorial on how to fix it.
@george1421 There’s a forum visit somewhere in the spider web of browser history that said to change that variable. Regardless, I’m working through that link you gave me. RE: "4)Now reset the linux user
fogproject's password with
sudo passwd fogproject", that’s referring to setting the Linux user account with the password from the
/opt/fog/.settingsfile, correct? It’s not explicitly stated and I don’t want to cause myself (or you) any more headaches than already incurred.
@jvenus Ah yes, I can feel another voyage is in your future: https://forums.fogproject.org/topic/11203/resyncing-fog-s-service-account-password
How did that get messed up?
@george1421 Quite the journey so far indeed. I’m grateful that you’ve been helping me. Otherwise, I’d have probably just issued USB drives by now.
aaaaaand another error… At one point, I edited the /opt/fog/.fogsettings file and changed the ‘fogproject’’ username’s password from what it had to ‘password’. But, that’s a different file. Looking into /var/www/fog/lib/fog/fogftp.class.php file now.
@jvenus So looking back on this thread what can we state was wrong?
- Strangeness in capturing a good packet capture.
- Needing to get the right pxe boot options configured in your firewall.
- Virtual box and undionly.kpxe
- Sending a bios based boot loader to a uefi system.
- Needing to update to the latest linux kernel to get the needed drivers for the hardware.
Wow you have been on a journey with this issue.
@george1421 Yep. That’s where I did the update. Updated to 5.6.18. The 5510 boots into FOG menu, performed full registration & inventory, and is now capturing the image from that machine. Amazing help. Thank you!
file /var/www/fog/service/ipxe/bzImagesays 4.19.101. Updating kernel to your recommendation now.
@george1421 Ok. I was unaware of the differences before. But that makes sense. Changing the bootfile-name to ipxe.efi gets the 5510 to boot into the FOG menu. But, as it appears nothing wants to be easy for me, there is another issue with the 5510 registering. I will be going through the forums trying to find an answer. I had to split the image because the forum wouldn’t take the original full size.
@jvenus Lets be clear ipxe.kpxe is only for fixing the booting issues with virtual box. In general use (physical machines) use undionly.kpxe for bios and ipxe.efi for uefi systems. Understand these two files are only used to get into the FOG iPXE menu (period). Also understand that these boot loaders are firmware specific. You CAN NOT boot a uefi based system with undionly.kpxe, conversely you can not boot a bios system with ipxe.efi. If you have both types of hardware in your environment you can not use static dhcp settings. If you have a windows 2012 or later dhcp server, or linux dhcp server then you can setup dynamic pxe booting based on the target computer.
Once imaging starts then FOS Linux takes over and iPXE is history. For this make sure you have the version 5.6.x series of kernels installed. Understand this is not the fog server host OS kernels but the kernels sent to the target computer for imaging.