@george1421 @Tom-Elliott
Luckily I could schedule a meeting with my System-Admin today, and he tried turning off the serving of the WDS boot file - seems in the configuration of option 66 and 67 of our companies DHCP server was an old Windows Server that served a meaningless WDS file, we changed it to my FOG Server and the issue is now solved.

I am very thankful for your first-class support and I apologize for the inconvenience! You guys are my heroes!

@george1421 said in Dell Optiplex 3080 - UEFI - PXE Boot E-21: Remote boot cancelled.:

Side note: If your network doesn’t have a dhcp server I would personally use isc-dhcp server on your fog server over dnsmasq. I would use dnsmasq if you have a dhcp server run by someone else and can’t update settings. In this case dnsmasq would supplement your unchangeable dhcp server.

THANK YOU!

I set up isc-dhcp and it’s working like a charm.

For any future people reading:
I modified /etc/dhcp/dhcp.conf with the below config.
I disabled dnsmasq. systemctl stop dnsmasq.service
I started isc-dhcp service dhcpd start
I tsuccessfully PXE booted with my Dell 3080 a few times.
I permanently disabled dnsmasq. systemctl disable dnsmasq
I set isc-dhcp to start automatically. systemctl enable dhcpd

option space PXE; option PXE.mtftp-ip code 1 = ip-address; option PXE.mtftp-cport code 2 = unsigned integer 16; option PXE.mtftp-sport code 3 = unsigned integer 16; option PXE.mtftp-tmout code 4 = unsigned integer 8; option PXE.mtftp-delay code 5 = unsigned integer 8; option arch code 93 = unsigned integer 16; # RFC4578 use-host-decl-names on; ddns-update-style interim; ignore client-updates; next-server 192.x.x.7; authoritative; subnet 192.x.x.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; range dynamic-bootp 192.x.x.200 192.x.x.254; default-lease-time 21600; max-lease-time 43200; option domain-name-servers 192.x.x.7; option routers 192.x.x.7; class "UEFI-32-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00006"; filename "i386-efi/ipxe.efi"; } class "UEFI-32-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00002"; filename "i386-efi/ipxe.efi"; } class "UEFI-64-1" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00007"; filename "ipxe.efi"; } class "UEFI-64-2" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00008"; filename "ipxe.efi"; } class "UEFI-64-3" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00009"; filename "ipxe.efi"; } class "Legacy" { match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000"; filename "undionly.kkpxe"; } }

@ice4192 Like this?
https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence

@Eruthon Thanks for the quick feedback. Should be all fine now I think. No need to post partition files as long as it works for you now.

@novaholic Hi,
I am facing with the same problem.
Have you managed to fix it?

Thanks

Alrighty, so my work-arounds for this issue were to use a virtual drive of 28GB to make the original image, alternatively you can delete the 4th partition to make imaging completely compatible, but you lose the ability to do an OS reset in Windows.

If you move the partition to where it used to be in v1909, Windows can’t find it and that also loses the ability to reset, so if you have to move it, just delete it i guess…

another alternative if using clonezilla you can image and use gparted to first move the 4th partition to the end of the drive, then resize the 3rd partition, this seems to work fine without losing the option to reset, tested on 2 different machines, a Clevo Laptop and an HP All in One.

Otherwise typically just make sure the drive you are imaging to with FOG is generally larger than the source disk you imaged from and everything should be fine… generally speaking…

@Fernando-Gietz said in Dell Optiplex 7050 and UEFI boot. Failed:

I wonder if is a miracle that it has worked well until now in the other hardwares

I’m glad you have it working now. Yes its strange why you didn’t find another system with the same issues. But that is why I included both, I ran across a system that would boot with the netboot info alone.

Just for the notes: I pushed a fix for populating the “Working with node” column properly. But still I don’t think this is causing @TheDiskDrive’s issue. Please post a picture of the error you see and we should be able to help.

@foguser9856 said in X1 Yoga Black screen after init.xz:

Is that something I can change?

Unfortunately that is one of the caveats of booting this way. You loose the dynamics that iPXE provides.

But booting FOS via USB does tell us that there is nothing wrong with the kernel or the inits. It appears to be the handoff between iPXE and FOS, or you have flaky firmware on that yoga.

Has the firmware been updated to the latest release on the yoga?

@Quazz True, but I wan’t to see what can be done with UEFI. In the future I will make almost all my deployment by UEFI boot. So I hop it will work find, I see than UEFI is not standardize as Legacy. So it was to understand.

@quinniedid OK in my test lab I’m running the build listed in my post. That is with 6.5u1 and the Oct 2017 patch. Point being if I can get a few minutes of time I want to see if I can duplicate what you are seeing to see if VMWare addressed/changed/fixed the issue with a vSphere update. I don’t know one way or the other, but this sounds like a uefi firmware issue to me.

I just wanted to post to close this out.

I got a test environment working with better switches and FOG was able to pass 64-bit UEFI traffic correctly the first time, every time. Thanks all for the big help! I really appreciate it!

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

@amo862 said in EFI Chainloading Failure - Venue 11 x86:

However, is there a way that I could write a separate boot.php file that only called i386 boot files and specify it in the TFTP x86 efi files or DHCP boot options or something?

Do what JJ Fulmer below said, that’s the best advice.

@andrewg78 What I want you to do is start a new thread.

I want you to pxe boot the target computer using FOG 1.5.4 and the post a clear screen shot of the exact error. Lets work through why its not working on your hardware there.

@Sebastian-Roth to be honest, it was an attempt at comminizing the files so they were very similar between efi and non efi. It was not to hurt anything, but a way to make things more similar.

It’s this separation that you see two ipxescript files as well.

@xcvtop said:

@Wayne-Workman Hi I am going to try fedora. Is there a link to fedora 21 you would recommend as safe to download? or is it literally as simple to to install on Fedora 22 and change “yum” to “dnf” in the commands?

The FedoraProject hosts torrent files for Fedora 21 and YES they are COMPLETELY legal to use - because the software is open source and free, and p2p is legal as well when used legally. The torrents hosed there are safe - and come with hash values of what the files should have. So what you get would be legit.

Also - you can use Fedora 22 as well - and just change yum for dnf - and skip the MySQL stuff, the installer will install mariaDB instead of MySQL for Fedora 22. There are notes on this at the bottom of the article.