Proxmox VE Host Has No Network After an 8-to-9 Upgrade

Confirm independent console access before anything else

Confirm a physical console or an independent out-of-band recovery console that does not depend on the broken management network. Without it, stop before any configuration change: every later step on this page assumes recovery access exists, and remote-only repair over the failed path risks total lockout.[2]

Capture current links, addresses, routes, and bridge state

From the console, capture the current host links, addresses, routes, and bridge ports with display-only commands. Presence of a route never proves traffic passes, and a bridge showing UP never proves the gateway is reachable; record observations without drawing conclusions yet.[6][7]

ip link show

ip addr show

ip route show

bridge link show

bridge vlan show

Do not edit, reload, or reinstall networking before classification

Do not edit bridge or address configuration, apply or reload networking, reinstall packages, flush firewall rules, or change VLAN assignments before the observed state is classified against the pre-upgrade design. A change made before classification can convert a rename into an outage.[3][2]

1. Compare enumerated NICs against hardware identity and prior inventory

When the configured physical member name is absent, compare the currently enumerated interfaces against hardware identity and the recorded pre-upgrade inventory. A confirmed mapping mismatch is a rename branch; no enumerated matching NIC is a device or driver investigation instead. Never substitute the first interface with a similar name, and treat renaming as possible across kernel and systemd updates, never inevitable.[2][3][6]

2. Compare active bridge membership and parsed configuration separately

With the NIC present, compare active bridge membership and the parsed configuration as two separate observations. A missing membership or a parser error identifies a configuration discrepancy, not necessarily the whole outage. The experimental check comparison cannot validate user hooks, and a successful parse never proves a safe apply.[3][4][7]

ifquery -a

ifquery --running -a

ifquery --check -a

3. Compare address, gateway, and VLAN against the known pre-upgrade design

With the bridge present, compare the address and prefix, the management VLAN, and the route and gateway against the documented pre-upgrade design and report the exact discrepancy. A VLAN mismatch additionally needs matching switch-side evidence; never prescribe an arbitrary VLAN ID. If host management works and only a guest fails, exit to the guest diagnosis.[3][6]

4. If configuration parses, inspect service startup and package state

When configuration parses but the networking service fails or hangs, inspect service and boot logs plus custom hooks before any repair. The old Ceph full-mesh FRR restart hook is a documented upgrade-specific trap that applies only when that exact setup is present; otherwise keep hooks out of the simple bridge path. Separately, verify package, repository, and upgrade-checker state against the official upgrade guide; never reinstall networking blindly over the only management connection.[2][8]

ifreload -a --syntax-check

pve8to9 --full

Before any network mutation: confirm console and saved recovery

Planning boundary only. Every bridge, address, gateway, or VLAN edit, every live reload, service restart, interface pinning, reboot, or package replacement on this page requires a physical or independent console, a saved copy of the working configuration, and an operator able to restore it from that console. Without recovery access, stop before modification; read-only inspection is the only permitted activity.[2]

Confirmed rename: correct the interface identity to inventory

Where hardware identity and prior inventory confirm the same physical NIC under a new name, correct the configuration to the confirmed identity from the console with the saved configuration at hand. Never substitute the first interface with a similar name on suspicion alone.[2][3]

Membership or parser discrepancy: reconcile configuration to the proven state

Where bridge membership or parser evidence proves a configuration discrepancy, reconcile the staged configuration to the proven active design from the console. Parser success alone never authorizes application: user hooks and unvalidated attributes stay out of the change until separately verified.[3][4][5]

Address, gateway, or VLAN mismatch: restore the documented design exactly

Where the discrepancy against the known pre-upgrade design is exact, restore precisely that address, gateway, or VLAN value from the console. VLAN corrections additionally require the matching switch-side evidence already collected; arbitrary VLAN IDs are never prescribed.[3]

Service or hook failure: inspect logs and hand off scoped recovery

Where the service fails or hangs, inspect service and boot logs plus custom hooks and hand the scoped recovery to the operator: the old Ceph full-mesh FRR restart hook path only when that exact setup is confirmed present, with its documented recovery, and never as part of the simple bridge repair. No hook deletion or blind service surgery happens on this page.[2][8]

Inconsistent upgrade state: follow the official upgrade guide

Record the inconsistent package, repository, or upgrade-checker state and hand it to the operator with the official upgrade guide as the recovery reference. Do not instruct package changes in this read-only solution; actual package and repository mutations remain outside this diagnosis and are potentially disruptive. Do not reinstall networking blindly and never run package repair over the only management connection.[2]

If no branch is proven: preserve the evidence

Record the enumerated links, addresses, routes, bridge state, staged and parsed configuration, service and hook logs, package and upgrade-checker state, and the known pre-upgrade design. Send the sanitized evidence to the operator; matching state everywhere never permits flushing firewall rules or guessing a fix.[2][3]