Right the NBP indicates this is a uefi device. In this case you need to use a uefi compatible boot kernel. As a suggestion, change your dhcp option 67 to ipxe.efi. Then pxe boot the target computer again.
FWIW, the undionly.kpxe is for bios (legacy) devices.
Looking at your ls command, ipxe.efi doesn’t exist. This IS an issue. Please confirm that you have ipxe.efi as well as about 4 others in that /tftpboot directory.
said in FOG won't complete when reimaging a computer.:
it just stopped finishing imaging
Can you explain exactly what “it just stopped finishing imaging” means?
I see two possible interpretations of this
Which one is it?
said in Lenovo Miix 700:
start to pxe says download MIB
Just reading between the lines here, specifically “start to pxe says download MIB”
My bet is not MIB but another 3 letter name that starts with an N like NBF (I can’t remember the exact name). If that is the case then this sysem is a uefi based computer. So we also need to know what do you have configured for dhcp option 67?
@Wayne-Workman I know in the inits that the developers added the loop for the count of 4 for dhcp discovery, which I think the timing should have put it past the 27 seconds forwarding threshold. There should be two values. There should be a loop count and then a wait time you can play with. You “could” pass a kernel parameter to adjust either. It wouldn’t be that hard to extract the inits and update the code. This way if the kernel new parameter didn’t exist then the defaults would be used.
Just in case its not a spanning tree issue we have also seen issues with certain network adapters and green ethernet (802.1az). Typically a dumb (unmanaged) switch would mask this issue. But in the OPs case they are using a pretty old dell o745, and it doesn’t have any of the green ethernet stuff.
Dell e6430
lspci | grep SATA
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 04)
@asbenavides Just so I understand this correctly. During dhcp discovery you have been hitting the pause button to “freeze” the dhcp discovery for a bit, then when you release the pause it detects an IP address and the FOS engine continues to run as it should? And you have been doing this since 1.2.0?
If this IS THE CASE this condition still points to spanning tree not forwarding data right away. You MUST enable one of the fast stp protocols.
@dureal99d that is an insanely complex advanced menu. But, it is a great example of how to implement an ipxe advanced menu.
Let us know how it goes as well as (if you can) post the efforts of your labor to help the next person with their advanced menu build out.
@MattPayerle OK so it sysprepped, launched and deployed OK upon reboot. The next step is to introduce FOG into the picture. Repeat the sysprep part, power off the vm and then pxe boot into FOG and capture the image. Then redeploy the image back to the same vm, reboot the system. Since the fog client isn’t installed then none of the fog post install actions will be carried out (make sure the early name change is not enabled too). The expectation of this test is to produce the same exact results as your previous test. If you receive the same oobe results (success) as your first test then go on to the next test.
For the next test you will deploy to a second VM. The expected results is the same as your very first test. In this case you must use your previously captured image (from above) and just deploy to a like Virtual Machine.
Understand this is the same methodical process I would use to find a flaw in my deployments. You need to back up to where you have success and then start moving slowly out to your final design. Once you have a failure then you can identify what changed between working and failure. If the deployment to a second VM works, then you need to introduce the unatten.xml so you can avoid the questions during OOBE.
Here is a great starter script for the advanced menu.
https://forums.fogproject.org/topic/7329/sub-menu-within-fog-advanced-menu
You can also create more parent menu items (in addition to the advanced menu) and use the same concept as above. For example on the same level as the advanced menu, you can create an entry for WinOS setup pxe boot another one for disk utilities and a third for debug utilities. They don’t all have to be in one advanced menu.
You have to remember that you must be on the 1.3.0-rcX build (1.2.0 will not have the utiltiies to manage the iPXE menus from the GUI) and your paste into the parameters field must be a complete iPXE menu, so you must learn iPXE menu design (or find one you can hack up to your needs /like above/. http://ipxe.org/examples
@MattPayerle said in windows could not complete the installation:
Its still not clear if this is a fog problem (which I’m thinking not) or a reference image creation issue. Of course you would have a snapshot before you sysprep (so you can restore the vm after this test), but sysprep the image on your reference image and then just boot your reference image back up. Does it startup without issue? This will test without fog in the picture. You are just syspreping the reference image and then booting it up through OOBE.
As for the logs in panther, they end with .log as well as there is a folder with DG or DC in the name there are logs in there too. You may have to copy them to the desktop to be able to view them. But they should give you an idea of what is going on with the OOBE process.
Right now its now clear of its a fog issue or windows imaging issue.
On your reference image disabled the fog client service and don’t have your setupcomplete.cmd file enable it. On your vm sysprep the image and have it shutdown. Then repower the VM without using fog to capture and deploy it. You need to see if on the same vm you can prepair an image, sysprep it, wake it up and it restores correctly. Use vm snapshots so that you don’t loose your efforts in setting up the reference image.
You should also look at the windows setup logs in the c:\windows\panther directory to see if you can pinpoint where the error is being triggered. But I’m with Wayne here, I think it is a driver issue that is causing you pain, probably video. If you look at the device manager after you reboot it, is there any indication of a failed driver?
I can say I use a process that roughly resembles what you are doing, except I’m using MDT to create my reference image in an automated manner. So it goes from DVD to a full reference image with the windows updates and base applications. This is done on a VM (as it should be done). From there I use FOG to capture and deploy the image. I also have a FOG post install script that injects the proper drivers into the image before the first OOBE boot. I use an unattend.xml file to set certain system parameters and I have the unattend.xml file connect the target computer to AD in the proper OU (the OU location is set by the fog post install script modifying the unattend.xml file before the first oobe boot). It is quite a complex dance, but the process does work.
@asbenavides well that’s interesting in that it blew my current train of thought. OK so I guess the next bit is as I suggested register a host and then schedule a debug deployment. Hopefully it will drop you to a command prompt on the target computer.
@asbenavides Whats really at issue is that you MUST enable one of the fast spanning tree protocols for the access ports. BUT right now we need to determine if spanning tree is the issue.
FWIW When a port transitions from no link to link up, with spanning tree on (and not fast stp enabled) the switch will listen on the port for 27 seconds to listen for other switch announcements. After 27 seconds the switch will start forwarding data. If you watch the FOS engine boot, its checking for a network connection in about 4 seconds.
In theory it should work for the fog server. The difficulty would be to get all of the required php modules installed properly. Once apache, mysql, and php were running properly you would need the reset of the bits like tftp, nfs, ftp setup.
The other part you will need to setup is the storage node bits. I did write a proof of concept document to turn a windows server into a fog storage node: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog
The hardest part would be get wamp working, the storage node part will work as I have documented it above.
But understand this configuration is not supported. The developers (once 1.3.0 stable is released) will be working on FOG 2.0 which is based on node.js which is portable across many platforms (even Raspberry Pi). FOG 2.0 will be a huge step, but also will create a very portable FOG installation. As it stands now FOG 2.0 is at least 2 years out of beta.
Your best choice is to install Centos 7 or Ubuntu 14.06 and install from there, until FOG 2.0 is released.
@asbenavides On a single port where you have the device connected. Can you ensure that spanning tree is turned off? I don’t usually recommend this because if forgotten can turn into a nightmare if someone creates a loopback with it. But we need to identify if this is a spanning tree issue.
That o745 has a very common nic so that should not be a problem. When FOG 1.3.0 is installed you also get the latest kernels and inits for the FOS engine (the software that captures and deploys images to the target computer). The FOS engine is failing to detect an IP address.
First see if you can disable spanning tree protocol on that specific switch port. Also ensure that any green ethernet functions (802.1az) are disabled on that switch port too. Then pxe boot the fos engine again.
If that doesn’t work manually register the host in the FOG console, then schedule a debug capture. Don’t worry we are not going to upload anything. What this will do is drop you to a command prompt on the target computer. From there we can run some debugging commands to try to understand why this system is going sideways.
I haven’t tried win10 yet, but this process works for win7: https://forums.fogproject.org/topic/7765/pxe-booting-into-ms-windows-7-setup
@Sebastian-Roth Great catch, I was only thinking about read/catch.
for reference this is the output from a Dell 6410 on ubuntu. Parsing the response may be tricky to get right every time.
sudo lspci | grep SATA
00:1f.2 RAID bus controller: Intel Corporation 82801 Mobile SATA Controller [RAID mode] (rev 05)
@lukebarone I think I understand the post. You want fog to record the firmware settings and then on a deploy reset the firmware setting to the captured values(??)
Unless you use Dell computers, not many hardware vendors have the tools required to read and set the firnware setting, period. On top of that the FOS engine (the operating system that captures and deploys images) is linux based. So what ever tool that may be available, its typically windows based, not linux compatible. Dell does have the cctk kit for linux that allows rhel/debian based linux to read and write to the firmware. So on the outside its possible to do. You do have to be careful since some firmware changes will only be active after a reboot. So it would be almost impossible to set/reset these setting during image deployment. It would be a cool concept if the hardware vendors supported this type of external “adjustments” of the firmware with a consistent API.
This issue reminds me of a spanning tree issue where the target computer gets an IP address for iPXE but then in the FOS engine it can’t pick up an IP address. This is because spanning tree take 27 seconds to start forwarding data, since the FOS engine is so fast it has already given up by the time the network switch starts forwarding data. Wayne’s recommendation to use a mini (dumb) switch will typically improve your chances of getting an IP address since the building switch port never winks (momentarily turns off and back on) net network link as the FOS kernel takes over the management of the nic adapter. Most enterprise switches have a fast start mode for spanning tree called (portfast, fast-stp, rstp, and a few other names) that is typically turned on for access switch ports.
The other possibility here is that the network adapter is not supported by the FOS engine, in this case the nic will never initialize. I quickly looked through the thread but I didn’t see any mention of the target computer you are tying to boot. What device is this? Is it a physical (on-board) nic or a usb network adapter?