• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. rurap
    3. Posts
    R
    • Profile
    • Following 0
    • Followers 0
    • Topics 4
    • Posts 27
    • Best 2
    • Controversial 0
    • Groups 0

    Posts made by rurap

    • RE: Slow restoration of Windows 11 with FOG on Proxmox

      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?

      posted in FOG Problems
      R
      rurap
    • RE: Slow restoration of Windows 11 with FOG on Proxmox

      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

      posted in FOG Problems
      R
      rurap
    • RE: Slow restoration of Windows 11 with FOG on Proxmox

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

      posted in FOG Problems
      R
      rurap
    • RE: Slow restoration of Windows 11 with FOG on Proxmox

      @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

      posted in FOG Problems
      R
      rurap
    • RE: Slow restoration of Windows 11 with FOG on Proxmox

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

      posted in FOG Problems
      R
      rurap
    • RE: Slow restoration of Windows 11 with FOG on Proxmox

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

      20241216_101036.jpg

      posted in FOG Problems
      R
      rurap
    • RE: Slow restoration of Windows 11 with FOG on Proxmox

      @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

      posted in FOG Problems
      R
      rurap
    • RE: Slow restoration of Windows 11 with FOG on Proxmox

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

      35d94e55-d51e-4266-bdb2-166717c3fc47-image.png

      posted in FOG Problems
      R
      rurap
    • RE: Slow restoration of Windows 11 with FOG on Proxmox

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

      posted in FOG Problems
      R
      rurap
    • RE: Slow restoration of Windows 11 with FOG on Proxmox

      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.

      posted in FOG Problems
      R
      rurap
    • Slow restoration of Windows 11 with FOG on Proxmox

      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.

      posted in FOG Problems
      R
      rurap
    • RE: FOG on Proxmox use UEFI booting.

      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.

      posted in FOG Problems
      R
      rurap
    • FOG on Proxmox use UEFI booting.

      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?

      posted in FOG Problems
      R
      rurap
    • Fog client: iPXe error code 420c6001, Broken Pipe

      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.

      posted in FOG Problems
      R
      rurap
    • RE: Can not deploy using multicast - read image_hdr block_size error

      @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

      posted in FOG Problems
      R
      rurap
    • RE: Can not deploy using multicast - read image_hdr block_size error

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

      posted in FOG Problems
      R
      rurap
    • RE: Can not deploy using multicast - read image_hdr block_size error

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

      posted in FOG Problems
      R
      rurap
    • RE: Can not deploy using multicast - read image_hdr block_size error

      @george1421

      There is no / tftpboot directory.

      I install everything again, I have no idea what happened to this catalog. I could have sworn that this catalog was yesterday.

      posted in FOG Problems
      R
      rurap
    • RE: Can not deploy using multicast - read image_hdr block_size error

      @george1421
      your suggestion did not work. I looked for TFTP troubleshoting like @Sebastian-Roth says and used the command:

      tftp -v x.x.x.x -m binary -c get undionly.kpxe
      

      and i have got nothing.
      I searched the system a bit and found something like this:
      this is my tftp-hpa configuration file

      # /etc/default/tftpd-hpa
      
      TFTP_USERNAME="tftp"
      TFTP_DIRECTORY="/var/lib/tftpboot"
      TFTP_ADDRESS=":69"
      TFTP_OPTIONS="--secure"
      
      

      there are no files in this directory, so where is the undionly.kpxe?

      posted in FOG Problems
      R
      rurap
    • RE: Can not deploy using multicast - read image_hdr block_size error

      @george1421

      This is from Ubuntu server 18.1 and dnsmasq 2.9 verssion:

      # Don't function as a DNS server:
      port=0
      
      # Log lots of extra information about DHCP transactions.
      log-dhcp
      
      # Set the root directory for files available via FTP.
      tftp-root=/tftpboot
      
      # The boot filename, Server name, Server Ip Address
      dhcp-boot=undionly.kpxe,,192.168.25.117
      
      # Disable re-use of the DHCP servername and filename fields as extra
      # option space. That's to avoid confusing some old or broken DHCP clients.
      dhcp-no-override
      
      # inspect the vendor class string and match the text to set the tag
      dhcp-vendorclass=BIOS,PXEClient:Arch:00000
      dhcp-vendorclass=UEFI32,PXEClient:Arch:00006
      dhcp-vendorclass=UEFI,PXEClient:Arch:00007
      dhcp-vendorclass=UEFI64,PXEClient:Arch:00009
      
      # Set the boot file name based on the matching tag from the vendor class (above)
      dhcp-boot=net:UEFI32,i386-efi/ipxe.efi,,192.168.25.117
      dhcp-boot=net:UEFI,ipxe.efi,,192.168.25.117
      dhcp-boot=net:UEFI64,ipxe.efi,,192.168.25.117
      
      # PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
      pxe-prompt="Booting FOG Client", 1
      
      # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
      # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
      # This option is first and will be the default if there is no input from the user.
      pxe-service=X86PC, "Boot to FOG", undionly.kpxe
      pxe-service=X86-64_EFI, "Boot to FOG UEFI", ipxe.efi
      pxe-service=BC_EFI, "Boot to FOG UEFI PXE-BC", ipxe.efi
      
      dhcp-range=192.168.25.117,proxy
      

      And this one is from Ubuntu 16.04, dnsmasq 2.5 :

      # Don't function as a DNS server:
      port=0
      
      # Log lots of extra information about DHCP transactions.
      log-dhcp
      
      # Dnsmasq can also function as a TFTP server. You may uninstall
      # tftpd-hpa if you like, and uncomment the next line:
      # enable-tftp
      
      # Set the root directory for files available via FTP.
      tftp-root=/tftpboot
      
      # The boot filename, Server name, Server Ip Address
      dhcp-boot=undionly.kpxe,,192.168.25.137
      
      # rootpath option, for NFS
      #dhcp-option=17,/images
      
      # kill multicast
      #dhcp-option=vendor:PXEClient,6,2b
      
      # Disable re-use of the DHCP servername and filename fields as extra
      # option space. That's to avoid confusing some old or broken DHCP clients.
      dhcp-no-override
      
      # PXE menu.  The first part is the text displayed to the user.  The second is the timeout, in seconds.
      pxe-prompt="Press F8 for boot menu", 3
      
      # The known types are x86PC, PC98, IA64_EFI, Alpha, Arc_x86,
      # Intel_Lean_Client, IA32_EFI, BC_EFI, Xscale_EFI and X86-64_EFI
      # This option is first and will be the default if there is no input from the user.
      pxe-service=X86PC, "Boot from network", undionly
      
      # A boot service type of 0 is special, and will abort the
      # net boot procedure and continue booting from local media.
      #pxe-service=X86PC, "Boot from local hard disk", 0
      
      # If an integer boot service type, rather than a basename is given, then the
      # PXE client will search for a suitable boot service for that type on the
      # network. This search may be done by multicast or broadcast, or direct to a
      # server if its IP address is provided.
      # pxe-service=x86PC, "Install windows from RIS server", 1
      
      # This range(s) is for the public interface, where dnsmasq functions
      # as a proxy DHCP server providing boot information but no IP leases.
      # Any ip in the subnet will do, so you may just put your server NIC ip here.
      # Since dnsmasq is not providing true DHCP services, you do not want it
      # handing out IP addresses.  Just put your servers IP address for the interface
      # that is connected to the network on which the FOG clients exist.
      # If this setting is incorrect, the dnsmasq may not start, rendering
      # your proxyDHCP ineffective.
      dhcp-range=192.168.25.137,proxy
      
      # This range(s) is for the private network on 2-NIC servers,
      # where dnsmasq functions as a normal DHCP server, providing IP leases.
      # dhcp-range=192.168.0.20,192.168.0.250,8h
      
      # For static client IPs, and only for the private subnets,
      # you may put entries like this:
      # dhcp-host=00:20:e0:3b:13:af,10.160.31.111,client111,infinite```
      posted in FOG Problems
      R
      rurap
    • 1 / 1