I’m not sure what the problem is at the moment (not enough info yet), but this error has nothing to do with the target computer.

“Unable to locate image store” At this point in the deployment, FOS (the customized linux OS that runs on the target system) maps a local directory back to the FOG server. Once it does this then partclone will take over and move the bits from the fog server to the target computer. So where its failing is FOS can’t reach the FOG server or storage node to map the directory.

First thing I would do is look on the fog server console see if in /images/dev there are directory names that look like MAC addresses. If yes then your image uploads are not completing. Then look in /images directory to see if you see directories with names that match the image name you are trying to deploy.

When FOS throws the error unable to locate image store. It will print out a bunch of variables at the end of the error. Those variables are important to debug what went wrong. Take a clear picture of the error with a mobile phone and post it here. Lets match up the variables to what fog thinks its doing.

@azm9s These post install actions are done by the fog agent (client) software that gets installed on the golden image before image capture. Once install and started after windows is done, the FOG agent will rename the computer and then connect it to the domain.

Do you have the fog agent installed in the golden image before image capture?

An alternative to using the fog agent/client is to let the unattend.xml file in windows rename the computer and then connect it to active directory. Either way should work.

@cjiwonder Well this is the strangest pcap that I’ve seen in a while. I finally found a uefi computer pxe booting at 8.3 seconds (you have a very active dhcp network). And the request is from 192.168.200.1.

Your dhcp server is telling the client to get ipxe.efi from 192.168.200.3. Is that your fog server? The dhcp transaction looks normal and from the dhcp side should work.

It looks like you used wireshark on the same subnet as your dhcp server? I would have expected to see broadcast messages from the pxe booting computers instead of unicast messages between the routers and dhcp server. That’s OK because we now know that the dhcp server is sending out the right boot file information (assuming that 200.3 is your fog server). If you would have used the tcpdump command from the fog server we could/should have see the target computer requesting the file to download. That would tell us if the file was actually being sent to the pxe booting computer. But from the dhcp side it looks good.

@Paladin1 First the wipe speed is controlled by the wipe method + target hard drive + processor speed of the target computer. The FOG server and/or network has no impact on the speed it takes to wipe a hard drive.

You really can’t do much about improving the wipe speed with the hardware. The hardware you have is all you have. The wipe method is a sliding scale between efficiency and security. A one pass data wipe will be of course faster than 3 to 7 pass DoD mandated wipe (be aware this DoD wipe is only really effective for HDD, SSDs are good with just a single pass wipe.

So using the FOG utility to fast wipe a hard drive uses a single pass wipe method. The full wipe method uses a 3 pass wipe (i.e. writes to every block on the drive 3 times).

You can use an alternative disk wiping tool like dban and have fog send that tool to the target computer via PXE booting if the standard FOG wipe command is not what you are looking for.

Lastly you need to be aware of technical limitations of the media you have. For spinning disk I’ve typically seen on average for a single disk a maximum speed of 90MB/s (I have seen as high as 120MB/s for certain drives) If you were going to use a single pass wipe on a 2TB hard drive it would take 7 hours-7 minutes-11 seconds to write to every block on that drive.

For SATA SSD drives I’ve seen on average 500MB/s for that same 2TB ssd drive it would take 1 hour-16 minutes-53 seconds

And to round out the numbers for NVMe drives on average write speeds of 1500MB/s it would take about 26 minutes for a single pass wipe

ref: https://techinternets.com/copy_calc

@cjiwonder If the fog server and pxe booting computer are on the same subnet then use the instructions in the link I previously provided to generate the pcap file. This will give you the entire pxe booting information and not just the dhcp part you would get from wireshark.

But to answer your wireshark question, when you first startup wireshark you will be prompted with this screen. In the using this filter section enter port 67 or port 68 and then double click on your ethernet adapter and the capture will start. With this filter you will only see the dhcp booting packets and not all of the network data packets.

Now pxe boot the target computer until you get the error. You should see at least 4 packets (Discover, Offer, Request, and Ack) this is the DORA process. The Discover and Request come from the target computer and Offer(s) and Ack from the DHCP server. The Offer packet tells the target computer which file to load from the tftp server. This same process is for both wireshark and tcpdump using the fog server. You can review the tcpdump output with wireshark if you want.

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