FOG working with virtual interface

  • Hello guys,

    I try do download and activate a new kernel. The web interface is saying “Your new FOG Kernel has been installed!” but in the apache error log I get:

    [Tue May 12 20:25:35.105748 2020] [proxy_fcgi:error] [pid 22243] [client] AH01071: Got error 'PHP message: PHP Warning:  ftp_mkdir(): Create directory operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 493\nPHP message: PHP Warning:  ftp_rename(): Rename failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 808\n', referer:

    Maybe the issue is because I try to use FOG with an virtual interface: FOG is running with eth0:1 with IP and the normal IP address is

    The second issue is, that often fog is not providing an ip address if I want to image or register the client

    I get something like:

    Starting syslogd: OK
    Starting klogd: OK
    Running sysctl: OK
    Populating /dev using udev: done
    Saving random seed: OK
    Staring haveged: haveged: listening socket at 3
    Starting enp1s0 interface and waiting for the link to come up
    No link detected on enp1s0 for 35 seconds,skipping it.
    Failed to get an IP via DHCP! Tried on interfaces(s): enp1s0
    Please check your network setup and try again!
    Press enter to continue
  • Moderator

    @Oleg said:

    I don’t know if it has to do something with the timeout issue but in /etc/default/grub I added

    We don’t use GRUB for PXE booting hosts usually! Seems like you have customized your setup a fair bit. I may ask you to tell us more about the customization to we are able to properly help you!

    I changed manually the kernels in /var/www/html/fog/service/ipxe/ to the 4.15.2 Kernel.
    With the older kernel the issue with the timeout is gone.

    That’s interesting. So it seems like a Linux kernel network driver issue from what we know so far. Let’s start by trying to find out what driver is used. Please boot Windows on that machine, open device management and get us the device ID from there. Usually in the form 12c4:5f78.

  • I don’t know if it has to do something with the timeout issue but in /etc/default/grub I added

    GRUB_CMDLINE_LINUX="net.ifnames=0 biosdevname=0"

    because we want to use eth0 name instead of enp1s0.

    I changed manually the kernels in /var/www/html/fog/service/ipxe/ to the 4.15.2 Kernel.

    Now I get eth0 instead of enp1s0:

    Starting syslogd: OK
    Starting klogd: OK
    Running sysctl: OK
    Populating /dev using udev: done
    Saving random seed: OK
    Staring haveged: haveged: listening socket at 3
    Starting eth0 interface and waiting for the link to come u

    With the older kernel the issue with the timeout is gone.

  • @Sebastian-Roth
    I went through the wiki article and everything seems to be fine.

    I saw that fog is downloading the kernels twice if you do an update. First time if you expand the kernel you want to download and click on “download”. (Kernel will be downloaded as “bzImage”) The second time after you enter the kernel name and click on “install” - this time the kernel will be downloaded with the new name.

  • Moderator

    @Oleg For the kernel update issue you wanna go through this wiki article:

  • @Sebastian-Roth
    any ideas regarding the issue with the kernel update?
    I disabled the virtual interface and run the 1.5.8 installer again and tried the kernel update - still get the error with ftp_rename() I mentioned in my first post.

    My system: ubuntu server 18.4.4

  • @george1421
    I disabled the virtuel interface and changed all settings to the ip address of the fog server.
    It seems to work a little better but still the clients are often running into timeouts after the fog menu.
    FOG and the client are both connected with the tp-link switch and nothing else

  • Moderator

    @Oleg said in FOG working with virtual interface:

    client waited at least 15 seconds until it got the dhcp address from fog

    See the issue is that if it IS spanning tree, standard spanning tree doesn’t start forwarding data until the 27 second timer counts down. So that means the switch will not forward data for 27 seconds. By then the FOS Linux engine has already given up. Typically once of those cheap unmanaged switches don’t support spanning tree so they keep the building switch port active as PXE hands off to IPXE and then iPXE hand off to FOS Linux.

  • @Sebastian-Roth
    i noticed, that the installation process (or ./ is generating a strange netmask in the dhcpd.conf, if a virtuel interface is configured:
    network settings of system:

    auto eth0
    iface eth0 inet static

    virtuel interface:

    auto eth0:0
    iface eth0:0 inet static

    generated DHCP settings:

    subnet netmask{
        option subnet-mask;
        range dynamic-bootp;
        default-lease-time 21600;
        max-lease-time 43200;
        option routers;
        option domain-name-servers;

    if I disable the virtuel interface before running, everything is ok then.

    I manually change all network settings to the 192.100.1.x after the script is finished.

  • @george1421
    I tried to do a quick registration 10 times with my unmanaged tp-link switch and in 6 of 19 cases the client pc didn’t get an ip address and ran into the timeout.
    In that cases, where the client got an ip address, the client waited at least 15 seconds until it got the dhcp address from fog.

  • Moderator

    @Oleg Do you have a cheap unmanaged network switch you can place between the target computer and the building switch. About 90% of the time where we see this condition is because your building switch is using spanning tree but not one of the fast spanning tree protocols like port-fast, RSTP, MSTP, fast-STP (or what ever your switch vendor calls it), and not the FOG server itself. A (dumb) unmanaged switch will typically mask the problem and as a test gives us an understanding of the problem.

    There is another way if you don’t have an unmanged switch to test, but just placing an unmanged switch between the target computer and the networks is the quickest test.

  • @Sebastian-Roth

    TFTP HOST is set to

    Booting and getting into the FOG menu is working everytime.
    In most cases after choosing fog registration, quick image or fog sysinfo, fog is running into the timeout mentioned before - but sometimes it works and the client is getting an ip address and doing the registration or fog is deploying the image. I would say, every 4th time it seems to work.

    I tried fog 1.5.8 and 1.5.9-RC1. Both versions have problems with providing DHCP addresses after the fog menu items.

    I thought maybe it has something to do with the kernel, so tried to change the used kernel and ran into the update problem with the kernel.

  • Moderator

    @Oleg The permissions in the kernel directory look alright to me. From “www-data” group name we see this is Ubuntu or Debian install and so I don’t expect SELinux to get in the way here.

    So I would imagine the fogproject account to not be “in sync” (see George’s great forum post). But on the other hand we should see a “Login incorrect” error message in that case!

    The other thing could be the virtual interface. Did you capture an image lately and did that work properly?

    Please check in FOG Configuration -> FOG Settings -> TFTP Server. What is TFTP HOST set to?

  • Here the output:

    drwxr-xr-x 2 fogproject www-data     4096 May 12 20:23 .
    drwxr-xr-x 3 www-data   www-data     4096 May 12 19:56 ..
    -rw-r--r-- 1 fogproject www-data     1966 May 12 19:56 advanced.php
    -rw-r--r-- 1 fogproject www-data    16272 May 12 19:56 bgdark.png
    -rw-r--r-- 1 fogproject www-data    21280 May 12 19:56 bg.png
    -rw-r--r-- 1 fogproject www-data     1139 May 12 19:56 boot.php
    -rw-r--r-- 1 fogproject www-data  8438432 May 12 19:57 bzImage
    -rw-r--r-- 1 fogproject www-data  7836480 May 12 19:57 bzImage32
    -rw-r--r-- 1 fogproject www-data   234697 May 12 19:56 grub.exe
    -rw-r--r-- 1 fogproject www-data      592 May 12 19:56 index.php
    -rw-r--r-- 1 fogproject www-data 20315484 May 12 19:57 init_32.xz
    -rw-r--r-- 1 fogproject www-data 20891504 May 12 19:57 init.xz
    -rw-r--r-- 1 fogproject www-data    25340 May 12 19:56 memdisk
    -rw-r--r-- 1 fogproject www-data  1839104 May 12 19:56 memtest.bin
    -rw-r--r-- 1 fogproject www-data   202624 May 12 19:56 refind_aa64.efi
    -rw-r--r-- 1 fogproject www-data    29719 May 12 19:56 refind.conf
    -rw-r--r-- 1 fogproject www-data   262592 May 12 19:56 refind.efi
    -rw-r--r-- 1 fogproject www-data   201600 May 12 19:56 refind_ia32.efi
    -rw-r--r-- 1 fogproject www-data   208776 May 12 19:56 refind_x64.efi

    In many different subnets we don’t have a dhcp server and dont have free Ip addresses in that small subnets. So we decided to use in every subnet the same fog-configuration. The problem is, that we normally don’t have so many IP addresses available in the subnet, where the fog is acting.
    With the virutal interface FOG is providing as many IP addresses to the clients as we want and the fog server is set as the router address.
    The IP addresses are only for temporary cases until they get the right ip address.

    If there is another possibility to let fog use another network for providing images, let me know. I didn’t find anything.

  • Moderator

    @Oleg May I ask you to open another topic for the second issue as it’s way better to keep things sorted and not mix it up.

    For the first issue, please run ls -al /var/www/html/fog/service/ipxe/ and post output here. Not sure if the virtual interface is playing a role here but I really wonder why you set it up like this. Can you please tell us more about why you have two IPs from obviously different subnets bound to your FOG server?