@george1421 said in UEFI Booting with Lenovo T470 NvMe drive:

If you capture a bios image it will only deploy to bios image configed systems. Same for uefi/gpt.

Deployment will work but booting the system will not 😉
I always deploy UEFI Images to Virtual Box in legacy mode because Virtual Box cannot PXE Boot in UEFI Mode, so i Deploy in legacy shut the machine down, enable EFI and start the VM again.

@rowebil @george1421 Have you ever tried ipxe7156.efi for your Acer System? I have to use this for HP X2’s or MS Surface’s since ipxe.efi will not boot them propperly in UEFI mode.

https://forums.fogproject.org/topic/9005/uefi-pxe-boot-how-to-do-it (don’t wonder i have used ipxe.efi there but this has changed to ipxe7156.efi)

FYI: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

@eistek this might get you started with a solid configuration. Your configuration IS very close.

https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

I reduced the server’s port speed from 1000Mbps to 100Mbps, forcing it to work at 100Mbps, but the gigabit port is the only one that keeps running.

OK, first we will try the update to version 1.4.1

I’ll let know if it works.

Thanks!

@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?