From: Shay Sevet <shay@sevet.net>
To: pve-devel@lists.proxmox.com
Subject: [RFC] ifupdown2: missing bond-primary device prevents the bond from being created
Date: Sat, 7 Nov 2026 11:52:50 -0800 [thread overview]
Message-ID: <CAEjZgy5nvZM5gUz1kEo5ErE_+hBa3AOfuuyng0VVezsxsZ6rLQ@mail.gmail.com> (raw)
Hi,
I hit this on a 3-node PVE 9.2 cluster and want to report it together with
a proposed fix.
Problem
-------
If an active-backup bond's `bond-primary` names a device that does not
exist at boot (for example a USB NIC that died, was unplugged, or was
replaced and came back under a new MAC-based name), ifupdown2 never creates
the bond at all. Every interface stacked on it fails too (vlan-aware
bridge, VLANs, addresses), so the node loses all networking, although the
other bond slave is present and has link. Same result on `ifreload -a`.
error: ifname <nic> not present in cache
error: vmbrX: bridge port bond0 does not exist
This defeats the redundancy the bond was configured for: losing the
preferred device takes the whole bond down instead of failing over.
Reproduced on ifupdown2 3.3.0-1+pmx12 and 3.3.0-1+pmx13 (Debian 13 VM and
on PVE 9.2.26 hosts). The related missing-slave case is already handled in
pmx13 (Proxmox bug 8117 / upstream PR #355); the missing primary is not.
Cause
-----
`bond-primary` is resolved with `self.cache.get_ifindex()` in
`ifupdown2/addons/bond.py` (`get_ifla_bond_attr_from_user_config()`). For
an unknown name it raises `NetlinkCacheIfnameNotFoundError`; only
`KeyError` is caught there, so the exception aborts the bond setup before
the link is created.
Proposed fix
------------
Treat a missing bond-primary device like an invalid value: log a warning,
set the interface status to warning, and create the bond without a primary.
The configuration is left untouched; a later ifreload sets the primary once
the device exists.
Upstream PR (with a unit test that fails without the change and passes with
it):
https://www.google.com/url?q=https://github.com/CumulusNetworks/ifupdown2/pull/358&source=gmail&ust=1794167497172000&sa=E
I have been running a rebuilt 3.3.0-1+pmx13 with this change on all three
nodes. A rebased quilt patch for the Proxmox packaging is available if
useful.
Workaround until then: drop `bond-primary` and set it after the bond is up,
only if the device exists:
post-up echo <nic> > /sys/class/net/bond0/bonding/primary 2>/dev/null ||
true
I found the bug on my own setup; the fix was developed with AI assistance
(Claude) and reviewed and tested by me.
Thanks,
Shay Sevet
next reply other threads:[~2026-11-09 8:29 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 19:52 Shay Sevet [this message]
2026-11-09 10:01 ` [RFC] ifupdown2: missing bond-primary device prevents the bond from being created Gabriel Goller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAEjZgy5nvZM5gUz1kEo5ErE_+hBa3AOfuuyng0VVezsxsZ6rLQ@mail.gmail.com \
--to=shay@sevet.net \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.