@eruthon said in Acer Z3-605 AiO - Single Disk (resizable):

So now just for explanation: what could be the problem here?

There is no simple answer to this as you are describing various different issues. Let’s see if we can tackle those one by one. It might be wise to open new topics in the forums as we go along to focus on the different issues and not loose track. Depends on how dare you are so solve all of them.

this week at work we wanted to upgrade 2x Acer Z3-605 AiO from 500GB HDDs to 240GB SSDs. Systems were installed with Win10 with GPT partitioning and UEFI boot.

We tried file ipxe.pxe with IPv4 Network Stack iPXE, which resulted in restart before even downloading bzImage.

Have you tried other UEFI iPXE binaries like snponly.efi or snp.efi yet? The next step would be to compile new iPXE binaries from the latest source code to see if that fixes the PXE boot issue in UEFI mode. But we better look into the other this first.

We changed UEFI to Legacy (and undionly.kpxe) and used this with Single Disk (resizable);

That’s a good step to get around the UEFI PXE boot issue. FOG doesn’t care which mode it PXE boots in as long as it does it will start the task and do its job.

it managed to upload everything into the /images/dev folder, but the PC restarted and the task started again in infinite loop. This issue isn’t happening with other PCs, so I don’t think it’s FTP related.

Was the image moved to /images/#IMAGENAME#/ after the capture? I am fairly sure it was not. Sounds like FTP/disk space/access rights issue or the image capture ran into an issue and did not finish at all. Did you pay attention to the messages on screen when the capture was running? We need more information to be able to help with this.

We changed the Single Disk (resizable) to Single Disk - Multiple Partitions (not-resizable) and it managed to upload the image succesfully. Or at least it shows Image Size on Server now.

Better to check the files in /images/#IMAGENAME#/ on the server than relying on “Image Size on Server” information when in doubt if capture worked correctly. The non-resizable type won’t help you in this case because you can’t deploy it to the smaller size SSD.

FOG version 1.5.9 stable

This version of FOG is not yet able to capture and deploy an image to a smaller size disk if there is a recovery partition at the end of the partition layout. Find more information on this in the forums: https://forums.fogproject.org/topic/15025/move-partitions-on-gpt-layouts-need-people-to-test

@novaholic said in Any UEFI client with more than 2 network interfaces:

But in a UEFI machine with more than 2 NICs when I select ‘Deploy Image’ I am prompted for the FOG users credentials. After entering the credentials the ‘Client System Information’ item runs for some reason.

Sounds really strange. I was just going to try and replicate the issue but I couldn’t. Worked all fine. Then I read again and figured that I can’t replicate in my test setup because I use VirtualBox here and that is not able to PXE boot in UEFI mode unfortunately. Maybe others can look into this.

Don’t think I have ever seen or heard about this kind of issue you describe here.

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.