All issues have been resolved by the latest kernel . Best regards, this thread can now be closed. Solved.

@rodluz Updating the kernel to the latest version helped; the computers are finally being restored at full and consistent speeds, for both unicast and multicast deployments. Thank you for your help.

Re: Wake on LAN on Realtek cards

Hi, for some time, I’ve been struggling with the issue of restoration on Vostro 3910 computers with a Realtek card. I describe my experiences with this issue here

Now, I came across the thread Wake on LAN on Realtek cards and there is a broken link to a patch that fixes the Realtek Wake on LAN issue. The author also mentions that computers restored with the modified kernel restore faster. Does anyone still have that patch?

Hello again, I conducted additional tests. In debug mode on the client, I ran network tests between the client and the fog server using the iperf server. The results do not indicate any network issues:

iperf -c 192.168.25.11 
------------------------------------------------------------ 
Client connecting to 192.168.25.11, TCP port 5001 TCP 
window size: 16.0 KByte (default) 
------------------------------------------------------------ [ 1] 
local 192.168.25.49 port 35204 connected with 192.168.25.11 port 5001 
(icwnd/mss/irtt= 14/1448/924) 
[ ID] Interval Transfer Bandwidth [ 1] 0.00-10.02 sec 1.09 GBytes 938 Mbits/sec

I also conducted disk write tests, and they also do not indicate any issues with the disk:

bash
dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 status=progress
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.17635 s, 5.9 GB/s

I also created an uncompressed image, and it also restored slowly, with transfer speeds below 1GB/s, rather around 500-600 MB/s, which results in even lower speeds.

I changed the PXE environment boot file, set it to realtek.efi, and then changed it to snp.efi.The snp.efi visibly improved the FOS loading process, but the image restoration is still slow. Can the FOS system use a different driver during restoration than it does when operating in debug mode?

Hello again, after some time, I still haven’t been able to solve the problem. I started looking for different solutions, I installed the latest version of FOG, but so far nothing has helped. In the system logs in the file /var/log/messages, I found this line:

code_text
Feb 11 11:48:52 fogclient kern.noticekernel: r8169 0000:03:00.0 enp3s0: No native access to PCI extended config space, falling back to CSI

Since the driver cannot directly access the PCI and falls back to CSI, is this an issue with the driver itself, or could it be something else?

I have attached the entire log file in the post. Could someone take a look at this?

messages.txt

@rurap
OK, I tried it myself but failed. Somehow I couldn’t manage to attach the drivers to the system kernel, I don’t even know if I’m doing it right. I tried to follow this documentation:

https://docs.fogproject.org/en/latest/kb/reference/compile-fos-kernel/#arm-64-bit

I downloaded the drivers from here:

https://packages.ubuntu.com/noble/r8168-dkms.

I don’t know where to install these drivers, I don’t even know which files. I’m just groping in the dark and still don’t know how to do it, or if it’s even possible. Can anyone explain how to do it?

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

Hello everyone, I have Fog installed on Ubuntu 24.04.1 on a virtual machine on proxmox. I get this error on the client:

“https://192.168.25.11/fog/service/ipxe/boot.php… Error 0x420c6001 (https://ipxe.org/420c6001)
Could not boot: Error 0x420c6001 (https://ipxe.org/420c6001)”

what could this mean?

edit:
It looks like I messed something up during the installation. I suspect it’s the DNS. I didn’t notice, but it detected the DNS as localhost by default. When I changed it, FOG started on the client.

@george1421

thank you george, the current switch is unmanaged, it’s a simple switch. There is not much in the specification of the switch, so I bet that switch is the problem.
All PCs are the same and support WOL and on the old switch they all turn on, but I will check it, maybe one of the students has changed something in the BIOS

@george1421

Multicast is working, but …

First I used my old switch TP-LINK TL-SF1024 and it’s faild. Two PCs restored at a rate of 150MB/min,

Second time I used LinkSys LGS308, 8 x 1Gb ports. I start to restore 2 other PC and only one turn on from network, second i turn on by my self but the multicast session starting, and both PC restore at rate of 10GB/mmin. Then I connect third PC to the switch and strat multisession once again one PC turn on but second and third i have to turn on. Again multicast worked very well (10GB/min at each PC)

Do you have an idea why only one PC wake on LAN?
Whether the old switch may not support multicast?

@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