Debian User Forums

Final fix was to: Jeez!

Looking at the logs, it seems that systemd and polkit are bashing it out, trying to restart the bridge and slave multiple times.
$ sudo sudo journalctl -ab -u NetworkManager
$ sudo sudo journalctl -ab -g 'eno1|Slave\ 1|Bridge\ 1|br1'

Here is my temporary work-around (it's the best I can do) and I'm pretty sure it's a bug.

$ vim /etc/systemd/system/fix-bug-slave-link-local.service [Unit]
Description=Remove rogue link-local from slaves!
Requires=NetworkManager.service
After=NetworkManager ...

Why does NetworkManager add a link-local IP address 169.254.105.42/16 to the slave interface when reboot after I create a bridge?
What is it used for? It ruins my internet connection and manually correcting the routing table does not fix it, but restarting the bridge does.
If I traceroute 8.8.8.8 then it tries to use the link-local address to reach the default gateway. Yikes!

$ sudo nmcli connection add type bridge con-name 'Bridge 1' ifname br1
$ sudo nmcli connection add type ethernet con ...

Ok and your are logging in from console and not from SSH?
The problem occurs after SU or SSH or Any time that commands are run withing a user environment which has not GUI session.

dbus appears to be activated here: /etc/X11/Xsession.d/20dbus_xdg-runtime
Yeah, this is where it disappears into the weeds.

I worry that systemd might require a user@1001.service instance to exist.
If so then the question changes to: What is the workaround?
If not then man dbus-update-activation-environment ...

The end goal is to have the session D-Bus running in the same way as it does when I'm logged into Gnome, so that I can use the same scripts and commands, for instance when accessing the secrets API via session bus, pkexec, etc etc. The second goal (I did not know this was going to become a goal) is to understand what hoops I have to jump through to enable socket activation for a service. It seems that socket activation only works after a GUI login, which is REALLY weird seeing that D-Bus is not ...

Sure ...I'm wanting to start my D-Bus socket activation unit /usr/lib/systemd/user/dbus.socket on my socket address, which I exported as XDG_RUNTIME_DIR="/run/user/$(id -u $USER)" in my console session (which has no parent user@1001.service ). Objective is to be able to use my session D-Bus normally, like I would be able to had I logged into Gnome. D-Bus is refusing to start the socket, does not spit out LISTEN_FDS, and therefore fails to invoke /usr/lib/systemd/user/dbus.service when the socket ...

Trying to start a plain vanilla session D-Bus with ordinary D-Bus Socket Activation at the usual unix:path=/run/user/1001/bus without a parent systemd --user process such as user@1001.service but it is fighting me every step of the way:

# Set up the socket location:
$ XDG_RUNTIME_DIR="/run/user/$(id -u $USER)"
$ echo $XDG_RUNTIME_DIR
/run/user/1001
$ export XDG_RUNTIME_DIR

#Start the Systemd dbus.socket unit which will now create the listening socket:
$ systemctl --user start dbus.socket ...

I have eliminated apparmor and polkit from the list of possible suspects, by masking both unit-files and confirming that the problem still persists.
I have also confirmed that the problem remains mitigated even by delaying only to basic.target .
I also ran auditd against the folder attributes and no culprits showed up, at least from the point where auditd starts.

This makes me think it is a BTRFS bug, ...still trying to get to the bottom of it.
I gave up because my workaround (prior post) works ...

This is weird work-around : If I delay mounting of the /srv subvolume until after multi-user.target via the fstab entry below, then permissions are NOT lost and everything works as expected. Could this have something to do with polkit or apparmor ? Might one of these have the audacity to mess with my personally tailored permissions?

Here is the ferocious fstab entry that "works around" my problem:

UUID=5e1b0391-a9b1-49df-a840-5b791e539ad1 /srv btrfs nofail, x-systemd.requires=multi-user ...

My root filesystem is BTRFS, and I've mounted a BTRFS subvolume at /srv.
I can change permissions on the mounted subvolume to 2770 but they revert after every reboot.
I have NO HAIR LEFT so please help if you know the secret.

My /etc/fstab on Debian Trixie:

UUID=5e1b0391-a9b1-49df-a840-5b791e539ad1 / btrfs subvol=@ 0 0
UUID=5e1b0391-a9b1-49df-a840-5b791e539ad1 /home btrfs subvol=@home 0 0
UUID=5e1b0391-a9b1-49df-a840-5b791e539ad1 /srv btrfs subvol=@srv 0 0
UUID=5e1b0391-a9b1-49df-a840 ...

I'm actually very hopeful that I'll be able to stay in Bookworm when it goes to Stable in two years from now because Wayland and nftables should both be fully entrenched by then. I'm really looking forward to that; it's been a very long time coming.

And so I replaced bullseye with bookworm in /etc/apt/sources.list and then I ran:
sudo apt update --allow-releaseinfo-change && apt full-upgrade
And now I still have a working system. I suppose that's all there is to it.

I just found this post which might help anyone who wants to do this NOW and live dangerously:
https://tiny.tilde.website/@pho4cexa/106764026015059759
You still have to update your sources.list to specify "testing"

Ah right, sources.list thanks.
Looking at mine, it did indeed install Debian 11 even though I downloaded the Testing ISO, so ouch!
If I replace bullseye (below) with bookworm then I'm sure it will break everything!
... and so I'll wait until the release team fixes it.
Debian 12 will be the best Debian ever, with Gnome 4 and fully working Wayland+Pipewire plus not having to compile application packages.
I'm really looking forward to it!

deb http://deb.debian.org/debian/ bullseye main non-free ...

Does this mean that the Testing image which I installed yesterday (currently idintifies itself as Debian 11) will automatically transform itself into Bookworm 12 over the next couple of weeks?

Now that Debian 11 has been released I ran over and downloaded the Debian Testing ISO build on Aug 18, spent 2 hours installing it and BOOM! I ended up with a Debian 11 instead of Debian 12. So I downloaded the special ISO which includes non-free firmware and again BOOM, it was not Bookworm.

Can someone please suggest how to obtain Debian Testing as Bookworm 12? I was all fired up about getting this but have failed at the expense of losing 2 hours out of my life. I didn't download SID because I ...