Thanks for your investigation.
Not sure, if bridge-utils are really need, but I use them because its an easier way then "ip-link".
I usually use 'ifquery' ether with '--list' or '--state' but it does not show my second bridge, even
though 'ip link' shows it.
I know the problem with the member ports and on my current workstation the solution was to
give it a dummy address ("0.0.0.0"). The bridges are for containers and LXC, so there is no
definitiv port at computer start - which was never a problem to me.
But there is "/etc/network/if-pre-up.d/bridge -> /lib/bridge-utils/ifupdown.sh*"
which should solve the problem (that ip link is not persistent) and read "interfaces".
I have two comparable computers (hardware and VM), both Devuan5. If I look into /var/log/boot:

Starting: AppArmorLoading AppArmor profiles...done.
Configuring network interfaces...if-up.d/mountnfs[eth0]: waiting for interface eth1 before doing NFS mounts ... (warning).
invoke-rc.d: could not determine current runlevel
if-up.d/mountnfs[eth1]: waiting for interface lanbr before doing NFS mounts ... (warning).
invoke-rc.d: could not determine current runlevel

Note: waiting for interface lanbr ....
I am even not capable to write everthing, I saw. But a internet search for

Exactly this is part of my experience, were the bridge and even sometime
a hardware inferace shows this strange status!
This earch gives tons of similar messages, a hint of apparmor bug, of Kernel 6.1 bug and more.
You remove a VF from a dual-nic and suddenly, the other(!) port does not get carrier! I changed the NIC with the exact same from another computer (shown in the log-excerpt above) with not changes and the other box does not have that problem.
The whole story started with unexpected behavior of a kvm-guest, which had no traffic. But then I made the same, step-by-step on this host itself (create bridge, create macvlan) and everythings works - repeated this using LXC, works.
I made a port mirror on the hardware-switch - no packages came out, if the VM runs ..... but you see the packets on the host.
Something drops them. Due to the probability, this could be some of the "same subnet" things, I used a complete different, 10.10.10. ... (have enough free port on other computers). No change.
Now I removed systemtap, xtables-common, libvirt*, qemu*, xrdp, x2go, xfce4. Upgraded to kernel 6.5 - no changes.
There is no wait-message for the bridge and the assigned interface does not become member (can be done manually, after login). Even "/etc/network/interfaces.d/" is not read (was successful with: "/etc/network/if-pre-up.d/lanbr"
(my script with name of the bridge - but the membership problem remains). So the bridge can be created, but get no member ports.
Time to reinstall and hope.
I remember, what was the first fault on this box:
On shutdown, after the first boot (zfs on root), installed the usual way using chroot (like one of the other
boxes from the logs above, were the same things works), I got:
~ "cannot unmount /var/log" .....

Thanks anyway and
best regards,
Manfred

Bridges are of course available as kernel networking elements regardless of that package, and the ip command operates on the kernel elements.

Generally speaking, the ifup and ifdown commands are tunable and extensible by means of scripts/programs in the /etc/network/if-* directories which all get invoked when interfaces are brought up or down by those commands. See man interfaces for more.

The ip command only operates on the kernel's networking setup and it does not make use of ifupdown. It's rather the opposite, that ifupdown scripts (and built-in functions) make use of ip to effectuate declared configurations.

        #bridge_stp off
        #bridge_waitport 0
        #bridge_fd 0

        bride_ports eif0

But the bridge does not come up after boot and bootlog tells me:

Cannot find device "lanbr"
Sat Jul  6 23:20:03 2024: ifup: failed to bring up lanbr
Sat Jul  6 23:20:03 2024: invoke-rc.d: could not determine current runlevel

Looks like, someone forgot the 'lanbr' interface.
This is something I never had seen before.
What is a - reproducable - list of steps to setup a bridge?
I try to avoid - for this message - that KVM has the same
problem and does not find (the other bridge).
Something strange!
Please help!

Regards,
Manfred