Dell Optiplex 9020 UEFI network booting
-
I’ve made serious progress with this.
I’ve configured a vendor class DHCP policy to hand out ipxe.efi to UEFI hosts, and it works.
I know it works because when I trade out the 64 bit copy with the 32 bit copy via CLI, everything stops working on the UEFI hosts, but using the 64 bit copy, it gets much further… I plan to make a WiKi article on how I made the policy because it’s not simple.
The problem seems to be getting the IP from DHCP the 2nd time.
Anyways…
FOG r3709
Fedora 21 Server x64Target:
Dell Optiplex 9020
with
Secure Boot disabled & UEFI network booting on, all legacy options off.Here’s what I’m seeing:
https://www.youtube.com/watch?v=0PathituA04I’ve tried all of the .efi files in the /tftpboot directory.
Additionally, when I do a TCPDump on the FOG server and transfer it to my desktop for viewing with Wireshark, Wireshark tells me that the packet size is too big…
Here is that capture file… I cannot view it so I have no idea what’s in it.
issue.pcapBIOS based network booting continues to work fine with the new DHCP policy in place.
-
Update on this issue.
I’m now on r3783 and I’m still having this issue.
I’ve also tried to connect through an unmanaged switch to see if it was timing related and there was no difference.
Any help at all is appreciated.
-
This post is deleted! -
I thought I’d share this with the @Developers because it was different.
I was able to get Legacy BIOS to work on the Dell Optiplex 9020 model, but I’m still not exactly happy about not getting UEFI to work on this model… the DHCP piece to make UEFI and BIOS type netbooting work together is in place and working… there’s just something about FOG and UEFI on this particular model or my particular network that just doesn’t work. :-S
-
@Wayne-Workman Try Symantec Ghost lol
-
I have found some Dells picky… specifically with Realtek 81xx NICs. Just to throw a dart at the board have you tried a BIOS update?
-
@brycew said:
I have found some Dells picky… specifically with Realtek 81xx NICs. Just to throw a dart at the board have you tried a BIOS update?
Nope, that’s a good suggestion. I’ll try it.
-
This is what happens when I try to upload:
This is what happens when I try to upload again:
And this is what happens when I try to run fixparts /dev/sda
-
Reading these were enlightening:
http://sourceforge.net/p/clonezilla/discussion/Clonezilla_live/thread/5d36a48f/
http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspxI should add that I’m trying to image Windows 8.1 that is in GPT format.
-
That is strange. Just at quick glance it does not look like it it getting the next server dhcp option. tftp:///default.pxe
No tftp server specified. In order to get that far dhcp should have been received. Can you try a version of ipxe with cli and manually enter in commands. Romomatic downloads are a good place to get stock ipxe efi file
-
Will pending windows updates cause the errors I’m seeing in partclone below?
-
So I feel stupid, I figured it out.
You have to schedule a check disk in windows to get past this error.
From a elevated command prompt in Windows 8.1 I ran:
chkdsk /FThis will schedule a check disk at next boot.
When that is complete, the system will reboot. You HAVE TO boot to network on that next boot otherwise windows will just dirty up the partition again. I set my computer to boot to network first, and then just used the boot options F key to choose HDD for the check disk, then just walked away and FOG was uploading like a champ. -
Bumping this thread, today at work I updated to cloud 5293 svn 4323 and UEFI network booting is WORKING for the Optiplex 9020!
ALSO, Much progress has been made in the way of GPT and Windows 8 imaging using resizable and non-resizable image types. Read more about it here: https://wiki.fogproject.org/wiki/index.php/Windows_8_UEFI_Imaging_Tips
