@dustindizzle11 Sorry for my late reply. There is a side way you could go with this now that you know how to modify the init.xz image. Grep yourself a copy of the current script and exchange the one you posted with this new one. See if you can make it work with this. Just an idea for a quick dirty fix.

Try different hdd exit types. Look up the host in Host Management, and on it’s general page you’ll see two drop downs towards the bottom for hdd exit types, one is BIOS the other is UEFI. so the mode that the computer is operating in determines which of these settings will apply. I would first recommend trying Grub, then if that doesn’t work just try one at a time - do a full reboot between each try.

@george1421 Yes the grub menu that is specified as exit. As with goes into bios i meant that even if i don’t boot to network (no cable), computer wont boot from deployed (Win10 image) hard drive and since it can’t find operating system it goes into bios settings. But that is problem with my image or with bios settings. Maybe the problem is only one partition i tend to merge recovery 500mb partition with the rest. But that is fixable i guess, i am just glad that now after fog upgrade the deployment to NVMe disks works. Also thank you for the tip about KBs updates for Win7.

@Tom-Elliott @george1421 you guys been a world of help and I just want to help back anyways I can with what I got.

So it is all good, I got the USB FOS disk working, but no need. All I had to do was use the OneLine+ Ethernet adapter and it resolved all my issues. I was able to capture and deploy images with in 2~5 mins. This X1 Gen 4 was a big headache but this PCIE 3.0 x4 SSD should be worth it… I hope.

@maria_reed Given that it works fine on other models, I’m guessing the issue here will come down to drivers. Some of them likely have slightly different hardware (bluetooth tends to be a bitch here) that will cause BSODs/reboots, etc

If not drivers, then most likely something to do with the unattend.xml file.

@george1421 I’ll double check and see if there are any updates and let you know 🙂 I didn’t actually think to check the firmware. cheers.

@Chubert There are some bits just need to be flushed out. The easies way is to use the fixparts command. If you reload windows you will end up in the same spot and only have accomplished just burning time.

IF you want to reload windows, use a brand new hard drive or one that has never seen a gpt format. That is the way around this issue.

You may be able to clean the disk (destructively) using this process. I say “may” because I haven’t done this route I use fixparts. https://technet.microsoft.com/en-us/library/cc725797(v=ws.11).aspx The downside is that you will have to reload windows and recreate your reference image.

@Sebastian-Roth You are right that firmware is for the fiber (10G) adapter. While it did fix the error in the log its not adding any real value for the OP or for FOG in general. But too, I’m still not seeing FOG as a good tool for cloning servers because of the other mix of hardware (you won’t find in desktops). I would say remove the firmware and have the OP test again now that its working in his environment (because the other roadblocks have been removed).

@george1421 it depends how the nic is designed to handle the fw but typically yes a full/cold power start should correct for that iteration.

@Wayne-Workman I already thought in create a virtual server to work as DHCP in a specific scope and connect the FOG server and the clients in this special scope.

I think is the only possibility inside my environment.

I can say I have both the Extreme 12 (7204) and Extreme 14 (7404) on my campus and I’m running the 1.3.0-rcX series of FOG and both image properly. I have mine setup in legacy (bios) mode. They imaged with our standard Win7 build. You will need the newer kernels to support the intel nics as well as the NVMe disk (if that is in your model).

@sloeckle Just for clarity I was wrong in my post. If you are running FOG 1.2.0 the newest kernels you can run must be less than version 4.4. That means you will need 4.1.X and less than 4.4.0. The kernels 4.4 and newer requires code that only exists in FOG 1.3.0.

Your final answer may be to upgrade to the 1.3.0-rc7 (or what ever is the latest in the 1.3.0 series.

@drewski Good job!! Yes the FOSL usb can be removed once the FOS engine starts. The usb is only the delivery system for the FOS engine. FOS runs out of memory once loaded.

@george1421 said in Dell Inspiron mini 1012 ipxe initialising devices problems:

For FOG 1.3.0 and bios based computers you should use undionly.kpxe

undionly.kkpxe actually works more often, with more systems than undionly.kpxe

Further, any system compatible with undionly.kpxe is also compatible with undionly.kkpxe so we have been recommending the .kkpxe version. This is also the file used for BIOS systems in FOG’s ISC-DHCP setup because it is more compatible.

@george1421 said in Fog .032 and HP8000 elite:

you are on 1.3.0-rc1we should not be talking about pxe.krn at all. For bios you should have undionly.kpxe or undionly.kkpxe and for uefi systems ipxe.efi.

+1,000

That’s what I was thinking since it was first mentioned.

@Psycholiquid Understand that I don’t know the Surface Pro, but it was my understanding that you could use MDT to build your reference image with all of the Surface toys built in. https://blogs.technet.microsoft.com/askcore/2014/07/15/deploy-windows-to-surface-pro-3-using-microsoft-deployment-toolkit/ (Yes I know this says surface 3, it was the first one I hit on in my google-fu search)

@Nicolas-Bricet

We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.

Thanks,
Wayne

@Tim-Trageser

We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.

Thanks,
Wayne

@nicked

We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.

Thanks,
Wayne

@SusejNatas Go ahead and update again. RC-4 is out.