@joesay You are welcome! Feel free to ask again and even open new threads if you run into issues again. We will try to help and get things fixed!

@mrcur Great!! rEFInd is a great boot loader (once you tell it where to and not to look).

What’s the contents of that system’s image d1.fixed_size_partitions.

What’s the contents of:

cat /images/<imagename>/d1.fixed_size_partitions cat /images/<imagename>/d1.partitions cat /images/<imagename>/d1.minimum.partitions

This, too me, sounds liek the image was captured before our tests for “fixed” partitions became a little more proper and it resized something that was expected to be fixed size. What partition was it giving this issue on?

@firej8 if your fog server and pxe booting client are on the same subnet you can use the fog server to eves drop on the pxe booting process. Here is a tutorial: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Upload the pcap file to a google drive or dropbox. If you are uncomfortable posting the link to the form use the forum direct message and send the link to either Sebastian or myself and we’ll take a look at the pcap and keep it private. When we have an answer then you are free to tear down the pcap from your google drive.

it’s all about network througput and storage fastness comparing to the network speed 😉
would be interesting to see the deployment speed with a native 10gbit lan and ssd raid for storage 😛 …and sure the client should have ssd too.

But i can tell you 1gbit lan and hdd in the storage node can easily deploy a 16gb image within 2 minutes to a system with ssd 😉 i see it daily happen again and again hehe

Here is one way to go about it.

Acquire a usb flash drive that is at least 4MB in size (yes I said only 4MB, larger will work but we only need 4MB of space). Format that usb flash drive - fat32. You can do this on a windows box or a linux box. The format must be fat32. On that newly formatted flash drive create the following path \EFI\BOOT (case should not be important, but use all caps as I posted). Now you will need 2 of the iPXE files from the fog server. Copy /tftpboot/ipxe.efi to \EFI\BOOT as BOOTX64.EFI Copy /tftpboot/i386-efi/ipxe.efi to \EFI\BOOT as BOOTIA32.EFI Eject the usb flash drive and then attempt to boot this Dell laptop device from the usb drive using the device’s boot menu.

Taken from here: https://forums.fogproject.org/topic/7435/uefi-pxe-boot-asus-t100-tablet/79

What we will be doing is bypassing the on board pxe roms and loading iPXE right from usb flash drive. Understand this method will only work if iPXE has the drivers built in for this usb network adapter. If this route won’t work for us we have one more last chance option.

I’ll get that info for you tomorrow morning when I am back in my office. I’ve actually yet to open the laptop up. All other stuff isn’t going to be a problem.

Thanks…

@theterminator93 I dug through the iPXE code and read Intel’s PXE spec but I am still not sure why it would hang/loop/lock up (?) right at this point. This is where iPXE calls basic PXE functions (provided by the NIC’s PXE code) to cleanup the base memory before handing over (e.g. to the linux kernel) - explained here. As far as I understand the PXE specification was never very clear and therefor different vendors implement those PXE functions in a different manner.

Years ago in the early days of iPXE (was called Etherboot then) the developers were not sure about the order to call those functions.

There are other PXE boot loaders out there doing things differently. For example see the pxelinux code. It even mentions that iPXE is doing it differently in a comment. Would be interesting to see if pxelinux is doing fine on your USB NIC. This is easy to test as we still have this stuff from the old days. Please change your DHCP option 67 from undionly.kpxe to pxelinux.0.old. As well you want to change the timeout in /tftpboot/pxelinux.cfg/default to TIMEOUT 05 so it’s not just flicking through. Boot up your client and see what happens. My guess is that you see the pxelinux menu and then it properly chainloads ipxe.krn which then probably hangs as it used to with the other iPXE binaries. In case it hangs on a kernel panic then we are hitting a different spot.

As well I added more debugging statements to the code and compiled a new 10_undionly.kpxe (download, compiled with DEBUG=undinet) for you to test. Please post a picture of the messages on screen again. By the way I don’t see the pictures hosted on photobucket anymore - says “please update your accound to enable 3rd party hosting”.

I think we are good folks, sorry to bother!

Thanks for timely answers and support.

Cheers

None of this is working. So I will just continue to use it with the current version that is installed (1.3.5). Thanks for your help.

@Troye-Johnson My intuition is telling me that you have a second dhcp server responding to this request.

If your fog server and pxe booting target computer on the same subnet? If so lets grab a pcap file of the pxe booting process. That will tell us what is really moving down your wires. I have a tutorial here that describes the process. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Post the pcap to a google drive or dropbox and either IM me the link or post the link here and I will look at the pcap and tell you what I see.

Here is the errors from the FOG client.

7/14/2017 11:44 AM Service Sleeping for 334 seconds 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&configure&newService&json 7/14/2017 11:49 AM Middleware::Response Success 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/management/index.php?sub=requestClientInfo&mac=F8:59:71:B0:43:44|F8:59:71:B0:43:43|F8:59:71:B0:43:47&newService&json 7/14/2017 11:49 AM Middleware::Response Invalid host 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?clientver&newService&json 7/14/2017 11:49 AM Middleware::Communication URL: http://fogserver/fog/service/getversion.php?newService&json 7/14/2017 11:49 AM Service Creating user agent cache 7/14/2017 11:49 AM Middleware::Response Module is disabled globally on the FOG server 7/14/2017 11:49 AM Middleware::Response No Printers 7/14/2017 11:49 AM Middleware::Response Module is disabled globally on the FOG server

@george1421

Hi george,

Thanks for your answer. I updated kernel and set kernel host for new PC and it’s working now (and I buy some time). I should have found answer by myself, my bad. I will get a look to new versions as soon as I have time.

Cheers.

@David_Alvarez That’s great to hear. The secure boot being on is always a pain and you do have to turn it off for imaging to work correctly.

Thank you for providing feedback on this issue. Hopefully it will help others that come to this thread.

@wwagar Just remember FOGProject donations gleefully accepted. We need to keep the developers happily charged up with soda and cookies…

I’m glad you have it going. Your request IS under consideration.

Thank you for the advise, I’ll keep that in mind.

@Tom-Elliott It works!

But I get the message of the IP address of the interface eth0 repeated, as if IP search several times with the same itnerfaz.

Thanks a lot!

Hi everyone.

We have installed a new fog server on a virtual machine, using the latest 1.4.3 version of FOG.

Everything seems to be working now.

Still building new images to use, but so far everything is working.

Thanks for all the help and quick response times.

@Maikl Any news on this?

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