@noelpd sure enough its exactly as you said. Let me check
Posts made by george1421
-
RE: LDAP Plugin - ID Must Be Set To Edit Error
-
RE: PXE boot hanging on HP Compaq Pro 4300 SFF PC + Nuc
@joesay This looks like its passing the tests.
Just for the sake of argument (because we’ve seen a rash of this issue lately) can you place a dumb (unmanaged) switch between the building switch and the pxe booting computer and see if allows you to register? I’m seriously doubting my self on this one, but we need to rule it out.
-
RE: LDAP Plugin - ID Must Be Set To Edit Error
would you mind posting a screen shot of the actual error so we can see what values are in the fields? That error is understandable and not at the same time.
-
RE: Help trying to create USB PXE Boot - Where is ipxe.efi?
@caw001 If that is the process you followed then something is not right with either the fog server or the usb module. Let me look into it. The kernel parameters don’t look correct. There should be more info in the kernel parameters almost like the grub config file is damaged. It should list the web server and storage info.
-
RE: PXE boot hanging on HP Compaq Pro 4300 SFF PC + Nuc
@joesay It also looks like you need to sync that monitor with the computer. since the image we need to see is actually off the left edge of the monitor.
-
RE: PXE boot hanging on HP Compaq Pro 4300 SFF PC + Nuc
@joesay We really need to see the enter screen for the last one.
Also have you run the hardware compatibility test (from the pxe boot menu) on these hardwares?
-
RE: PXE boot hanging on HP Compaq Pro 4300 SFF PC + Nuc
@joesay can we get a screen shot of the last picture with the entire kernel parameters.
-
RE: PXE boot hanging on HP Compaq Pro 4300 SFF PC + Nuc
@joesay Something went sideways when you tried to upload your pictures. I can say a clear screen shot taken with a mobile phone will help set the context of the error.
-
RE: Help trying to create USB PXE Boot - Where is ipxe.efi?
@caw001 You hit one of the caveats of booting this way. The fix is simple.
Schedule the capture/deploy task first then usb boot and select capture.
The very poor error above should say (IMO)“Hey dummy, give me something to do before booting me via usb” but the developers nixed that error message.
-
RE: FOG server not replicating drivers correctly to secondary node
@themcv chmod on both source and destination /images/drivers folders?
If that is the case and you restart the fog image replicator service with no joy then we will need to get the @Developers involved for additional debugging steps.
-
RE: FOG server not replicating drivers correctly to secondary node
@themcv On the receiving storage node (assuming its a linux fog server) can you look in /var/logs there should be a log file for the ftp service. Check to see if there is any useful error messages when the drivers try to replicate.
The images replicate like they should, the drivers and images use the same replication engine.
The ftp process works.
Have we check the permissions on the master FOG server to ensure the directory and file permissions for /images/drivers match /images/<image_name>?
If Tom is saying its not a bug, then it has to be something simple we’re missing.
-
RE: FOG server not replicating drivers correctly to secondary node
@themcv OK one comment first, make sure you protect these drivers to ensure they don’t get accidentally overwritten.
So the next steps…
- Go to the remote storage node configuration on the FOG server’s web gui.
- Collect and document the user management ID and password from the web gui.
- From the master node ftp to the storage node in question using the management user ID and password collected from step 2.
- Change to the /images directory using the ftp client.
- Create a directory in /images on the storage node (we are testing permissions)
- put a local test file from the master node to the remote storage node in that new directory.
- rm that file you put to the remote storage node.
If you can test the mechanics of the replication then we will move it over to a bug in 1.5.0. But test the mechanics first.
-
RE: Windows 10 - Sysprep Image For Upload
@avaryan FWIW, you can start with a online generator to build your basic win10 unattend.xml file: http://windowsafg.no-ip.org/win10x86_x64.html To that we add in the section to load the drivers from a known location. We have to do this because some driver are needed for the OOBE process (we use a single image developed on a vm for all computers in our fleet) to run successfully. Then in the setup complete we use dism to inject any drivers missed during the initial OOBE process (mainly because some hardware is hidden behind other devices that needs it driver loaded first).
In our deployment process we use the unattend.xml file to connect to AD and not the fog client. We calculate the target OU based on several factors that is calculated at deployment time. This dynamic OU selection isn’t possible using the standard FOG environment. So we use a post install script in fog to update the system’s host name, location, timezone, OU location and a few other things that escapes me right now.
Since we use MDT to build our reference image you don’t need to mess with audit mode to default user profiles that is managed by the mdt process.
-
RE: DHCP server doesn't see the client request
@olivetree Well then, now I think its a spanning tree issue. The (dumb) unmanaged switch keeps the building switch’s port from winking as the pxe client boots. The standard spanning tree protocol listens for 27 seconds for a bpdu packet before putting the network port in forwarding mode. Where the fast stp protocols starts forwarding right away and then listens for a bpdu packet. During the pxe booting, FOG iPXE menu, FOS booting process (such as in a deployment) the target computer’s network link will wink twice resetting the 27 second timer each time. FOS boots so fast by the time the port starts forwarding its already given up on trying to boot. So the unmanaged switch helps us test this process by keeping the STP timer at 0 and the port forwarding.
You will need to get with your networking admin to try to understand why standard spanning tree is enabled.
The other thing we have see is that the dumb switch also interrupts (in a good way) the miscommunication between the target computer and the green ethernet (802.3az) handshake with certain realtek chips. Its more likely its a spanning tree issue over green ethernet, but we have seen both happen.
-
RE: Unable to restart DHCP and TFTP services using default password after 1.4.4 update
@sebastian-roth I forgot updating this thread yesterday. After a chat session we agreed to do a TV session. There was a number of things that went wrong with the upgrade. The first was using the linux
fog
account for system management. The fog installer change the linuxfog
user’s password to something and (I feel) the fog installer didn’t complete the first time since not all of the info was saved to the .fogsettings file. So the fog user password was not saved in the .fogsettings. It was a bit of a bad situation.The OP had to go through the ubuntu password recover process to gain control of FOG server’s
fog
account. Once that was done, he created a new user for FOG server administration and then switched to that account for system administration. He was using isc-dhcp for the imaging dhcp server on an isolated network because of some incompatibilities with the primary dhcp server on the business network. When trying to complete the 1.4.4 upgrade again the installer was aborting because of some missing settings in the .fogsettings file. We decided to disable the isc-dhcp server and switched over to dnsmasq to supply the missing pxe boot information. We had to call off the debugging do to end of business day. He has to get with his networking engineer to update their dhcp-helper service to include the FOG server IP since the fog server is on one subnet, dhcp server on another, and the pxe booting clients on several other subnets.I feel the OP is pretty close to getting his fog server operational again with everything connected to the business network.
-
RE: FOG server not replicating drivers correctly to secondary node
@themcv It is replicating the images OK, just the drivers are failing?
Did you create a fake image definition for the /drivers directory on the master node? -
RE: Windows 10 - Sysprep Image For Upload
@noelpd We also started with our win7 unattend.xml file for our Win10 deployment. And also like sudburr rewrote it when we reached our final golden image to do some things the windows 10 way.
For our reference image we use MDT to build that for us. We took the time to setup our MDT task sequences to give us an automated one touch reference image build. We can either create a thin image or a fat image by activating one folder in the task sequence. This automated process give us a consistent reference image since we rebuild our golden image ever quarter with the latest windows and application updates. That way when we deploy the image it is never out of date more than 4 months from current with updates. Our mdt build also automatically installs all windows updates when the golden image is built.
Now once the golden image is built we have a mdt step to copy over our standard unattend.xml file to the target computer. Then we sysprep and power off the computer using sysprep (this is an important step to have sysprep power off the computer to ensure everything is closed properly).
Then we capture with FOG.
On the deployment side we will deploy the captured fog image, then using fog inject the correct drivers for the target hardware, then also update the unattend.xml file with deployment time values. Once the computer reboots then OOBE takes over and fog is out of the picture.
FOG can push out a 25GB Win10 image in just a bit over 4 minutes. The rest of the time is OOBE completing the workstation setup. When the login prompt appears its either ready to move to the desktop (if a fat image has been pushed) or ready to load any custom applications.
-
RE: FOG server not replicating drivers correctly to secondary node
it looks like its syncing to me. Do you mean to tell me that on the storage node you don’t have a /images/drivers directory?
-
RE: Unable to restart DHCP and TFTP services using default password after 1.4.4 update
@mattbrown Is this fog server in production or are you still in a pilot phase?
What linux user account do you use to manage this fog server?
-
RE: IP Address changing
If you changed your fog server’s ip address after installation then follow the guide here on the wiki: https://wiki.fogproject.org/wiki/index.php?title=Change_FOG_Server_IP_Address
The thing the wiki doesn’t tell you is after you update the .fogsettings file, rerun the fog installer script to fix all of the remaining bits.