@rurap Well, I thought it said the current version at the top…
OK for a plan B then, with the fog server console, navigate to /var/www/html/fog/service/ipxe directory. In that directory run this command file bzImage. The file command should tell you about that kernel image with a version number embedded in it. Note the version number and post it here.
@rurap said in Slow restoration of Windows 11 with FOG on Proxmox:
I’m not sure what you meant by the FOS kernel
There is a customized linux distro that gets copied to the target computer during pxe booting. You will see that as bzImage and init.xz. To check the version of FOS linux from within the web ui go to fog settings->kernel update. From there it will tell you the version and give you options to update it if needed.
So from your testing you can rule out the OS being deployed. I kind if figured that but ruling it out is always good at helping us narrow down the root of the issue.
So now its down to the network adapter and or the disk controller/nvme. If we could use your idea of process of elimination (one you verify you are on the latest version of FOS Linux) to see where the problem isn’t.
Also we might want to schedule a debug deployment so we can get to the command line on the target system within FOS linux. I would search /var/log/syslog on the target computer for the keyword firmware to see if there are any error messages wanting a specific version of a firmware driver.
@rurap Just to add an additional bit of information the partclone “speed” is a composite rating of
If we had to rule out differences between Dell 7010 and 3910 the decompression of the image is probably not a factor because of the speed differences between a 4th Gen processor and a 12th Gen Intel processor (the Pcore-Ecore might be an issue depending on the FOS kernel). Looking at the truth table I would say the issue is either with #3 or #5.
@rurap OK just to be clear. Your fog server is running on proxmox. You are only restoring to physical computers. The physical computers in question are Dell 7010 (about 10 years old) and Dell Vostro 3910 with a 12 Gen processor writing to a nvme drive.
Windows 10 deploying to both systems are > 6.5GB/min according to partclone
Windows 11 deploying to both systems are < 2GB/min according to partclone
Do I understand the situation correctly?
If this is the case we can probably rule out the fog server and proxmox as a root cause. FOG on a capture or deploy are really not a factor in imaging because at this point its only moving data blocks between the network interface and local nonvolatile storage. All of the heavy lifting is being done by the target computer.
Also, what version of FOG are you running as well as what version of the FOS Linux (fog ui->fog settings->kernel update) are you running. Make sure you are running the latest 6.6.x version. Having an old version of FOG and FOS Linux kernel may cause this type of issue.
@azm9s said in Configuring adding to an active directory domain.:
Do I need to create an capture creation task on the site in the host settings?
Just to be clear on this task. Once you have your golden image the way you want it. Use sysprep command line switches to power off the computer, or user the shutdown -s -t 0 to power off the computer. This will properly close the files for cloning. Then schedule the task for image capture in FOG and then pxe boot the target computer.
Prior to your step file, you need to create a batch script called setupcomplete.cmd in the proper location (google it), and in that batch file use the sc command to enable and start the fog client service (this should be explained in the fog client wiki page). The setupcomplete.cmd batch file (if it exists in the correct location) will be called by OOBE/WinSetup when its all done with its bits. At this point we want the fog client to be enabled and started so the fog client can do its stuff.
Yes on the AD stuff. You will probably want the fog client to rename the computer too, or it will go into AD with a generic system name.
@Mr_____T First let me say I don’t have a clue when it comes to imaging macs. The last time I touched one was in the mid 90s.
But from working on the FOG Forums I know that people are able to image the older ones with FOG. The introduction of the T2 chip caused some issues but I was able to compile a patched version of FOS Linux to allow imaging to work there too.
Looking at your error screen I see several promising clues. iPXE is running and it can see the nic because it can see the mac address of the nic. It doesn’t appear to see the PHY interface because unless you didn’t plug in the network cable, its waiting for the link up to continue.
Did you get iPXE to run by pxe booting or usb boot drive?
I did notice that iPXE is pretty old (circa 2019). You probably want to get the latest version, yes I know you are working with old hardware.
That also raises the question, what version of FOG are you using.
Just to be clear the issue is between iPXE and the network, you haven’t got to FOS Linux bit yet. That may be the next milestone you will need to pass.
@azm9s Yes that needs to be installed before you capture the image, because its needed for post deployment actions (if you want FOG to manage those).
https://docs.fogproject.org/en/latest/installation/client/install-fog-client/
You will install the fog client before capture, but make sure you disable the service before you capture it then use the windows startupcomplete.cmd file that OOBE/WinSetup runs to reenable the service and start it. The issue is if you leave the service enabled, after deployment the fog client (if left running before image capture) will start doing its thing before windows OOBE completes giving you a botched deployment because the fog client program will change the system name and then reboot it, before oobe is ready for the reboot.
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
@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.