You may need to do a debug deploy and single step through deployment process to see if you can capture the error why the partitions won’t expand.
You may also want to download the latest inits (manually) and install them in your fog server. The devs patch the inits last week to solve a specific issue with disk expansion.
wget https://fogproject.org/kernels/bzImage
wget https://fogproject.org/kernels/bzImage32
@JJ-Fullmer Well done!! I wish I could upvote your post more that just +1.
What we are trying to identify is if this issue with the Surface Pro 4 is with the FOG kernel or the hand off between ipxe and the fog kernel. Right now we are not sure which part is falling down. If we can usb boot the fog kernel and it works in debug mode then we are pretty sure where the problem isn’t.
Thank you for giving us a hand with this issue, its bigger than just the surface pro. The uefi booting is here to stay, so we have to work it out.
@breit The boot.php script builds the iPXE menu on the fly based on what the client is asking, the state of knowledge about the clinet, and what the client is. There is no static file that can be changed. If you want to change the iPXE menu you can
Each has its drawback and advantages, but beyond step 1 you add quite a bit of complexity to your task.
@zorderelda The info you are looking for, unfortunately doesn’t exist outside of the brains of the developers. And I agree we really need to get some documentation on this to grow the list of available plugins.
I’ve done some tweaking of a few plugins and I can say they are not difficult but also a pita at the same time.
I worked on / with 2 plugins the LDAP and the Persistent Groups.
The persistent groups was created by the developers to aid in installing a sql trigger that simulates persistent groups in FOG. It is the most simple one with no menus or outward appearance that it has been installed.
The ldap plugin is a bit more complex, but it also shows you how to create tables, hook into a process. It also has a display/editor page. I can tell you the graphics at the top are fonts based on the font awesome library http://fontawesome.io/
The fog application has and calls out hooks at certain functions and as a plugin programmer you can tie into those hooks to add function to fog.
That is about it from what limited knowledge I have.
We do this for both Win7 and Win10. We have a single universal image for all different models of computers we use on our campus. These are all Dell systems but the process would work for other hardware platforms as long as you can get the drivers for the models in inf format and not as a self extracting archive.
The key is to make your reference image on a virtual machine (I use vmware) with the mimimal number of drivers, sysprep and capture that image with FOG. That becomes your golden/master/mother image. We use MDT to create that reference image so it is consistently built every time since we update our reference image every quarter with the latest OS and application updates. MDT helps us do this so that it is repeatable each time.
Then during image deployment to the target computers we use fog’s post install script function to write a custom post install script that determines the target computer’s hardware model and then we inject the proper drivers into the target system before the target computer boots into OOBE.
There are a few discussion/tutorials on this subject.
https://forums.fogproject.org/topic/8889/fog-post-install-script-for-win-driver-injection
https://forums.fogproject.org/topic/4278/utilizing-postscripts-rename-joindomain-drivers-snapins
https://forums.fogproject.org/topic/7740/the-magical-mystical-fog-post-download-script
https://forums.fogproject.org/topic/7391/deploying-a-single-golden-image-to-different-hardware-with-fog
In our environment we use the sysprep / unattend.xml file to name the computer, connect it to the domain instead of the fog client. We have some deployment time unique settings that our post install scripts inject into the unattend.xml file that’s not possible to do with the fog client so that method works out best for us.
Do you have a dnsmasq service or proxy dhcp service running somewhere?
This makes me suspicious: [error “ProxyDHCP service did not reply on port 4011” ]
For FOG you need option 66 set to the IP address of your FOG server and option 67 to point to the kernel you need to load probably undionly.kpxe
If you have the skills probably the best thing to figure out what is going on is to create a pcap file of the dhcp process. What you want to do is setup the wireshark to listen on a mirrored port used by your test computer. Start wireshark scanning using the filter of bootp || tftp then boot the target computer via PXE. Once you have the pcap file then post it here. One of the devs here loves to read through pcap files. This will really tell us what is going on.
Really either of the two hardwares will work just fine for FOG. In your environment either would be a bit of an overkill. I would stick with one of the main stream linux distributions, rhel/centos, debian, ubuntu and not go with one of the variants unless you have a specific case.
As long as your network is setup for multicasting you can image those 35 lab machines in one push, as long as you have the same image setup for all systems.
For your setup I would work on developing a single image (or group of images) that will deploy to all systems on your campus. This will give you the most flexibility as new models are brought on board.
In my environment the FOG server is running Centos7 on a virtual machine with 2 vCPU and 5GB of RAM. Image push time for a 25GB Win10 image is about 4.5 minutes.
Very nice job!! After some time we should be able to identify the most stable OS for FOG installs. This will really come in handy when thinking about which OS we might support in the future.
@asbenavides I can say these commands install Acrobat Reader DC very well. I don’t use snapins so you may need to translate that into snapin format. We use a different tool, but we deploy using the following commands in a batch file.
start /wait msiexec.exe /i AcroRead.msi TRANSFORMS="AcroRead.mst" ALLUSERS=1 /qn /norestart
start /wait msiexec.exe /i FontPack1500720033_XtdAlf_Lang_DC.msi ALLUSERS=1 /qn /norestart
There is a tool “adobe acrobat dc customization wizard” that allows you to customize the Acro Reader install (which creates the transform file used in the above command). It lets you accept the eula, makes customization to the reader install there are quite a few guides on the internet for this, just search. For example: http://www.itninja.com/software/adobe/reader-6/dc
We throw in the APAC font pack file because we do interact with Asian countries.
@jxke Yes for sure it runs in a VM. That is how I personally have it setup. I might suggest that you setup a new VM with 1.2.0 instead of trying to update something that old to 1.2.0. And then if this is a new install you might consider upgrading from 1.2.0 to a pre release of 1.3.0 because there has been many enhancements over 1.2.0 in the area of UEFI and newer hardware support. Just understand that 1.3.0 has not been released yet so it is still in a beta state. But the devs are working hard to get it stable and released soon. By setting up a new instance you will not loose access to your production instance while you setup this new server.
@tomcatkzn said in Setting up the right FOG Environment:
Could you offer the reasons why you prefer Centos over Ubuntu?
Based on recent changes to Ubugtu they seem to alter the code for some reason that causes FOG issues. Centos has always been a stable build, and that is what I run. As Wayne said, Centos or Debian seems to be are most stable OS platforms. With that said FOG does support and is tested against a large number of Linux OS distributions. Wayne runs install checks every morning against the supported platforms: http://theworkmans.us:20080/fog_distro_check/installer_dashboard.html
The issue is sure… maybe.
You can capture a single partition. The issue is deploying the image to a target computer. The existing target partition must be the same exact size as the source partition. FOG can’t push around the partitions if, lets say your copied partition is larger than the destination partition, it can’t move the next partition (i.e. Partition #2) out of the way.
@chris.dees Replication happens right away. There isn’t a way to control the replicator in the way you want from inside FOG. You can do what you want if you use cron to start and stop the fog image replicator service.
So basically you would setup a cron job to launch the replicator at 11p and stop it at 6am. The drawback to this would be there is a potential for an incomplete image being setup on a remote storage node. Because the cron job runs asynchronous of the replicator service. The replicator would finish on the next cycle, but just be aware of this.
The same concept could be used if you want to throttle the replication speed during the day, but want 100% over night. You would setup a cron job to update the bandwidth setting in the sql server then restart the fog image replicator service, and so on.
It would be grand if FOG supported this internally, but with FOG 1.3.x its not possible. Possibly FOG 2.0 will support this capability, but that version is a few years away.
@roee Just for clarity, you don’t have any lingering older image deployment systems hanging about like acronis, altiris, windows deployment server, windows RIS do you? FWIW FOG doesn’t use ProxyDHCP unless you specifically configure it. So that’s why I think there is something else in your environment.
@sebastian-roth The issue is (only guessing here), that the OP needs to setup a multicast router, or on their vlan router allow multicast data to pass through the router. Most routers have this disabled by default. One other thing is to have IGMP Snooping enabled on the switches so that the switches know who is a IGMP subscriber and who doesn’t care about the data stream (i.e. PIM Sparse Mode vs Dense Mode).
@sebastian-roth said in What can we do when we don't trust UUID?:
As described in the github issue I still think we should not add another field to the DB for that.
I’m not suggesting one way or the other here, but just opening the discussion.
Adding a new field would be possible especially if the fluid value can be calculated based on values already in the inventory database. This could be a simple (or complex) sql script delivered with a FOG update just like we do today. If the value can be calculated then it can be populated.
You do raise an interesting point, what are the impacts to the FOG Client if we move away from mac address being the key identifier? The mac address will need to be involved somewhere still with booting since iPXE isn’t as smart as the FOG programmer’s PHP skills.
@Sebastian-Roth Assuming the OP used git to replicate the fogproject repository as well as followed the instructions from the wiki page. Would the proper path be /opt/fogproject/bin/error_logs to find the log files?
@roee just be aware that there IS a dhcp server inside vmware workstation. It should only be for the internal host only networks. Make sure this isn’t configured incorrectly.
@joe-schmitt said in Service Fog Client:
when client installs, it sets the service to auto on boot, but does not start.
I guess what needs to be turned into a feature request is a msi install command line switch to alter this behavior. This switch would install and set the service to disabled. Or alter the process to require a command line switch to set the service to auto and the default would be disabled. Either way would work. Probably the command line switch to disable the service would cause the least amount of pain for already installed environments.
Most of the time the fog client is being installed before the system is sysprepped, which is causing us the most problems. So if the client installs but doesn’t start until the FOG Admins wants it to, that would eliminate that source of imaging pain. Also if we can keep the fog client from starting during reference image development, we can keep the fog client from tattooing to the defined FOG server until after OOBE is run (I’m not sure if there is a benefit there).
On the back end to turn the auto start service back on we could have a command line option for the fog client to start the client and enable the service that can be called from the setupcomplete.cmd file. Something like “c:\program files\fog\fogclient.exe /autostart” (I just made up the path and file name just as an example)