@lauren Getting the required firmware for the nic into the inits is the easier solution. The RAID controller, or the lack of available raid drivers is the bigger issue.

@Quazz The files “d1.original.partitions”, “d1.original.fstypes”, “d1.fixed_size_partitions”, “d1.original.swapuuids” are all there. The system tries to load “d1.partitions” which is missing.

So I tried “cp d1.original.partitions d1.partitions” and it works! Even with NVME drives!

This solved it for me, thank everyone!

@Avaryan We depend on the community to tell us what works. Please let us know how it goes, generally this stuff is posted here and later put into the documentation:
https://forums.fogproject.org/topic/2987/hardware-currently-working-with-fog-v1-x-x

@george1421

Fired up my test Dell Inspiron 7559 through UEFI boot and it first failed but that was my fault. I forgot to undo all the changes to the ltsp.conf I had done on Friday. After I changed the boot files all back to ipxe.efi the Dell 7559 booted just fine to the FOG menu and also successfully registered with the FOG server using the quick registration. I guess your assumption was correct about the funky setup of the Parallels UEFI VMs. BIOS works GREAT on those VMs, it’s just the EFI boot that doesn’t get through the bzImage phase.

@Tom-Elliott Sorry I was helping someone else in a chat session so I’m now just getting back to this.

Taking Tom’s specilation that iPXE was not managing the boot files correctly on this system for some reason, I asked the OP to usb boot into FOS as a test. We’ve had to do this in the past with a few other systems that just failed to pxe boot properly. The OP was able to usb boot into FOS so that told me the kernel and the init.xz were fine. I created the boot image on Apr 6, so the kernel and inits were current of that time.

Will this process work for now for imaging, yes. Is this a long term solution, I hope not. Hopefully either a iPXE kernel update or a firmware update on the target computer will fixed the issue so that PXE booting can continue to be used in the future.

@revilo Do you see a request in the apache access log when this happens? Or maybe even a message in the apache error log? See my signature on where to find those logs.

Roger that I will only post ones not in there, that was the document that led me down to finding the one for VMWare.

Try to image your device with below given steps:
Log on to Windows as an administrator
Open Dell Backup and Recovery by clicking Start, pointing to All programs and clicking Dell Backup and Recovery
Click Restore System
In the Restore System window, select the backup file you want to use to restore your system in the drop-down menu and click Next
In the Confirm window, read the caution message and click both check boxes to confirm that you want to overwrite your computer’s operating system with the selected backup file, and that the restore process cannot be interrupted or undone
Click Start. Your computer will restart into the Windows Recovery Environment. Dell Backup and Recovery will first erase your operating system partition and then install the selected backup
When the process completes a success message appears. Click Finish.
You can also take help from Dell Latitude 3450 Manual.

@Draco0068 Ok from the picture this system is in bios mode? So is it currently setup in bios (legacy) or uefi mode?

I don’t see the error in your OP. I’m just trying to make sure we are talking about the same error. I see the sanboot doesn’t work as expected.

Looking at the specs for this M700 does it have a sata hard drive or a m.2 drive?

@Wayne-Workman said in Surface 3 - Unable to obtain DHCP:

@dylan123 I added the link to your solution post in the wiki. One day I (or someone else) can go through it all and make a formal article.

Sounds great, happy to help if required in more detailed instructions if needed 🙂

@Tom-Elliott said in Surface 3 - Unable to obtain DHCP:

@dylan123 So if you added has_usb_nic=1 to the FOG_KERNEL_ARGS field in fog settings, this would be the reason you “didn’t have to add it back”. This “flag” doesn’t automatically set itself, so the only way to have it “preset” is if you entered this in FOG Configuration Page->FOG Settings->Expand All->FOG_KERNEL_ARGS

Think I was half correct with what I said, I must have had the host with the mac still added. Interestingly though, I’ve found I don’t need that command for the surface 3s.

So basically in the config > fog settings > fog_kernel_args section, that’s blank. In my host section, it only contains two laptops that are both the HP models I’ve been previously working with, no surfaces. I can then turn on any surface 3 and it will boot to the fog menu where I can either quick register it (not much point) or deploy the surface 3 image I took yesterday.
*I did a quick register of the surface 3 given I thought it automatically added the has_usb_nic=1 to the arg section however it didn’t. It still added the surface to my list of hosts though I then tried with a surface 4, it booted to the fog section but when I selected ‘quick register’ I got then ‘unable to obtain DHCP address’ type error message which suggests for the surface 4, I need to have the has_usb_nic=1 argument.

Just thought it was interesting how that worked, probably come across that though with other people that have been trying to image surfaces.

Please first update to the official 1.3.5. Soooo many changes happened in the RCs of 1.3.5 and it’s very likely that you have a bum image just because you’re on a broken RC version.

Second, are you deploying to the same model of system & same size HDD with the exact same hardware components?

Are you sysprepping?

Are both systems configured to operate in the same mode, i.e. both in legacy mode or both in UEFI mode?

@noelpd said in HP 210 Netbook (RealTek NIC) - DHCP Failed on PXE Boot:

So rebuilding a custom bzImage file will not effect it at all

No it won’t

The typical flow is PXE ROM -> tftpserver -> iPXE kernel (what you see in the OP post, and why the iPXE error message) -> FOG httpserver -> bzImage + init.xz (FOS image)

The issue is for some reason iPXE can find the nic (no problem) but it can’t pick up a dhcp address. To me this still screams of being a spanning tree issue, but you have tested otherwise.

Thanks for the suggestions! All our other systems are imaging just fine. I Dell has some kinks to work out with this system. When I try to PXE boot with the drive in AHCI mode the system hangs at a black screen and doesn’t even attempt to boot.

@drc0nc Thanks! Definitely worth a shot for $11

@oraniko can you update to 1.3.5 and see if the problem is still present?

Hi there,

same Problem…

Z400 - BIOS-Version: 7G3_0357 / 19. Nov. 2013
FOG-Version: 1.3.5

I just added to Host:
Host Kernel Arguments: “acpi=off”

Worked for me 😉

BR
Beekay

Many thanks george1421 . The FOS method worked. I was able to capture the image finally 🙂 Case closed.

Some posts showing FOG is capable of using these particular machines, but the users are using new versions (beyond 1.2.0) of FOG.

https://forums.fogproject.org/topic/8902/dell-optiplex-5040-m-2-256gb-pcie-nvme-class-40-solid-state-drive
https://forums.fogproject.org/topic/6686/can-t-register-optiplex-5040-tsc-fast-tsc-calibration-failed
https://forums.fogproject.org/topic/7443/0-10-6-client-breaking-sysprep
https://forums.fogproject.org/topic/7759/pxe-chaining-fails-on-ssd/7
https://forums.fogproject.org/topic/9587/blinking-cursor-after-booting-from-hard-drive-in-fog-menu-on-optiplex-5040s

Glad I took two different kind of images.

Single disk clone - Went through the process, on boot the file I created was still there, the only difference was it had uninstalled a lot of the drivers such as the NIC…

Multiple partition clone - Seems to have worked!

Thanks again for the help guys, much appreciated

@george1421 You’re absolutely right, thanks a lot. I upgraded to Ubuntu 14.04 / fog 1.3.4 and can boot and run the inventory on Lenovo T560 with Kernel 4.4.0 and 4.9.11