@george1421

YES, It’s works !!! Such a simple misteake, thx for patience and everything

I was looking for this file, it wasn’t there, I reinstalled FOG and magic happend ;]

Now I will be testing multicast !!! Keep your fingers crossed, i will let you know

@george1421

Thank you for your response. I don’t know why but I thought all the time that FOG should be installed on the server / router behind NAT. It didn’t occur to me that it could be a normal host on the network. I don’t need Fog working as a router and image server. Now I see that it makes no sense. So I’ll try to install it on a separate host computer and see what happens.

My switch is TP-LINK TL-SF1024. So it’s not an advanced device. But if I can run FOG on it, I’ll talk to my boss about something better.

Thanks to everyone for the answers, I will let you know if it works.

@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

@george1421

Information about the installed cards:

00:14.3 Network controller [0280]: Intel Corporation Alder Lake-S PCH CNVi WiFi [8086:7af0] (rev 11)
02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8161] (rev 15)
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15) - This is the built-in network card

You can see a total of 3 network cards, as I mentioned, one is an Intel WiFi card and the other two are Realtek cards, which appear to be identical."

grep -i -e firm /var/log/messages - this command did not return any information.

@george1421

I think I have found the problem - the network card. I installed another network card and it turned out to be practically the same card as the built-in one, and the restoration speed did not increase. I had another one that was recognized in the system as TP-link instead of Realtek, and after replacing it, the restoration speed suddenly reached 17.33GB/min. Can someone now explain to me what’s going on with this Realtek? The integrated card is a Realtek RTL8821CE. I also have an M.2 WiFi card with Bluetooth in a Dell Vostro PC, an Intel AX201, but it will likely be difficult to use it for booting and restoring computers. Any ideas?

Below are the differences between the mentioned network cards I installed in the Vostro.

@george1421

The result of the command I received:

bzImage: Linux kernel x86 boot executable bzImage, version 6.6.49 (runner@fv-az1756-740) #1 SMP PREEMPT_DYNAMIC Thu Sep 5 00:21:28 UTC 2024, RO-rootFS, swap_dev 0X9, Normal VGA

@george1421
In the place you indicated, I see different kernels, but I don’t know where the version of this kernel is.

@george1421
I checked restoring Windows 10 and it also restores slowly. But that already follows from what you wrote earlier, I changed various settings in BIOS (disabled C-state for the processor) and still nothing.

Write speeds on the disk are higher than my old SSDs on SATA, unless NVMe is somehow "messing up. Maybe I will install the system on a SATA SSD.
I’m considering connecting a new network card and testing the restoration on it.

I’m not sure what you meant by the FOS kernel, Fog is running on the latest version 1.5.10.1629 on Ubuntu 24.04.1, the system kernel is 6.8 so if that’s what you meant, then it’s probably the latest one."

As for Windows 10, I am restoring it only on Dell 7010 computers, tomorrow I planned to test this system on a new one. As for the FOG version, it’s the latest one, I will check FOS Linux tomorrow. I thought similarly that It’s neither FOG nor Proxmox., but I have no idea how to check the target computer.

Ethernet on Vostro is - Realtek RTL8111HSD - Could the network card have its transfer speed limited during image restoration? I will check the network card settings in BIOS tomorrow.

Good morning, I am using FOG on Proxmox. There are no problems with imaging and restoring Windows 10. The speed of restoring 16 computers with Windows 10 via multicast ranges between 10-13GB/min. A single computer is 14-15GB/min. The problem arises with Windows 11. The same FOG, the same settings, supposedly everything is the same, but the restoration is happening at a speed of 700MB/min - 1.4GB/min and takes far too long.

I restore Windows 10 on different hardware: Dell Optiplex 7010, these computers are to be replaced by Dell Vostro.

Image settings for Windows 11(the same as for Windows 10) :

1. Operating System: Windows 10,
2. Image Type: Multiple Partition Image - Single Disk (not Resizable),
3. Image Manager tested Partclone Gzip and Zstd. Zstd creates the image twice as fast but restores at the same speed.
   The computer I want to restore to is a Dell Vostro 3910 with an i12400 and a 256GB KIOXIA NVMe drive.

Windows 10

I don’t know where to start. is it more likely a hardware problem (Vostro 3910 - maybe BIOS settings, disk too slow for writing?), Proxmox (VM settings?) or FOG? No errors, the system works after restoration.

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.

Hi, I’m moving FOG to Proxmox. I currently have FOG installed on a physical computer on Ubuntu Server in Legacy mode, and I’m restoring systems in legacy mode. On the second computer I put Proxmox and there I created a VM with Ubuntu using the default SeaBIOS. Both FOG servers use dnsmasq with the same config (only different FOG server IP addresses). However, during registration and later restoring images from FOG on Proxmox, FOG uses booting after UEFI, not BIOS. Can someone explain to me why this is happening? Is it related to SeaBIOS? Or is it because Proxmox is based on UEFI?
I would like to be able to restore systems on Proxmox in both Legacy and UEFI mode, how to set legacy mode on VM in Proxmox?