@george1421 i have this error even when i created the multicast task. when i create my multicast task i do this: I select the computer group, click basic task and select multicast task and select “check Schedule instant”. then i power on my computer and i have the fatal error unknow request type error after the machine got their IP addresses. i tried another way i’ve tried the deploy task to a 10 tablet group and this is not working i have this following error: Invalid storage group I looked my fog group storage configuration and is was set to 30 max client.

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