Posts made by george1421

@rurap I’ve read this a few times to make sure I understand what you are saying. If you are saying the firmware mode of the FOG server (bios or uefi) is having an impact on imaging a target computer, I don’t believe it. The firmware mode of the fog server (bios or uefi) has no control on what or how FOG images. In fact FOS Linux (the engine that clones target systems) has no viability into the FOG server’s setup. Its only interaction with the fog server is over http/ftp/and nfs.

registration and later restoring images from FOG on Proxmox, FOG uses booting after UEFI, not BIOS.

Would you explain this phrase a bit more. I’m not sure I’m understanding the problem.

@PFilip said in iPXE "Boot from hard disk" not working with RAID.:

imaging and restoring works perfectly, but I can’t get booting from PXE menu working.

I managed to get Windows Boot Manager working with rEFInd,

I need to boot to grub because of dual boot.

Booting without FOG works as expected (into GRUB).

Could it be issue that disk is seen as RAID Controller?

I’ll answer the last question first. No. If you were able to boot the target OS at all then its not a raid controller issue.

We need to make a distinction with the issue between FOS Linux (a.k.a bzImage) and iPXE. The fog iPXE menu is managed by iPXE so bzImage/FOS Linux is not in scope. I know you did not mention FOS Linux, so I wanted to remove that from the equation because you said it images fine.

Why refind is working is it is configured to find “windows” and boot it out of the box.

What you need is for iPXE to chain load grub.efi from the first partition so that the grub menu starts up correctly so you can dual boot.

I don’t know off the top of my head if a custom chain load command can be used to boot grub.efi. I know in concept what needs to be done though.

@cjiwonder said in UEFI is not booting with Windows DHCP:

PXE is not booting, could you pls help me to resolve this issue?

You really haven’t given me anything to help you other than it works for bios and not for uefi.

You have snp*.efi configured for dhcp option 67.

You haven’t provided any error message if there are any. No error messages is also a clue.

If the fog server and pxe booting computer are on the same ip subnet you can use this tutorial to capture the pxe booting process. This will tell us exactly what the target computer is being told through dhcp: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If your fog server and pxe booting computer are on different subnets, then you will need to load a computer with wireshark and use the capture filter of port 67 or port 68 to capture the dhcp process.

Upload the pcap to the forum or a file share site that you can manage, and I will take a look at it.

I need more info to be able to help solve this issue.

@JamiesonCA092 OK I think I understand the goal here.

In theory what you suggest is possible. But with Microsoft being microsoft its not practical.

Lets just talk hypothetical here for a minute.

Your system will be a uefi only system.
In the ESP partition ( disk partition 1 ), which is uefi boot. You will install grub and ipxe and refind.efi or wimboot.efi (might no be needed if ipxe can find the Windows OS partition) . You will have grub call fog’s ipxe.snp. iPXE will check in with the FOG server to see if there is anything to do. If not ipxe will exit to its default menu selection which will call refind or winboot. It will be refind or wimboot’s responsibility to find the windows OS partition and boot. The ESP partition will probably need to be 768MB in size to be able to contain grub, ipxe, and refind or wimboot. In theory it should work and FOG could clone this disk configuration.

Now enter Microsoft…

Windows 11 requires secure boot. FOG’s ipxe, refind, wimboot, and bzImage is not secure boot signed so they will not boot when secure boot is enabled in the firmware. You could get around this by including your own signing keys in UEFI and then sign ipxe, refind, wimboot and bzImage. Its possible to do, but not simple. The last part is windows thinks it owns the hardware and no matter how meticulous this system is setup, during any random windows update windows might update the UEFI - ESP partition and overwrite all of your settings.

@cjiwonder said in UEFI is not booting with Windows DHCP:

Already secure boot is disabled.

sorry I missed that in your first post.

What error do you see? Is iPXE even trying to boot?

The difference between ipxe.efi and snp*.efi is in the network adapter. If iPXE boots but can’t find the network interface then you are not selecting the correct version of iPXE. But if iPXE never boots (what I suspect) then there is something wrong with the mechanics of getting the uefi boot file to the target computer. What error does the computer screen say? Something about “NBF”?

@JamiesonCA092 I’m not totally sure what you are asking here because I can read this a few different ways.

You can usb boot into FOG for imaging, pxe booting is not require to image with FOG.

Also what you are describing taking a portable hard drive and booting off that drive and either loading the image from a network share or the local portable hard drive would be best served with a tool like clonezilla. Clonezilla could make a totally off-line imaging solution.

@cjiwonder Your issue is secure boot. The FOG Project doesn’t have signed ipxe boot loaders or FOS imaging engine. Secure boot is blocking both of them from running. Turn secure boot off for imaging and it will work for you. Once imaging is done you can reenable secure boot.

@COE Typically if the permissions on the /images directory get messed up you can reinstall FOG and it will fix the permissions.

If you run the chmod 777 /images that will make the directory world writable but not the existing files / folders under that directory. If you use chmod -R 777 /images it will change everything under that directory to world writable.

But before you do that, the linux user fogproject should have read write access to /images. The password for that user is found in the hidden file /opt/fog/.fogsettings That is the user account fog uses to move files around while imaging.

@Bristow-0 Is this a physical computer or VM? Is it possible to add a new storage device to the FOG server?

Something to understand that the fog database that lists the images is disconnected from the raw data file. You can move the image files to some place else, it won’t impact the FOG UI until you try to deploy a previously captured image.

@CheekiBreekiHelsinki you have some missing information needed in your first post.

1. What device is your dhcp server? (manufacturer and version)
2. Is it on the same subnet as the FOG server? You mentioned the VM and FOG server was on the same subnet.
3. What hypervisor are you using?
4. I assume when you say “run PXE” you are saying you are trying to pxe boot the VM?
5. Is the VM in bios or uefi mode?
6. What specifically do you have defined for dhcp option 66 and 67?

Lets start with those questions to see what’s next

@nec Good find, but I would also say that you are missing the boot-file (or whatever its called) at the pool level. That is the bootp part of the pxe booting. When you look at the pcap from the witness computer on the same subnet as the pxe booting computer. You should see both sets of values set.

I have no idea what Kea dhcp server is but the config file looks similar to the linux standard ISC-DHCP dhcp server.

@nec There is two sets if fields that need to be updated. There are the bootp fields in the ethernet header next-server and boot-file AND the dhcp fields option 66 and 67 that need to be set. Depending on who programmed the pxe boot code the target computer could look at either set of values (bootp or dhcp). Many dhcp servers set both just to be sure.

You should use wireshark on a witness computer with the capture filter of port 67 or port 68 Start wireshark and pxe boot the target computer to the error. Stop collecting data and look at the OFFER packet you should have one packet for every dhcp server that hears the DISCOVER packet.

Make sure if you only expect one dhcp server to respond that there is only one offer packet. Now look at the offer packet, in the ethernet header the next-server and boot-file is properly specified. Also validate the dhcp values 66 and 67. My bet there is something missing in the offer packet. If you can’t find the issue upload the pcap here and we can look at it.

@jmeyer Make sure you are paying attention to MB/s and Mb/s. It goes without saying there is a difference.

I wrote an article about 8 years ago now. https://forums.fogproject.org/topic/10459/can-you-make-fog-imaging-go-fast

This contained some benchmarks I did at the time. FOG imaging speed is (according to Partclone) is made up of several elements. FOG Server disk subsystem speed, the speed at which the fog server and move the image from the disk to network interface, network transfer time, the client receiving the file and expanding it in memory, and finally the client moving the data to local storage. All of those go into the number displayed by partclone.

For clarity let me present some theoretical best network speeds.

For a 100Mb/s network link the maximum transfer speed is 12.5MB/s or 750MB/m
For a 1GbE network link the maximum transfer speed is 125MB/s or or 7.5GB/m
For a 10GbE network link the maximum transfer speed is 1250MB/s

Pay attention if your network speed is getting capped at or around one of the maximum transfer speeds. I’ve seen someone in the past only get 8MB/s transfer rate. He/she had 1GbE on each end, but between the ends there was a network switch link that was running in 100Mb/s half duplex. Not saying that is your case, but stuff happens.

Now why I referenced that article above. It has the commands to benchmark your hardware. iperf3 will give you network speeds between the network interfaces and the kernel. It has nothing to do with moving fog image blocks between systems. If you put the FOS target system in debug mode you can run iperf3 between FOS Linux and the FOG server. This will give you an idea of the bandwidth you have. I would do this with a computer that is exhibiting the slow imaging speed and then one that has normal imaging speed. Lets see if the network speeds are compatible. I’m not willing to rule out is the linux kernel version 6.1.x vs 6.6.x it maybe there is something that is missing in FOS linux for this new hardware.

When you have the slow target computer in debug mode run this command to see if the kernel is complaining about the hardware/firmware. grep -i -e "firm" /var/log/syslog That should return any lines that complain about needing special firmware for the hardware.

@jmeyer said in what USB can support iPXE boot:

Do you mean using brand adapteur certified for PXE such as :

Exactly. They have to say pxe boot and then be branded to the device manufacturer. UEFI firmware is not like linux (well it is minux/linux) but in a general purpose linux it has one of every common driver, where uefi only needs drivers for the hardware actually installed in the device, there is no need for a 3com isa driver in a Dell laptop with a 14 gen processor (contrasting something really old with something new).

Typically if the uefi bios sees a uefi compatible nic adapter in the computer, the F12/boot manager will list pxe booting as an option. If its not listed then the network device is not supported by the uefi firmware.

@jmeyer said in Error PXE-E18 - Lenovo ThinkPad E16:

It’s now loading but terribly slow (average 6 Mb/s on a Gb link).

What is loading slow iPXE or the image via partclone? I haven’t been following closely the issue but I think I saw that someone tried an earlier version of the FOS kernel, like in the 6.1 range and imaging on these current lenovos went at normal speeds. I don’t know what the linux developers did between 6.1 and 6.6 to cause this slowness. Have we identified what nic adapter is installed in these computers? We would need the hardware ID of the nic to research it.

@robertkwild Yes right now pxe booting issue is between uefi firmware and network adapter. Typically the hardware vendor will have a recommended usb adapter (typically hardware vendor branded $$) that supports pxe booting, where the driver for the usb adapter is built into uefi.

I the imaging process once bzImage is loaded (FOS kernel) and you have a network issue then the issue with with the “FOG kernel”. You are not there yet in the booting process.

@jmeyer said in Error PXE-E18 - Lenovo ThinkPad E16:

I’ll put a wireshark tomorow to look what happen.

You really need to see what the client is being told and by who to try to explain why bios works and uefi doesn’t. There is something unknown going on here.

@robertkwild You have two things at play here.

1. The laptops don’t have built in nics so you can pxe boot them.
2. If you don’t purchase usb nic drivers that is supported by the laptop vendor they will not pxe boot.

You have to consider that uefi bios is much like a linux kernel. The uefi firmware vendor has control over what usb nics they support for pxe booting. If the laptop vendor doesn’t support the nic you will not be able to pxe boot. This isn’t a fog issue, its between the laptop vendor and the nic vendor.

The second issue is when ipxe boots it must have the correct nic driver onboard to boot.

The third issue bzImage boots that is the FOS Linux kernel. That is in the realm of fog developers. If the driver is available for linux, it can be included in bzImage. You will have better luck if the usb nic is a bit older and a bit more generic and linux will probably have a driver.

Now if you have a usb nic that is supported by linux but not the vendor, you can always usb boot right into FOS linux (bzImage) and bypass pxe booting altogether. This won’t work in a campus environment but will work on the imaging bench. I think I have a tutorial to usb flash drive into iPXE to get more normal imaging experience. Booting right into bzImage has a few caveats.

@davidsontiago If you are using sysprep, include the command line option to tell sysprep to power off the computer. You have this message because when you pick shutdown from the menu, windows doesn’t actually shutdown the computer but put it into a sleep state leaving some files open that FOG sees. Sysprep will power off the computer correctly for cloning or use the following command “shutdown -s -t 0” to properly power off the source computer and close all open files.

@jmeyer ok you did a lot of the initial debugging so its not the easy stuff.

The bit harder stuff is using either tcpdump on the fog server if its on the same subnet as the pxe booting computer. Or a witness computer loaded with wireshark on the target computers subnet.

If the fog server and pxe booting computer are on the same subnet you can use this tutorial to capture a pcap file: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue you can look at the pcap with wireshark or post it here and I will look at it.

or if your target computer is on a different subnet than the fog server you will need to use a witness computer with wireshark loaded. Use a capture filter of “port 67 or port 68” to only grab the DORA (dhcp) packets on the network.

What you want to look for is there will be a discover packet from the target computer that says “hello I’m here, come configure me”.

You will get a OFFER from one or more dhcp servers. This is the packet you are interested in. In the OFFER there will be a header section with the fields next-server and boot-file. These need to be populated with the fog servers IP address and snponly.efi (or whatever). This is the bootp fields. In addition if you look down in the dhcp options 66 and 67 that should match what is in next-server and boot-file fields. I’m suspecting something is not right with this section.

This is a pxe boot (iPXE) issue and unrelated to what FOS kernel or version of FOG you are running.