@george1421 said in Slow restoration of Windows 11 with FOG on Proxmox:

Just confirming that the /var/log/messages file exists and the /var/log/syslog one doesn’t ?

I only have two files there, nothing more: resolv.conf and messages

@george1421 said in Slow restoration of Windows 11 with FOG on Proxmox:

In researching this it seems one instant the 8169 driver was being installed instead of the 8168 linux kernel driver. This will take some looking by lspci -knn | more will list out all installed pci hardware with the “kernel drivers in use” for the hardware. As a hint for looking through the big list the section you are interested in starts with “03:00.0 Ethernet controller” since that is the built in nic you found in the previous post. Lets see if its using the 8169 driver instead.

I removed the network card from the PCI slot, and only the built-in one remains, so the section probably starts at [0200] and it looks like you are right.:

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
Subsystem: Dell RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [1028:0acf]
Kernel driver in use: r8169

If I understood correctly, the problem is due to the wrong network card driver? What to do now, how to install the correct driver?

@george1421 said in Slow restoration of Windows 11 with FOG on Proxmox:

This command may help give the answer on driver than looking through the entire list of lspci commands: inxi -Naz

Unfortunately, I don’t have this command in the command line, but it seems it’s not needed since I’ve already got the answer

Just checking in here to Mark this as SOLVED. I had added the dev branch under a different folder. So the mix up was between the chair and the keyboard. Performed @Tom-Elliott Recommendations and reinstalled from my primary install and it is now working. trying to pxe boot MacBookPro’s. That’s another story, for another thread.

@Tom-Elliott

Ok thanks @Tom-Elliott - that helped me. I had a script that was failing and trying to find logs for it was difficult to get a location that it could write to, that I could find after the deployment, and i couldn’t see if it was erroring or whatever… running in deploy debug was really helpful. Thanks.

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

@Tom-Elliott Thank you Tom. I change the UUID’s by the devices names on the /etc/fstab on the “golden” machine before I capture a new image and I redeploy it, but apparently it doesn’t change anything

@george1421 Hi,

Thanks for your reply. Its strange. I am working with (almost exclusively) early 2012 hardware. My older Imacs 2009-2011 afaict pxe boot fine image with FOG w/o issue. The problem comes along when, I try to image our macbooks. They display different levels of progress before they flat out hang. I had one mbpx,y I’m almost sure it was a 3rd gen intel just can’t find it right now. I may be being processed to go out the door to our clients.

Yes the 2019 verison of ipxe was executed from a boot of clonezill 3.1.x the version I would attempt to boot from ventory stick or from an imaged usb stick would display an error regarding not having efi capability and/or hang or return to the ventoy menu. If I just let them be long enough the MBP would just restart.

So I did attempted to roll my own and ran into the same problem with the oobox downloadable iso/zip file. Hang… I am researching w/o much success with how clonezilla compiled their ipxe menu entry or how to just plain add efi capability to ipxe.iso/zip and burn it to a usb stick. I just am not knowledable enough to formulate a good question or find what I am looking for (cause I don’t know:))

So thanks again for your reply. I have a large donations of older MBP’s coming just before the holidays and I would lik to be able to make it rain.

Regards,

@Tom-Elliott

Yeah, this was my suspicion. I see both sides of it too. Sounds like I’ll have to either super simplify some of my install scripts and make some sacrifices or figure out another solution.

I appriciate the response and confirmation!

@Tom-Elliott

I’ve downloaded the file ipxescript.txt file - Does the extension needs to be renamed to something else as it’s a script (i.e. .sh (bash??)? Also, what directory do I place the script in? (Sorry for the ignorance…I’m not a Linux guru)

Thanks again guys!

@ITCC Just to be clear you complied the latest version of iPXE using the instructions I provided? If that’s the case and it failed, then there is not much we can do because something in Lenovo’s firmware causing the software to hang. If rolling back the firmware isn’t an option (I don’t know what they were correcting with the update) I think we are stuck unless the iPXE developers have any idea why it might be getting stuck.

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

@george1421 post can be marked as solved.

Do I do that or is this done by a Moderator?

@george1421 Great, thanks for the info!

@RocksAndRolls I’m not sure how much additional help I can provide here but where it failing is at the end of the imaging process, the target system logs into the ftp server on the FOG server using the fogproject user account. That fogproject user MUST be able to rename the captured file in /images/dev from the mac address and the move the directory from /images/dev/<mac_address> to /images/<image_name>.

If you have verified you can log into the fog server via ftp as the fogproject user using the password saved in the fog ui then it has to be a permission issue on the /images directory.

The image capture process is

FOS Engine -> connects to /images/dev NFS share and creates a directory that matches it’s mac address
FOS Engine -> Uploads the disk connect as the root user (on the FOS Engine)
FOS Engine -> Connects to the FOG server as fogproject user and issues a mv command to move the directory from /images/dev/<mac_address> to /images/<image_name>
FOS Engine -> Logs out of ftp and completes the cleanup before reboot.

@Tom-Elliott oh okay sorry my bad

here is my csv

test_fog_import.csv

ok, got it.

My storage pool had the other IP address, once I changed the IP of the storage pool to same subnet has the machine I am trying to clone, it went smoothly.

It is now copying at 257MB/min… is that good ?

@george1421 Gotcha. Thanks for the reply. I’ll post a picture of the error when I’m able to get back to testing next week.

I had a problem when capturing an image when the computer was in legacy mode, when it was in UEFI mode everything worked. Then I reinstalled FOG on PROXMOX and I didn’t check Legacy mode anymore, but now I just tested imaging in legacy mode and everything works. That’s why I thought it was somehow dependent on whether fog was installed in UEFI/Legacy mode. Topic to close then.

@ALV_SUPECOLES This seems to be similar to this thread: https://forums.fogproject.org/topic/17759/ipxe-initialising-devices

In this case uefi firmware was updated then iPXE stops at initializing devices. If compiling and installing the latest version of iPXE doesn’t solve the problem then we will have to wait for either iPXE developers or Lenovo to fix the problem. https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

@nicolas-moraes We have to be careful some Soho routersthe don’t behave well with pxe booting. Some will put its IP address as the boot server even if you have dhcp option 66 configured. I don’t know the edgerouter, but if there is a bootp option make sure that is turned on too.

The edgerouter is based on vyos so it should behave correctly. Make sure when you define dhcp option 66 its the IP address of the fog server and for dhcp option 67 the boot file name needs to be all lower case. Make sure you don’t have a leading or trailing white space in the name.

If you have double checked everything then get a witness computer and load wireshark on it. Make sure you setup a capture filter of port 67 or port 68 start the scanning then pxe boot the computer until you get the error message then stop scanning.

What you are looking for is the DORA sequence
Discover (sent by target computer, akin to hello world, please configure me)
Offer (sent by one or more dhcp server, I would there to be only one of these and from your edgerouter).
Request (sent by the target computer)
Ack/Nack (sent by the dhcp server)

The interesting packet will be the OFFER.

Look at the packet, there should be an ethernet header section with the following fields.
Next-Server: this should be the IP address of your fog server (this is the bootp part)
Boot-FIle: this should be the name of the ipxe file to load.

If either of those are blank some pxe clients will not boot if they look at the bootp fields.

In the dhcp options section you should see option 66 and 67 that should mirror the values in the bootp part.

just to update I downloaded windows 11 23H2 from MS admin console and then made a new image with fog and deployed it and whilst for some reason the GPO that should auto encrypt the c drive doesn’t appear to be working, if I right click it and choose encrypt with BitLocker and chose allow windows to unlock the drive automatically (which is what the GPO should do) it encrypts just fine. So its definitely something new with Windows 11 24H2 I suspect its to do with secure boot being disabled.

Edit ignore the bit about the gpo not working I moved the pc to a diferent OU for testing and it simply wasn’t applied. I have since now forced windows update to install Win11 24H2 and the drive remains encrypted. so this for a while will be a workaround for our staff laptops that need to be encrypted.