From: Gabriel Goller <g.goller@proxmox.com>
To: Shay Sevet <shay@sevet.net>
Cc: pve-devel@lists.proxmox.com
Subject: Re: [RFC] ifupdown2: missing bond-primary device prevents the bond from being created
Date: Mon, 9 Nov 2026 11:01:42 +0100 [thread overview]
Message-ID: <avGZj__UWUy_M3BI@luna.proxmox.com> (raw)
In-Reply-To: <CAEjZgy5nvZM5gUz1kEo5ErE_+hBa3AOfuuyng0VVezsxsZ6rLQ@mail.gmail.com>
On 07.11.2026 11:52, Shay Sevet wrote:
> 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
Thanks, I recently submitted and backported:
https://github.com/CumulusNetworks/ifupdown2/pull/355
But it looks a little bit different from your PR (mine doesn't consider
bond-primary, only bond-slaves).
I'll have a look at your PR in the next weeks!
Thanks!
Gabriel
prev parent reply other threads:[~2026-11-09 10:01 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-07 19:52 [RFC] ifupdown2: missing bond-primary device prevents the bond from being created Shay Sevet
2026-11-09 10:01 ` Gabriel Goller [this message]
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=avGZj__UWUy_M3BI@luna.proxmox.com \
--to=g.goller@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=shay@sevet.net \
/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.