[Touch-packages] [Bug 1969976] Re: DynamicUser=1 doesn't get along with services that need dbus-daemon

2022-07-15 Thread Tom Hughes 
It may be fixed for kinetic but it's still very much not fixed for
jammy! That still has the broken 1.7.5 release...

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1969976

Title:
  DynamicUser=1 doesn't get along with services that need dbus-daemon

Status in Fwupd:
  Fix Released
Status in systemd:
  New
Status in fwupd package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Won't Fix
Status in fwupd source package in Focal:
  Confirmed
Status in systemd source package in Focal:
  Won't Fix
Status in fwupd source package in Impish:
  Confirmed
Status in systemd source package in Impish:
  Won't Fix
Status in fwupd source package in Jammy:
  Confirmed
Status in systemd source package in Jammy:
  Won't Fix

Bug description:
  Updating to systemd 245.4-4ubuntu3.16 has caused a regression in
  Ubuntu 20.04, that fwupd-refresh.service always fails to run.

  This has been root caused down to the changes in
  https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538

  Unfortunately this is an upstream issue introduced by stable systemd.
  https://github.com/systemd/systemd/issues/22737

  The problem also occurs in Ubuntu 22.04 with a newer systemd release.
  As discussed in 
https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1871538/comments/61
 it's a tradeoff of issues.  So within Ubuntu something probably needs to be 
done about fwupd-refresh.service.

  One proposal is to remove DynamicUser=yes from the systemd unit, but
  this will mean fwupdgmr refresh runs as root.  It's relatively
  sandboxed by other security mechanisms, but still not ideal.  Could we
  repurpose any other service account?  Or alternatively we can make a
  new fwupd service account that this systemd unit uses.

To manage notifications about this bug go to:
https://bugs.launchpad.net/fwupd/+bug/1969976/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1902109]

2020-11-04 Thread Tom Hughes 
Also rsync in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1894485

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsync in Ubuntu.
https://bugs.launchpad.net/bugs/1902109

Title:
  rsync uses lchmod and fails in Ubuntu >= 20.10 if /proc isn't mounted

Status in GLibC:
  Confirmed
Status in glibc package in Ubuntu:
  New
Status in rsync package in Ubuntu:
  Triaged

Bug description:
  Rsync in Ubuntu 20.10 fails when /proc isn't mounted, while it worked before.
  This happens because AC_CHECK_FUNC(lchmod) returns "yes" in 20.10, while it 
returned "no" before.

  Steps to reproduce:

  # Emulate /proc not being mounted
  $ mount --bind / /mnt
  $ chroot /mnt rsync -a /bin/ls .
  rsync: [receiver] failed to set permissions on "/.ls.CDExhu": Operation not 
supported (95)
  rsync error: some files/attrs were not transferred (see previous errors) 
(code 3) at main.c(1330) [sender=3.2.3]

  I reported this issue upstream in
  https://github.com/WayneD/rsync/issues/109 but the rsync developer
  says it's a problem in libc, and it might well be.

  Simple C code to reproduce the problem without rsync:

  printf("lchmod returned: %d\n", lchmod("/tmp/ls", 0755));

  If /tmp/ls is e.g. mode=0123, and needs to be changed, lchmod fails
  when /proc isn't mounted, yet it succeeds if it is mounted.

  Python had a similar issue, and they ended up avoiding
  AC_CHECK_FUNC(lchmod) under Linux:

  https://bugs.python.org/issue34652
  
https://github.com/python/cpython/commit/69e96910153219b0b15a18323b917bd74336d229#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810R3140

  ```c
  if test "$MACHDEP" != linux; then
AC_CHECK_FUNC(lchmod)
  fi
  ```

  So I'm not sure which package is causing the bug here. Should autoconf
  return false? Should libc implement lchown without the bug? Or should
  rsync skip lchmod under Linux, like python did?

To manage notifications about this bug go to:
https://bugs.launchpad.net/glibc/+bug/1902109/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1833671] Re: bond interfaces stop working after restart of systemd-networkd

2019-07-25 Thread Tom Hughes 
I've just updated the two machines where I was seeing this to
237-3ubuntu10.25 and in both cases the update was successful and managed
to complete without disconnecting the network.

** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1833671

Title:
  bond interfaces stop working after restart of systemd-networkd

Status in systemd:
  Unknown
Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  [impact]

  restarting systemd-networkd drops carrier on all bond slaves,
  temporarily interrupting networking over the bond.

  [test case]

  on a bionic system with 2 interfaces that can be put into a bond,
  create config files such as:

  root@lp1833671:~# cat /etc/systemd/network/10-bond0.netdev 
  [NetDev]
  Name=bond0
  Kind=bond

  root@lp1833671:~# cat /etc/systemd/network/20-ens8.network 
  [Match]
  Name=ens8

  [Network]
  Bond=bond0

  root@lp1833671:~# cat /etc/systemd/network/20-ens9.network 
  [Match]
  Name=ens9

  [Network]
  Bond=bond0

  root@lp1833671:~# cat /etc/systemd/network/30-bond0.network 
  [Match]
  Name=bond0

  [Network]
  Address=1.2.3.4/32

  
  restart networkd, or reboot, and verify the bond is up:

  root@lp1833671:~# ip a
  3: ens8:  mtu 1500 qdisc fq_codel 
master bond0 state UP group default qlen 1000
  link/ether 42:30:62:cc:36:2b brd ff:ff:ff:ff:ff:ff
  4: ens9:  mtu 1500 qdisc fq_codel 
master bond0 state UP group default qlen 1000
  link/ether 42:30:62:cc:36:2b brd ff:ff:ff:ff:ff:ff
  5: bond0:  mtu 1500 qdisc noqueue 
state UP group default qlen 1000
  link/ether 42:30:62:cc:36:2b brd ff:ff:ff:ff:ff:ff
  inet 1.2.3.4/32 scope global bond0
 valid_lft forever preferred_lft forever
  inet6 fe80::4030:62ff:fecc:362b/64 scope link 
 valid_lft forever preferred_lft forever

  
  restart networkd and check /var/log/syslog:

  root@lp1833671:~# systemctl restart systemd-networkd
  root@lp1833671:~# cat /var/log/syslog 
  ...
  Jul 23 21:08:07 lp1833671 systemd-networkd[1805]: ens9: Lost carrier
  Jul 23 21:08:07 lp1833671 systemd-networkd[1805]: ens8: Lost carrier
  Jul 23 21:08:07 lp1833671 systemd-networkd[1805]: ens9: Gained carrier
  Jul 23 21:08:07 lp1833671 systemd-networkd[1805]: ens8: Gained carrier

  [regression potential]

  this changes how bond slaves are managed, so regressions could affect
  any configurations using bonding.

  [other info]

  the patch is already included in d, and ifupdown manages networking in
  x, so this is needed only for b.

  [original description]

  Running systemd-networkd from systemd 237-3ubuntu10.23 on Ubuntu
  18.04.2 I have one machine where, every time systemd-networkd restarts
  (ie every time there is an update to systemd) the bond0 interface
  stops working.

  I see both physical interfaces go soft down and then come back again:

  Jun 21 07:28:24 odin.openstreetmap.org systemd[1]: systemd 237 running in 
system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SEC
  Jun 21 07:28:24 odin.openstreetmap.org systemd[1]: Detected architecture 
x86-64.
  Jun 21 07:28:24 odin.openstreetmap.org kernel: bond0: link status down for 
backup interface eno2, disabling it in 200 ms
  Jun 21 07:28:24 odin.openstreetmap.org kernel: bond0: link status down for 
active interface eno1, disabling it in 200 ms
  Jun 21 07:28:24 odin.openstreetmap.org kernel: 8021q: adding VLAN 0 to HW 
filter on device eno2
  Jun 21 07:28:25 odin.openstreetmap.org kernel: 8021q: adding VLAN 0 to HW 
filter on device eno1
  Jun 21 07:28:25 odin.openstreetmap.org kernel: bond0: link status up again 
after 200 ms for interface eno2
  Jun 21 07:28:25 odin.openstreetmap.org kernel: bond0: link status up again 
after 100 ms for interface eno1

  and after that nothing until I stop systemd-networkd, delete the bond
  interface, and then start systemd-networkd again.

  On most machines the cycle seems to take a bit longer and the
  interfaces reach a hard down start before coming back and in that case
  there seems to be no problem.

  I think this is likely an instance of this upstream bug:

  https://github.com/systemd/systemd/issues/10118

  which has a fix here:

  https://github.com/systemd/systemd/pull/10465

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1833671/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1833671] [NEW] bond interfaces stop working after restart of systemd-networkd

2019-06-21 Thread Tom Hughes 
Public bug reported:

Running systemd-networkd from systemd 237-3ubuntu10.23 on Ubuntu 18.04.2
I have one machine where, every time systemd-networkd restarts (ie every
time there is an update to systemd) the bond0 interface stops working.

I see both physical interfaces go soft down and then come back again:

Jun 21 07:28:24 odin.openstreetmap.org systemd[1]: systemd 237 running in 
system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SEC
Jun 21 07:28:24 odin.openstreetmap.org systemd[1]: Detected architecture x86-64.
Jun 21 07:28:24 odin.openstreetmap.org kernel: bond0: link status down for 
backup interface eno2, disabling it in 200 ms
Jun 21 07:28:24 odin.openstreetmap.org kernel: bond0: link status down for 
active interface eno1, disabling it in 200 ms
Jun 21 07:28:24 odin.openstreetmap.org kernel: 8021q: adding VLAN 0 to HW 
filter on device eno2
Jun 21 07:28:25 odin.openstreetmap.org kernel: 8021q: adding VLAN 0 to HW 
filter on device eno1
Jun 21 07:28:25 odin.openstreetmap.org kernel: bond0: link status up again 
after 200 ms for interface eno2
Jun 21 07:28:25 odin.openstreetmap.org kernel: bond0: link status up again 
after 100 ms for interface eno1

and after that nothing until I stop systemd-networkd, delete the bond
interface, and then start systemd-networkd again.

On most machines the cycle seems to take a bit longer and the interfaces
reach a hard down start before coming back and in that case there seems
to be no problem.

I think this is likely an instance of this upstream bug:

https://github.com/systemd/systemd/issues/10118

which has a fix here:

https://github.com/systemd/systemd/pull/10465

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1833671

Title:
  bond interfaces stop working after restart of systemd-networkd

Status in systemd package in Ubuntu:
  New

Bug description:
  Running systemd-networkd from systemd 237-3ubuntu10.23 on Ubuntu
  18.04.2 I have one machine where, every time systemd-networkd restarts
  (ie every time there is an update to systemd) the bond0 interface
  stops working.

  I see both physical interfaces go soft down and then come back again:

  Jun 21 07:28:24 odin.openstreetmap.org systemd[1]: systemd 237 running in 
system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP 
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SEC
  Jun 21 07:28:24 odin.openstreetmap.org systemd[1]: Detected architecture 
x86-64.
  Jun 21 07:28:24 odin.openstreetmap.org kernel: bond0: link status down for 
backup interface eno2, disabling it in 200 ms
  Jun 21 07:28:24 odin.openstreetmap.org kernel: bond0: link status down for 
active interface eno1, disabling it in 200 ms
  Jun 21 07:28:24 odin.openstreetmap.org kernel: 8021q: adding VLAN 0 to HW 
filter on device eno2
  Jun 21 07:28:25 odin.openstreetmap.org kernel: 8021q: adding VLAN 0 to HW 
filter on device eno1
  Jun 21 07:28:25 odin.openstreetmap.org kernel: bond0: link status up again 
after 200 ms for interface eno2
  Jun 21 07:28:25 odin.openstreetmap.org kernel: bond0: link status up again 
after 100 ms for interface eno1

  and after that nothing until I stop systemd-networkd, delete the bond
  interface, and then start systemd-networkd again.

  On most machines the cycle seems to take a bit longer and the
  interfaces reach a hard down start before coming back and in that case
  there seems to be no problem.

  I think this is likely an instance of this upstream bug:

  https://github.com/systemd/systemd/issues/10118

  which has a fix here:

  https://github.com/systemd/systemd/pull/10465

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1833671/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp