[SOLVED] PVE 8.3.0 - vmbr0 Works at OS Level but "Unknown Type" in Web UI & No /run/network/ifstate Created

[Raidek]

Hello Proxmox Community,

I'm encountering a persistent issue with my Proxmox VE 8.3.0 installation where my Linux bridge vmbr0 is not correctly recognized by the Proxmox VE web UI, despite being functional at the OS/kernel level. This problem has existed since the initial installation of the server.

System Details:

• Proxmox VE Version: pve-manager/8.3.0/c1689ccb1065a83b (running kernel: 6.8.12-4-pve)
• ifupdown2 Version: 3.2.0-1+pmx11 (confirmed via apt policy ifupdown2 and ifquery --version)

Main Problem:

The vmbr0 bridge appears as "Type: Unknown" in the Proxmox VE web UI (under Node -> System -> Network). Its IP address, gateway, and bridge ports are not displayed in the UI. Consequently, I cannot select vmbr0 when creating or editing network interfaces for VMs through the UI, and attempting to edit vmbr0 itself in the UI is not possible.

Key Finding:

The most critical issue we've identified is that the file /run/network/ifstate is never created, even though the networking.service (which manages ifupdown2) reports successful completion (active (exited) and status=0/SUCCESS). A global search for ifstate (find / -name ifstate) also yields no results.

Network Configuration (/etc/network/interfaces):

auto lo
iface lo inet loopback

# Interfaz PCIe (tajeta nueva)
auto enp129s0
iface enp129s0 inet manual

# Bridge para Vms
auto vmbr0
iface vmbr0 inet static
    address 192.168.4.15/24
    gateway 192.168.4.1
    bridge_ports enp129s0
    bridge_stp off
    bridge_fd 0

(Note: The bridge_ports syntax is correct for ifupdown2)

Relevant Command Outputs (Confirming OS Level Functionality):

• ip addr show vmbr0:

3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 88:c9:b3:b4:0d:e9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.15/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::8ac9:b3ff:feb4:de9/64 scope link
       valid_lft forever preferred_lft forever

(Shows vmbr0 is UP and has the correct IP)​

​

• brctl show vmbr0:

bridge name     bridge id               STP enabled     interfaces
vmbr0           8000.88c9b3b40de9       no              enp129s0
                                                        tap100i0

(Shows enp129s0 is correctly part of vmbr0. tap100i0 is a VM interface, proving the bridge is usable at kernel level if manually configured in VM .conf file)
​

• [B]systemctl status networking.service[/B]:
  
  Reports Active: active (exited) and status=0/SUCCESS after startup and after systemctl restart networking.service.
  
  Journal logs for the service show "Configuring network interfaces" and "Finished networking.service - Network initialization" without apparent errors.

• ifquery --list:

lo
enp129s0
vmbr0

(Shows ifupdown2 recognizes vmbr0 as a configured interface).​

• ls -l /run/network/ifstate:
  
  Always returns: ls: cannot access '/run/network/ifstate': No such file or directory

Summary of Troubleshooting Steps Attempted (without success in resolving the UI issue or ifstate creation):

• Verified and corrected /etc/network/interfaces syntax (ensured bridge_ports).
• Multiple restarts of networking.service, pvedaemon, pveproxy.
• Full server reboots.
• Reinstallation of ifupdown2 (apt install --reinstall ifupdown2) along with updates to libc packages. This did not resolve the issue where dpkg -S /usr/sbin/ifquery (which is a symlink chain to /usr/share/ifupdown2/__main__.py) failed to recognize the --dump flag (later clarified that --dump is not a standard flag for ifquery). The core issue of /run/network/ifstate not being created persisted.
• Tested with a minimal /etc/network/interfaces configuration (only lo, enp129s0, and vmbr0 with address and bridge_ports). The /run/network/ifstate file was still not created.
• Confirmed ifquery binary path and package ownership (/sbin/ifquery is part of ifupdown2 as per dpkg -L ifupdown2).
• Confirmed that the error ifquery: error: unrecognized arguments: --dump is expected behavior if the --dump flag is not supported by the version of ifquery in use.

The core problem seems to be that ifupdown2 (version 3.2.0-1+pmx11 on PVE 8.3.0) is not creating the /run/network/ifstate file, despite networking.service exiting cleanly and the kernel configuring the bridge correctly. This prevents Proxmox VE's management layer from correctly understanding and displaying the vmbr0 configuration.

As a workaround, I can manually edit VM config files to use bridge=vmbr0, and the VMs get network connectivity. However, managing the network via the UI is not possible for vmbr0.

Any insights or suggestions on how to further diagnose why /run/network/ifstate is not being created, or if this is a known issue with PVE 8.3.0 / ifupdown2 3.2.0-1+pmx11, would be greatly appreciated.

Thank you!

 

[shanreich]

We obtain the information about the type of interface by directly parsing /etc/network/interfaces - so the ifstate file shouldn't have anything to do with (and doesn't exist on any of my PVE hosts, for that matter). Usually the type bridge is assigned by checking the bridge_ports stanza in ifupdown, which seems to fail on your host for some reason.

Do you maybe have any errors in your journal? You can check via journalctl -b

 

[Raidek]

We obtain the information about the type of interface by directly parsing /etc/network/interfaces - so the ifstate file shouldn't have anything to do with (and doesn't exist on any of my PVE hosts, for that matter). Usually the type bridge is assigned by checking the bridge_ports stanza in ifupdown, which seems to fail on your host for some reason.

Do you maybe have any errors in your journal? You can check via journalctl -b

Hello @shanreich

Thank you for the very helpful clarification that Proxmox VE directly parses /etc/network/interfaces to determine the interface type, and that the /run/network/ifstate file is not the cause of vmbr0 being shown as "Type: Unknown" in the UI. This has helped refocus the troubleshooting.

The core issue remains that PVE's parser seems to be failing to correctly identify vmbr0 as a bridge, despite the presence of a bridge_ports line that the OS and ifupdown2 (at the kernel level) handle correctly.

Potentially Critical Historical Context:Following up on our internal discussions, a colleague reminded me of a very important detail that might be key here: Proxmox VE was initially installed when the current primary network card (enp129s0, a PCIe card) was NOT physically present in the server. At the time of PVE installation, only some fiber optic cards were installed (their configuration status or driver availability during the PVE install process is uncertain). The enp129s0 card was added later, and the network configuration, including vmbr0 using enp129s0, was set up manually in /etc/network/interfaces after this hardware change.

Could this post-installation addition of the primary NIC (enp129s0) and subsequent manual configuration of vmbr0 be why PVE's parser is struggling to recognize it, even if the /etc/network/interfaces file is now syntactically correct for ifupdown2?

Based on your feedback and further checks:

1. Output of cat -vet /etc/network/interfaces:

Here is the current state of the file, showing tabs (^I) and end-of-line ($) characters. The syntax appears correct, and bridge_ports is used.

root@proxmox:~# cat -vet /etc/network/interfaces
auto lo$
iface lo inet loopback$
$
# Interfaz PCIe (tajeta nueva)$
auto enp129s0$
$
iface enp129s0 inet manual$
$
# Bridge para Vms$
$
auto vmbr0$
iface vmbr0 inet static$
$
^Iaddress 192.168.4.15/24$
^Igateway 192.168.4.1$
^Ibridge_ports enp129s0$
^Ibridge_stp off$
^Ibridge_fd 0$

​

Is there anything that should change?​

2. Screenshot of the Proxmox VE Web UI (Node -> System -> Network):

This shows how enp129s0 and vmbr0 (still "Type: Unknown") are currently displayed:



3. Boot Journal (journalctl -b):

You asked for the output of journalctl -b. This log is quite long.
The full boot journal (journalctl -b) is attached.

Despite the OS level indicating vmbr0 is up and correctly configured with enp129s0 as a port (confirmed by ip addr, brctl show, and ifquery --list), the PVE management layer still fails to recognize it as a bridge. This issue has been present since the initial installation of PVE 8.3.0 and the subsequent addition of the enp129s0 NIC.

Given the new information about the NIC being added post-PVE installation, are there any known procedures to force PVE to fully re-evaluate or "re-learn" the network configuration based on the current /etc/network/interfaces? Or could this historical factor indeed be the reason for PVE's parser failing here?

Thank you again for your continued assistance and expertise.

 

[shanreich]

Seems like there are two newlines below the iface vmbr0 inet static stanza (There's two $ at least)? iow:

auto vmbr0
iface vmbr0 inet static

        address 192.0.2.0/24

instead of

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.0/24

Which probably trips up the parser

 

[Raidek]

Thanks

Seems like there are two newlines below the iface vmbr0 inet static stanza (There's two $ at least)? iow:

auto vmbr0
iface vmbr0 inet static

        address 192.0.2.0/24

instead of

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.0/24

Which probably trips up the parser

 

[rdfeij]

Just to add some information, just encountered the same. Solved by removing the extra empty line.
It seems to have started from last run update to version pve-manager/8.4.10.
The file was never knowlingly changed since a few years.
I do notice some files in /etc/network were changed during the update. Not sure if the interfaces file also did. I forgot to check the last change date before altering it myself.
Addition: interfaces file was not changed, i see it changed on all other hosts dec 27th 2024 during maintenance.
So the extra line probaply always has been there, and parser changed?