Re: nm-online -s errors but nnonline doesn't (and networking is up)

On Fri, 2018-06-29 at 07:46 -0400, Brian J. Murrell wrote:
On Fri, 2018-06-29 at 11:25 +0200, Thomas Haller via networkmanager-
list wrote:

in this log, there is a message:

systemd-journald[621]: Suppressed 1100 messages from

Doh!  I was looking at the wrong system when I looked for suppression
messages, so of course, I didn't see that one.  My apologies.

also, there is

  (pc_bridge): add_pending_action (2): 'carrier-wait' already

which is the last (visible) message telling something about
actions on pc_bridge device.
Likely, that one is hanging.

you would also see in the output of

  nmcli device

that pc_bridge is in fact not fully activated (but pending

Yellow in nmcli device, which I suppose is pending activation.

A bridge cannot complete activation, until any slaves are attached.
Hence, it is expected that
startup-complete is never successfully reached (because activation
still pending for the bridge).

Ultimately it would probably be useful for the NetworkManager-wait-
online.service to report why it failed.  Not sure who is managing
unit.  Probably not you folks.

No, NetworkManager-wait-online is part of NetworkManager. But it's not
entirely clear *why* it's not ready, so helpful log is easier said than

If your `nmcli d` output has still activating devices, that is a good

So that damn bridge.  That damn bridge has never worked properly.  NM
cannot seem to wrap it's mind around enp2s0 being a bridge member and
not an interface of it's own.

I really do actually want enp2s0 in the bridge and not on it's own
since I like to be able to bridge VMs with it.  The last time NM got
confused about the bridge and enp2s0 I didn't have time to
it for the forty-eleventh time and just gave up on it until I had
to deal with it.  I guess it fell by the wayside.  :-(

Hopefully this is the last time I'll have to fiddle with this
A "Wired Interface" seems to have gotten added for the enp2s0
which I removed.

Much thanks for all of the help!


It should actually suffice that you have an type=ethernet profile for
enp2s0, with connection.master=pc_bridge.

In general, just ensure that you have the right profiles around, and
that they are marked to autoconnect. There is also
connection.autoconnect-priority setting (in case you have multiple
profiles set to autoconnect -- for ethernet that is much less useful
than for Wi-Fi). Anyway, by default, a profile that was used last, will
be preferred to autoconnect next time.

Or, alternatively, you can also set on the bridge
connection.autoconnect-slaves=yes, which will the master cause to
forcefully drag in all slave profiles (even if they themself are not
marked for autoconnect).


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]