Bug#1037044: Forced password reset leaves behind failed user@.service unit
Control: fixed -1 254.1-2 On Fri, 2 Jun 2023 13:22:02 -0400 Jason Franklin wrote: Package: systemd Version: 252.6-1 Severity: normal Greetings: It appears that user@.service is left in a failed state when a user logs in over ssh and is forced to reset their password due to expiration. I was able to regularly reproduce this behavior with the process described below. # Create a test user. $ sudo adduser fish ... # Ensure no failed units. $ systemctl list-units --failed ... # Expire the user's password. $ sudo passwd -e fish # Log in via ssh. Properly change the user's password when prompted. $ ssh fish@localhost ... # Here, you will be kicked back out to your prompt after the new # password is set. # Now, note that a failed unit for the user is left behind. $ systemctl list-units --failed UNIT LOAD ACTIVE SUBDESCRIPTION * user@1001.service loaded failed failed User Manager for UID 1001 ... I think the above accurately describes the behavior I'm seeing. It seems odd to me that the failed service lingers even though the user's password has been changed correctly, without any real failures in the process. The user is now able to log in and what not, but systemd indicates a failure. This is an issue for me because these failures can stack up on systems at my work, and monitoring of failed units then indicates a problem where there is not one. Please let me know any thoughts on this. It could be another piece of software that's causing the error. Or, it could be that I have something improperly configured or that I am misinterpreting things. Seems to work in trixie/sid, so marking as fixed for that version. OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: Re: Forced password reset leaves behind failed user@.service unit
Processing control commands: > fixed -1 254.1-2 Bug #1037044 [systemd] Forced password reset leaves behind failed user@.service unit Marked as fixed in versions systemd/254.1-2. -- 1037044: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037044 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1023545: marked as done (systemd --user and sd-pam processes keep running after logout (again))
Your message dated Wed, 23 Aug 2023 00:21:44 +0200 with message-id <8f6b9ef2-1bd6-4622-960b-458cd12f5...@debian.org> and subject line Re: systemd --user and sd-pam processes keep running after logout (again) has caused the Debian Bug report #1023545, regarding systemd --user and sd-pam processes keep running after logout (again) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1023545: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023545 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 252-2 Severity: normal Dear Maintainer, similar to #749268 there seems to be again the problem, that when logging out, the systemd user process and sd-pam are not killed. Take, e.g., this example: # loginctl kill-session 34 # pgrep -a -u pat 11499 /lib/systemd/systemd --user 11500 (sd-pam) # loginctl list-sessions SESSION UID USER SEAT TTY 13 0 root seat0 tty2 21 0 root seat0 tty2 25 0 root seat0 tty2 33 0 root seat0 tty2 36 0 root seat0 tty2 37 121 sddm seat0 6 sessions listed. So although there is no logind session left, there are still the two user processes around. I added KillUserProcesses=yes but that did not help (is this an additional bug?). Do I miss anything in order to kill the systemd user process automatically? Kind regards Patrick -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers stable-security APT policy: (900, 'stable-security'), (900, 'testing'), (800, 'stable'), (500, 'unstable-debug'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-2-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE=de:en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii libacl12.3.1-1 ii libaudit1 1:3.0.7-1.1+b1 ii libblkid1 2.38.1-1.1+b1 ii libc6 2.35-4 ii libcap21:2.44-1 ii libcryptsetup122:2.5.0-6 ii libfdisk1 2.38.1-1.1+b1 ii libgcrypt201.10.1-2 ii libkmod2 30+20220905-1 ii liblz4-1 1.9.4-1 ii liblzma5 5.2.7-0.1 ii libmount1 2.38.1-1.1+b1 ii libseccomp22.5.4-1+b1 ii libselinux13.4-1+b2 ii libssl33.0.7-1 ii libsystemd-shared 252-2 ii libsystemd0252-2 ii libzstd1 1.5.2+dfsg-1 ii mount 2.38.1-1.1+b1 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.14.4-1 ii systemd-timesyncd [time-daemon] 252-2 Versions of packages systemd suggests: ii libfido2-11.12.0-1 ii libtss2-esys-3.0.2-0 3.2.0-1+b1 ii libtss2-mu0 3.2.0-1+b1 pn libtss2-rc0 ii policykit-1 122-1 pn systemd-boot ii systemd-container 252-2 pn systemd-homed ii systemd-resolved 252-2 pn systemd-userdbd Versions of packages systemd is related to: ii dbus-user-session 1.14.4-1 pn dracut ii initramfs-tools0.142 ii libnss-systemd 252-2 ii libpam-systemd 252-2 ii udev 252-2 -- Configuration Files: /etc/systemd/journald.conf changed: [Journal] SystemMaxUse=300M /etc/systemd/logind.conf changed: [Login] KillUserProcesses=yes /etc/systemd/system.conf changed: [Manager] DefaultTimeoutStartSec=20s DefaultTimeoutStopSec=15s DefaultDeviceTimeoutSec=20s -- no debconf information --- End Message --- --- Begin Message --- On Mon, 5 Dec 2022 22:42:11 +0100 Michael Biebl wrote: On Sun, 06 Nov 2022 14:37:39 +0100 =?utf-8?q?Patrick_H=C3=A4cker?= wrote: > Package: systemd > Version: 252-2 > Severity: normal > > Dear Maintainer, > > similar to #749268 there seems to be again the problem, that when logging > out, the systemd user process and sd-pam are not killed. > > Take, e.g., this example: > # loginctl kill-session 34 > > # pgrep -a -u pat > 11499 /lib/systemd/systemd --user > 11500 (sd-pam) > > # loginctl list-sessions > SESSION UID USER SEAT TTY > 13 0 root seat0 tty2 > 21 0 root seat0 tty2 > 25 0 root seat0 tty2 > 33 0 root seat0 tty2 > 36 0 root seat0 tty2 > 37 121 sddm seat0 > > 6 sessions listed. > > So although there is no logind session left, there are still the two user > processes around. > > I added > KillUserProcesses=yes > but that did not help (is this an additional bug?). > > Do I miss anything in order to kill the systemd user process
Bug#876261: marked as done (PathModified in path activation propagates to containing directory when file is deleted)
Your message dated Tue, 22 Aug 2023 23:44:35 +0200 with message-id <3adde7ef-5d5d-422b-b40d-aca371868...@debian.org> and subject line Re: PathModified in path activation propagates to containing directory when file is deleted has caused the Debian Bug report #876261, regarding PathModified in path activation propagates to containing directory when file is deleted to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 876261: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876261 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 232-25+deb9u1 Severity: normal Hello, given this setup: # cat beeponce.service [Unit] Description=Beeps [Service] Type=oneshot ExecStart=/usr/bin/aplay /tmp/beep.wav # cat beeponce.path [Unit] Description=Monitor /tmp/zz [Path] PathModified=/tmp/zz This happens: touch /tmp/zz # BEEP! (ok) rm /tmp/zz # BEEP! (ok) touch /tmp/foo # BEEP! (What??) touch /tmp/foo # silence (ok) touch /tmp/zz # BEEP! (ok) touch /tmp/foo # silence (ok) It looks like systemd is listening to events in the containing directory to catch if the file is created, and after removing the file it accidentally triggers on a directory event even if it's not about the file being monitored. Enrico -- Package-specific info: -- System Information: Debian Release: 9.1 APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-3 ii libaudit1 1:2.6.7-2 ii libblkid1 2.29.2-1 ii libc6 2.24-11+deb9u1 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-4 ii libgcrypt20 1.7.6-2+deb9u2 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-6 ii libkmod223-2 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.2+b1 ii libmount1 2.29.2-1 ii libpam0g1.1.8-3.6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b1 ii libsystemd0 232-25+deb9u1 ii mount 2.29.2-1 ii procps 2:3.3.12-3 ii util-linux 2.29.2-1 Versions of packages systemd recommends: ii dbus1.10.18-1 ii libpam-systemd 232-25+deb9u1 Versions of packages systemd suggests: ii policykit-10.105-18 ii systemd-container 232-25+deb9u1 ii systemd-ui 3-4+b1 Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.130 ii udev 232-25+deb9u1 -- no debconf information --- End Message --- --- Begin Message --- Version: 254.1-2 On Wed, 20 Sep 2017 11:42:58 +0200 Enrico Zini wrote: Package: systemd Version: 232-25+deb9u1 Severity: normal Hello, given this setup: # cat beeponce.service [Unit] Description=Beeps [Service] Type=oneshot ExecStart=/usr/bin/aplay /tmp/beep.wav # cat beeponce.path [Unit] Description=Monitor /tmp/zz [Path] PathModified=/tmp/zz This happens: touch /tmp/zz # BEEP! (ok) rm /tmp/zz # BEEP! (ok) touch /tmp/foo # BEEP! (What??) touch /tmp/foo # silence (ok) touch /tmp/zz # BEEP! (ok) touch /tmp/foo # silence (ok) It looks like systemd is listening to events in the containing directory to catch if the file is created, and after removing the file it accidentally triggers on a directory event even if it's not about the file being monitored. Seems to work as expected in sid, so closing for that version. OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#751486: marked as done (systemd: journald flooding logs if filesystem is mounted read-only)
Your message dated Tue, 22 Aug 2023 23:38:36 +0200 with message-id and subject line Re: systemd: journald flooding logs if filesystem is mounted read-only has caused the Debian Bug report #751486, regarding systemd: journald flooding logs if filesystem is mounted read-only to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 751486: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751486 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 204-10 Severity: normal Dear Maintainer, due to some filesystem problems, everything on my system except for /home, was mounted as read-only. This caused journald to flood me with error messages, preventing me from realizing what was actually going on. All I could see on the screen were journald error messages. I attach my dmesg. -- Package-specific info: -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.15.0a (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages systemd depends on: ii acl 2.2.52-1 ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.2 ii libacl1 2.2.52-1 ii libaudit11:2.3.6-1 ii libc62.19-1 ii libcap2 1:2.22-1.2 ii libcap2-bin 1:2.22-1.2 ii libcryptsetup4 2:1.6.4-4 ii libdbus-1-3 1.8.4-1 ii libgcrypt11 1.5.3-4 ii libkmod2 17-2 ii liblzma5 5.1.1alpha+20120614-2 ii libpam0g 1.1.8-3 ii libselinux1 2.3-1 ii libsystemd-daemon0 204-10 ii libsystemd-journal0 204-10 ii libsystemd-login0204-10 ii libudev1 204-10 ii libwrap0 7.6.q-25 ii sysv-rc 2.88dsf-53.2 ii udev 204-10 ii util-linux 2.20.1-5.8 Versions of packages systemd recommends: ii libpam-systemd 204-10 Versions of packages systemd suggests: pn systemd-ui -- no debconf information 0 overridden configuration files found. ==> /var/lib/systemd/deb-systemd-helper-enabled/cron.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/cron.service ==> /var/lib/systemd/deb-systemd-helper-enabled/dnsmasq.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/dnsmasq.service ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/dnsmasq.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/cron.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/rsyslog.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/syslog.service <== ==> /var/lib/systemd/deb-systemd-helper-enabled/rsyslog.service.dsh-also <== /etc/systemd/system/multi-user.target.wants/rsyslog.service /etc/systemd/system/syslog.service # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # proc/proc procdefaults0 0 /dev/sda2 / ext4noatime,errors=remount-ro 0 1 /dev/sda3 /home ext4noatime,defaults,commit=3000 2 /dev/sda1 noneswapsw 0 0 #/dev/sdb1 /media/cdrom0 udf,iso9660 user,noauto 0 0 #/dev/scd0 /media/cdrom1 udf,iso9660 user,noauto 0 0 #windows partition /dev/sda4 /media/windows ntfsnoauto,uid=501,gid=501,users0 0 http://computerazzo.homelinux.com/music/ /home/salvo/mp3/remote davfs user,noauto,ro,noexec,nosuid,uid=1001,gid=1001 0 0 tmpfs /amem tmpfs size=2G 0 0 tmpfs /run/user tmpfs nodev,nosuid,size=2M 0 0 tmpfs /run/ tmpfs nodev,nosuid,size=4M 0 0 tmpfs /dev/shm tmpfs nodev,nosuid,size=60M 0 0 tmpfs /sys/fs/cgrouptmpfs nodev,nosuid,size=4M 0 0 tmpfs /run/lock tmpfs nodev,nosuid,size=4M 0 0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.15.0a (root@hal9000) (gcc version 4.8.3 (Debian 4.8.3-3) ) #1 SMP Tue Jun 10 12:19:21 CEST 2014 [
Bug#810608: marked as done (systemd-sysv: on shutdown, fails to inform users that the system is going down)
Your message dated Tue, 22 Aug 2023 23:35:40 +0200 with message-id <674d22c0-b790-4540-a78b-aae57eeb6...@debian.org> and subject line Re: Bug#810608: systemd-sysv: on shutdown, fails to inform users that the system is going down has caused the Debian Bug report #810608, regarding systemd-sysv: on shutdown, fails to inform users that the system is going down to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 810608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810608 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd-sysv Version: 228-2+b1 Severity: normal Hello, I noticed a feature that systemd seems to lack. When the box is being shut down (reboot or halt or poweroff), users are not notified in any way of what is happening. For instance, any remote user (connected via SSH) is correctly forced out of the system (provided that libpam-systemd is installed and OpenSSH has UsePAM enabled, see bug #751636 for the long discussion about this), but there is no indication as to why the user was kicked out. On boxes that have sysvinit as PID 1, the users get an informative: Broadcast message from root@HOSTNAME (pts/0) (CURRENT TIME): The system is going down for reboot NOW! or Broadcast message from root@HOSTNAME (pts/0) (CURRENT TIME): The system is going down for system halt NOW! Could this feature be implemented in systemd as well? It should be easy to add an appropriate wall(1) invocation on shutdown. I hope it can be done soon. Thanks for your time! Bye. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (800, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd-sysv depends on: ii systemd 228-2+b1 systemd-sysv recommends no packages. systemd-sysv suggests no packages. -- no debconf information --- End Message --- --- Begin Message --- Version: 240-1 On Tue, 24 Jul 2018 22:27:05 +0200 Francesco Poli wrote: On Tue, 24 Jul 2018 21:59:56 +0200 Michael Biebl wrote: > Control: forwarded -1 https://github.com/systemd/systemd/issues/3700 > > Am 21.07.2018 um 20:07 schrieb Francesco Poli: > > On Sat, 21 Jul 2018 01:21:52 +0200 Michael Biebl wrote: > > > > [...] > >> For remote logins, it might be useful. > > > > Exactly: it is useful to figure out why your SSH connection got closed... > > Marking as forwarded Thank you so much for your prompt and kind reaction! :-) Now let's hope the bug will be fixed soon... Supposed to be fixed by https://github.com/systemd/systemd/commit/3d0ef5c7e00155bc74f6f71c34cad518a4ff56ba which is part of v240. So closing the bug report accordingly. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message ---
Processed: fixed 1040149 in 252.12-1~deb12u1, closing 1040149
Processing commands for cont...@bugs.debian.org: > fixed 1040149 252.12-1~deb12u1 Bug #1040149 [systemd] systemd: services considered running after mainpid has exited Marked as fixed in versions systemd/252.12-1~deb12u1. > close 1040149 Bug #1040149 [systemd] systemd: services considered running after mainpid has exited Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 1040149: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040149 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: fixed 1040149 in 254-1
Processing commands for cont...@bugs.debian.org: > fixed 1040149 254-1 Bug #1040149 [systemd] systemd: services considered running after mainpid has exited Marked as fixed in versions systemd/254-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1040149: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040149 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1041652: udev: Udev database attached to udev reportbug might contain sensitive information
On Tue, 22 Aug 2023 17:11:29 +0200 Michael Biebl wrote: > I posted a MR here > https://salsa.debian.org/systemd-team/systemd/-/merge_requests/207 > > The default is to include the information. If you have suggestions to > the wording, please follow-up in the MR. Hi Michael, thanks for your kind reply. The MR looks good to me. -- Michael Büsch https://bues.ch/ pgpXGi0UB4Hix.pgp Description: OpenPGP digital signature
Bug#815154: marked as done (systemd: localed wrote a /etc/default/keyboard without XKBMODEL)
Your message dated Tue, 22 Aug 2023 17:28:20 +0200 with message-id <5398c554-6b85-460e-a2e3-57e84b133...@debian.org> and subject line Re: systemd: localed wrote a /etc/default/keyboard withouth XKBMODEL has caused the Debian Bug report #765343, regarding systemd: localed wrote a /etc/default/keyboard without XKBMODEL to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 765343: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765343 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: initramfs-tools Version: 0.115 Severity: normal File: /usr/share/initramfs-tools/hooks/keymap Hello, Since one or two days, the keymap on my laptop is wrong at really early boot when I need to input the password for my cryptsetup partion. Today when running update-initramfs -u I saw the following message: Warning: error while trying to store keymap file - ignoring request to install /etc/boottime.kmap.gz Running "setupcon --save-keyboard" by hand here is indeed returning 1 According to the manpage, the --save-keyboard doesn't seems to exist at all Cheers, Laurent Bigonville -- Package-specific info: -- initramfs sizes -rw-r--r--. 1 root root 18M Jun 18 10:32 /boot/initrd.img-3.14-1-amd64 -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.14-1-amd64 root=/dev/mapper/soldur-root ro "acpi_osi=!Windows 2009" quiet selinux=1 security=selinux audit=1 -- resume RESUME=/dev/mapper/soldur-swap_1 -- /proc/filesystems btrfs ext3 ext2 ext4 fuseblk vfat -- lsmod Module Size Used by cpuid 12663 0 joydev 17063 0 xt_CHECKSUM12471 1 ipt_MASQUERADE 12594 3 xt_tcpudp 12527 6 ipt_REJECT 12465 4 xt_conntrack 12681 3 ebtable_nat12580 0 ebtable_broute 12541 0 bridge 97129 1 ebtable_broute stp12437 1 bridge llc12745 2 stp,bridge ebtable_filter 12591 0 ebtables 30026 3 ebtable_broute,ebtable_nat,ebtable_filter ip6table_nat 12649 0 nf_conntrack_ipv6 13605 1 nf_defrag_ipv6 29262 1 nf_conntrack_ipv6 nf_nat_ipv612920 1 ip6table_nat ip6table_mangle12540 0 ip6table_security 12548 0 ip6table_raw 12528 0 ip6table_filter12540 0 ip6_tables 26024 5 ip6table_filter,ip6table_mangle,ip6table_security,ip6table_nat,ip6table_raw iptable_nat12646 1 nf_conntrack_ipv4 18455 4 nf_defrag_ipv4 12483 1 nf_conntrack_ipv4 nf_nat_ipv412912 1 iptable_nat nf_nat 18156 5 ipt_MASQUERADE,nf_nat_ipv4,nf_nat_ipv6,ip6table_nat,iptable_nat nf_conntrack 70938 9 ipt_MASQUERADE,nf_nat,nf_nat_ipv4,nf_nat_ipv6,xt_conntrack,ip6table_nat,iptable_nat,nf_conntrack_ipv4,nf_conntrack_ipv6 iptable_mangle 12536 1 iptable_security 12544 1 iptable_raw12524 1 iptable_filter 12536 1 ip_tables 21915 5 iptable_security,iptable_filter,iptable_mangle,iptable_nat,iptable_raw x_tables 23015 16 iptable_security,ip6table_filter,ip6table_mangle,xt_CHECKSUM,ip_tables,xt_tcpudp,ipt_MASQUERADE,ip6table_security,xt_conntrack,iptable_filter,ip6table_raw,ebtables,ipt_REJECT,iptable_mangle,ip6_tables,iptable_raw bnep 17388 2 snd_hda_codec_hdmi 40955 4 pci_stub 12429 1 vboxpci18981 0 vboxnetadp 25443 0 binfmt_misc16949 1 vboxnetflt 23324 0 vboxdrv 261792 3 vboxnetadp,vboxnetflt,vboxpci uinput 17372 1 nfsd 254693 2 auth_rpcgss51240 1 nfsd oid_registry 12419 1 auth_rpcgss nfs_acl12511 1 nfsd nfs 183672 0 lockd 79321 2 nfs,nfsd fscache45542 1 nfs sunrpc228923 6 nfs,nfsd,auth_rpcgss,lockd,nfs_acl nls_utf8 12456 1 x86_pkg_temp_thermal12951 0 nls_cp437 16553 1 intel_powerclamp 17159 0 vfat 17135 1 fat53794 1 vfat tpm_rng12422 0 rng_core 12688 2 tpm_rng iTCO_wdt 12831 0 iTCO_vendor_support12649 1 iTCO_wdt loop 26605 0 fuse 78839 3 arc4 12536 2 efi_pstore 12805 1 uvcvideo 78960 0 videobuf2_vmalloc 12816 1
Bug#765343: marked as done (systemd: localed wrote a /etc/default/keyboard without XKBMODEL)
Your message dated Tue, 22 Aug 2023 17:28:20 +0200 with message-id <5398c554-6b85-460e-a2e3-57e84b133...@debian.org> and subject line Re: systemd: localed wrote a /etc/default/keyboard withouth XKBMODEL has caused the Debian Bug report #765343, regarding systemd: localed wrote a /etc/default/keyboard without XKBMODEL to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 765343: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765343 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 215-5+b1 Hi! What happened: 1. Install Debian with GNOME desktop using Jessie d-i beta 2. 2. Upgrade to sid. 3. Add new layouts in Input Sources through the Region & Language interface. 4. Install Plymouth. 5. Restart. 6. Be unable to enter disk passphrase. I hadn't notice when installing Plymouth that `update-initramfs` actually issue an error about not being able to save a boottime keymap… After more investigation, it seems that `/etc/default/keyboard` only had entries for XKBLAYOUT, XKBVARIANT and BACKSPACE. This was prevent the boot keymap from being generated as `setupcon` will exit unless `XKBMODEL` is set. Adding back XKBMODEL to `/etc/default/keyboard` and issuing `update-initramfs -u` restored a working keymap. I am not sure what made localed unable to get the keyboard model, but maybe that situation is bad enough to make it have a fallback value? -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature --- End Message --- --- Begin Message --- On Tue, 14 Oct 2014 12:37:48 +0200 =?iso-8859-1?B?Suly6W15?= Bobbio wrote: Package: systemd Version: 215-5+b1 Hi! What happened: 1. Install Debian with GNOME desktop using Jessie d-i beta 2. 2. Upgrade to sid. 3. Add new layouts in Input Sources through the Region & Language interface. 4. Install Plymouth. 5. Restart. 6. Be unable to enter disk passphrase. I hadn't notice when installing Plymouth that `update-initramfs` actually issue an error about not being able to save a boottime keymap… After more investigation, it seems that `/etc/default/keyboard` only had entries for XKBLAYOUT, XKBVARIANT and BACKSPACE. This was prevent the boot keymap from being generated as `setupcon` will exit unless `XKBMODEL` is set. Adding back XKBMODEL to `/etc/default/keyboard` and issuing `update-initramfs -u` restored a working keymap. I am not sure what made localed unable to get the keyboard model, but maybe that situation is bad enough to make it have a fallback value? XKBMODEL should correctly be handled by localed nowadays. If not, please file a new bug report. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#754078: marked as done (crypt devices not brought online (backed by iscsi))
Your message dated Tue, 22 Aug 2023 17:26:05 +0200 with message-id <008d38ba-196b-4010-940a-bc78cbf79...@debian.org> and subject line Re: Bug#754078: crypt devices not brought online (backed by iscsi) has caused the Debian Bug report #754078, regarding crypt devices not brought online (backed by iscsi) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 754078: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754078 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 204-14 Severity: normal Hi, as discussed on IRC, systemd fails to bring up my iscsi-backed crypt devices. Before systemd-sysv hit testing and was installed, they worked. Also, it seems to spend an awful lot of time bringing them online (significantly longer than a minute or so). I booted with systemd.log_level=debug, and put the contents of /var/log/debug.log up at https://www.palfrader.org/volatile/2014-07-07-8CnmVmaPpZA/var-log-debug } weasel@valiant:~$ cat /etc/crypttab } sda3_crypt UUID=81402c7d-3819-4860-b71f-ff0f808f599e none luks } sda6_crypt UUID=4385f6be-9584-4fd9-a3b8-92a2826311a5 /etc/luks/sda6.key luks } } aux1 /dev/disk/by-path/ip-172.22.118.11\:3260-iscsi-iqn.1992-04.com.emc\:storage.storcenter.sbg.palfrader.org.aux1-lun-0 /etc/luks/aux1.key luks,noearly } mailbak /dev/disk/by-path/ip-172.22.118.11\:3260-iscsi-iqn.1992-04.com.emc\:storage.storcenter.sbg.palfrader.org.mailbak-lun-0 /etc/luks/mailbak.key luks,noearly sda* are online, aux1 and mailback are not. Their backing devices exist: ] lrwxrwxrwx 1 root root 9 Jul 7 13:11 /dev/disk/by-path/ip-172.22.118.11:3260-iscsi-iqn.1992-04.com.emc:storage.storcenter.sbg.palfrader.org.aux1-lun-0 -> ../../sdi ] lrwxrwxrwx 1 root root 9 Jul 7 13:11 /dev/disk/by-path/ip-172.22.118.11:3260-iscsi-iqn.1992-04.com.emc:storage.storcenter.sbg.palfrader.org.mailbak-lun-0 -> ../../sdh fstab does not reference aux1 and mailbak - they get included using autofs. Cheers, weasel --- End Message --- --- Begin Message --- On Thu, 14 Aug 2014 20:03:12 +0200 Lennart Poettering wrote: On Sun, 20.07.14 15:58, Michael Biebl (bi...@debian.org) wrote: > > Currently, with systemd, it gets to where it'd like to bring up the > > crypt devices. As network and open-iscsi aren't up yet, it wastes a lot > > of time waiting for block devices that will never appear (at least not > > without further action later in the boot process). > > Hm, k. So I guess we'd need something like a cryptsetup-pre.target, > where certain units can hook into (via Wants/Before), network.target > being one of them. > And devices flagged noearly would get a dependency on this target and be > ordered after it. > > Lennart, do you have a different/better idea how we could handle such > setups which have more complex requirements, like cryptsetup devices > being backed by iscsi which in turn requires network access? Not following here. In contrast to classic sysv the jobs actually stay queued until the devices show up. If you have iscsi devices that shall be mounted during boot, then you really need to make sure that iscsi can work in early boot. Then, if iscsi needs the network, then your network system needs to be able to run in early-boot too. I have the suspcicion this works on Fedora already. But generally, the old Debian scheme of running cryptsetup twice doesn't really apply to systemd, since we never scan for devices, we just subscribe to them. Anyway, still not grokking the actual problem here I must say... Let's close this issue at this point. I don't think it's helpful to keep this issue open while a lot has changed since 2014. If there is still something missing, please file a new bug report. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#1041652: udev: Udev database attached to udev reportbug might contain sensitive information
On Fri, 21 Jul 2023 19:31:14 +0200 =?utf-8?q?Michael_B=C3=BCsch?= wrote: Package: udev Version: 254~rc2-3 Severity: normal X-Debbugs-Cc: m...@bues.ch Dear Maintainer, when reporting a udev bug via reportbug the tool auto-attaches the complete udev database dump to the report. That came as a complete surprise to be. I didn't see any mention of that in the report process. Nor was there a way to prevent the attachment. I think auto-attaching the complete udev database is a confidentiality problem. The udev database might contain sensitive information that the reporter did not want to disclose to the public internet. Think of Luks DM names for example. The reporter is free to choose any name for them. The reporter might not have thought about that the name can end up being posted to the public internet when the reporter choose a name for the DM device. Besides that, the udev database is a very large fingerprint of the hardware that the user uses. By posting the udev database to the public internet, that hardware is permanently associated to the reporter's name. That may be a problem. Think of illegal things being done with the hardware after the original reporter sold the hardware to somebody else. Please also keep in mind that not all Debian users live in free countries with free speech. Associating hardware to people might be a major threat to people in such countries. Think of plausible deniability of ownership, for example. Therefore, my suggestion is: - Please make the posting of the udev database optional. - Also, please make it obvious that the complete database is posted during the process, if the option is chosen. And explain to the reporter what that database contains. I posted a MR here https://salsa.debian.org/systemd-team/systemd/-/merge_requests/207 The default is to include the information. If you have suggestions to the wording, please follow-up in the MR. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#803468: marked as done (migrate to /etc/locale.conf or drop the locale.conf man page)
Your message dated Tue, 22 Aug 2023 16:39:31 +0200 with message-id and subject line Re: systemd: /etc/locale.conf locale variables are not set into the user locale has caused the Debian Bug report #803468, regarding migrate to /etc/locale.conf or drop the locale.conf man page to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 803468: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803468 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 227-2 Severity: normal Dear Maintainer, after installing locales package, generating my localization, editing /etc/locale.conf and finally rebooting the system, all the locales variable now default to "POSIX", as stated from the output of "locale". "localectl status", though, shows the desired values (the one i set in /etc/locale.conf), so the status printed by localectl is different from the actual status of the system. Here is the output of the two commands: --- $ locale LANG= LANGUAGE= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= $ localectl status System Locale: LANG=C.UTF-8 LC_NUMERIC=it_IT.UTF-8 LC_TIME=it_IT.UTF-8 LC_MONETARY=it_IT.UTF-8 LC_NAME=it_IT.UTF-8 LC_ADDRESS=it_IT.UTF-8 LC_TELEPHONE=it_IT.UTF-8 LC_MEASUREMENT=it_IT.UTF-8 VC Keymap: n/a X11 Layout: it X11 Model: pc105 --- To circumvent this, i copied /etc/locale.conf to /etc/default/locale, and in this way the locale is correctly set at startup. Reading locale.conf(5) man page, one may think that editing /etc/locale.conf is enough to set the locale, but indeed it's not. Thanks. -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 4.2.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=, LC_CTYPE= (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.113+nmu3 ii libacl1 2.2.52-2 ii libapparmor12.10-2+b1 ii libaudit1 1:2.4.4-4 ii libblkid1 2.27-3 ii libc6 2.19-22 ii libcap2 1:2.24-12 ii libcap2-bin 1:2.24-12 ii libcryptsetup4 2:1.6.6-5 ii libgcc1 1:5.2.1-22 ii libgcrypt20 1.6.4-3 ii libkmod221-1 ii liblzma55.1.1alpha+20120614-2.1 ii libmount1 2.27-3 ii libpam0g1.1.8-3.1 ii libseccomp2 2.2.3-2 ii libselinux1 2.3-2+b1 ii libsystemd0 227-2 ii mount 2.27-3 ii sysv-rc 2.88dsf-59.2 ii udev227-2 ii util-linux 2.27-3 Versions of packages systemd recommends: ii dbus1.10.0-3 ii libpam-systemd 227-2 Versions of packages systemd suggests: pn systemd-container pn systemd-ui -- Configuration Files: /etc/systemd/logind.conf changed [not included] -- no debconf information --- End Message --- --- Begin Message --- Version: 253~rc2-1 On Fri, 30 Oct 2015 12:58:18 +0100 nfb wrote: Package: systemd Version: 227-2 Severity: normal Dear Maintainer, after installing locales package, generating my localization, editing /etc/locale.conf and finally rebooting the system, all the locales variable now default to "POSIX", as stated from the output of "locale". "localectl status", though, shows the desired values (the one i set in /etc/locale.conf), so the status printed by localectl is different from the actual status of the system. Here is the output of the two commands: ... To circumvent this, i copied /etc/locale.conf to /etc/default/locale, and in this way the locale is correctly set at startup. Reading locale.conf(5) man page, one may think that editing /etc/locale.conf is enough to set the locale, but indeed it's not. At least from systemds POV we can consider this done. Since 253~rc2-1, /etc/default/locale will be turned into a symlink to /etc/locale.conf. In the non-systemd use case, /etc/default/locale might remain a real file, so ideally the locales package would create /etc/locale.conf directly. @aurel32: would you be open to a MR implementing this change? Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#1039987: systemd-gpt-auto-generator(8) - wrong instruction how to disable
Am Tue, Aug 22, 2023 at 02:31:21PM +0200 schrieb Michael Biebl: Hello Michael, thank you very much for the feedback. I have added replies inline. > On Fri, 30 Jun 2023 19:04:59 +0200 Christoph Brinkhaus > wrote: > > Package: systemd > > Version: 252.6-1 > > Severity: wishlist > > > > Dear Maintainer, > > > > I tried to disable systemd-gpt-auto-generator because I do not need it. > > man 8 systemd-gpt-auto-generator documents the necessary kernel > > parameter in the section "KERNEL COMMAND LINE" which is at the bottom of > > the man page. > > > > Incorrect is the original: > > Those options take an optional boolean argument, and default to yes. The > > generator is enabled by default, and a negative value may > > be used to disable it. > > > > That did not work. Correct is > > Those options take an optional boolean argument, and default to yes. The > > generator is enabled by default, "no" may > > be used to disable it. > > systemd-gpt-auto-generator uses the parse_boolean() function, which > interprets the following values as false [1]: > > >"0", >"no", >"n", >"false", >"f", >"off" > > > With "negative value", any of those strings is meant. > So changing the documentation as per your suggestion would be incomplete. > > I suppose, with "negative value", you understood a negative *integer* value, > like say -1? You are right, this is what I have expected to be ok according to the documentation. Due to your explanation I have found man systemd.syntax which explaines that kind of things. > > I do not have a better suggestion how to phrase it and in any case, this > should be addressed upstream. > I kindly ask you to raise this at https://github.com/systemd/systemd/issues > (maybe you have an idea how the documentation can be improved). I have raised an issue as https://github.com/systemd/systemd/issues/28928 My suggestion is to change "negative value" to "negative string". > > Running a > # grep boolean man/ -R > > shows that the documentation is not really consistent in that regard. > Sometimes it uses, true, yes, false, no, etc. > > Regards, > Michael > > [1] For completeness sake, the corresponding positive values are > >"1", >"yes", >"y", >"true", >"t", >"on" I think it is not easy to maintain the documentation of such a huge project. Kind regards, Christoph signature.asc Description: PGP signature
Bug#1050256: autopkgtest fails on debci
Source: systemd Version: 254.1-2 Severity: important Looking at https://ci.debian.net/packages/s/systemd/unstable/amd64/ , systemd has been failing on debci since about the beginning of May. Asking around on #debci, this might be kernel related, as the debci related systems were upgraded to bookworm around that time.
Bug#1003835: marked as done (udev: XEN domU: Guest RX stalled, unreachable due to nw device naming change)
Your message dated Tue, 22 Aug 2023 15:50:20 +0200 with message-id <3a970a8d-f5e7-4bfc-914d-1517a9104...@debian.org> and subject line Re: Bug#1003835: udev: XEN domU: Guest RX stalled, unreachable due to nw device naming change has caused the Debian Bug report #1003835, regarding udev: XEN domU: Guest RX stalled, unreachable due to nw device naming change to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1003835: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003835 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: udev Version: 250.2-3 Severity: important X-Debbugs-Cc: f.odenkirc...@gmx.net Dear Maintainer, -- Package-specific info: -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/2 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages udev depends on: ii adduser 3.118 ii libacl1 2.3.1-1 ii libblkid12.37.2-6 ii libc62.33-2 ii libcap2 1:2.44-1 ii libkmod2 29-1 ii libselinux1 3.3-1+b1 ii libudev1 250.2-3 ii util-linux 2.37.2-6 udev recommends no packages. udev suggests no packages. Versions of packages udev is related to: ii systemd 250.2-3 -- no debconf information Dear all, I'm running a stock Debian SID vm on xen, hostname "vm-sid". Dom0 is on stock Debian Bullseye, providing a virtual bridge for networking the VMs. apt updating several packages on domU on 2022-01-13 08:11:00 UTC rendered vm-sid unaccessible over network upon reboot. log messages on dom0: 12:36:35 felix: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/18/0 12:36:35 kernel: [2348158.091840] xenbr0: port 4(vif18.0) entered blocking state 12:36:35 kernel: [2348158.091846] xenbr0: port 4(vif18.0) entered disabled state 12:36:35 kernel: [2348158.091991] device vif18.0 entered promiscuous mode 12:36:35 felix: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif18.0, bridge xenbr0.11:58:39 12:37:14 kernel: [2348197.078134] vif vif-18-0 vif18.0: Guest Rx ready 12:37:14 kernel: [2348197.078164] IPv6: ADDRCONF(NETDEV_CHANGE): vif18.0: link becomes ready 12:37:14 kernel: [2348197.078235] xenbr0: port 4(vif18.0) entered blocking state 12:37:14 kernel: [2348197.078238] xenbr0: port 4(vif18.0) entered forwarding state 12:38:49 kernel: [2348292.051684] vif vif-18-0 vif18.0: Guest Rx stalled 12:38:49 kernel: [2348292.051759] xenbr0: port 4(vif18.0) entered disabled state Workaround: After logging into the vm using 'xl console 18', interface could be identified by 'sudo ip a' and manually brought up using 'sudo ip link set enX0 up'. ROOT CAUSE: udev package changed the naming of the primary network device on a XEN domU from "eth0" to "enX0". Since /etc/network/interfaces is not updated, nw interface is not automatically brought up anymore, rendering the vm unreachable. POSSIBLE FIX: devise a postinst script that (1) checks whether updated udev will change the name of the networking device, and (2) updates /etc/ntework/interfaces accordingly. P: /devices/breakpoint L: 0 E: DEVPATH=/devices/breakpoint E: SUBSYSTEM=event_source P: /devices/kprobe L: 0 E: DEVPATH=/devices/kprobe E: SUBSYSTEM=event_source P: /devices/msr L: 0 E: DEVPATH=/devices/msr E: SUBSYSTEM=event_source P: /devices/platform/intel_rapl_msr.0 L: 0 E: DEVPATH=/devices/platform/intel_rapl_msr.0 E: SUBSYSTEM=platform E: MODALIAS=platform:intel_rapl_msr E: USEC_INITIALIZED=36691826 E: ID_PATH=platform-intel_rapl_msr.0 E: ID_PATH_TAG=platform-intel_rapl_msr_0 P: /devices/platform/pcspkr L: 0 E: DEVPATH=/devices/platform/pcspkr E: SUBSYSTEM=platform E: DRIVER=pcspkr E: MODALIAS=platform:pcspkr E: USEC_INITIALIZED=31461564 E: ID_PATH=platform-pcspkr E: ID_PATH_TAG=platform-pcspkr P: /devices/platform/pcspkr/input/input2 L: 0 E: DEVPATH=/devices/platform/pcspkr/input/input2 E: SUBSYSTEM=input E: PRODUCT=10/1f/1/100 E: NAME="PC Speaker" E: PHYS="isa0061/input0" E: PROP=0 E: EV=40001 E: SND=6 E: MODALIAS=input:b0010v001Fp0001e0100-e0,12,kramls1,2,fw E: USEC_INITIALIZED=33422238 E: ID_INPUT=1 E: ID_SERIAL=noserial E: ID_PATH=platform-pcspkr E: ID_PATH_TAG=platform-pcspkr E: ID_FOR_SEAT=input-platform-pcspkr E: TAGS=:seat: E: CURRENT_TAGS=:seat: P: /devices/platform/pcspkr/input/input2/event2 N: input/event2 L: 0 S:
Bug#1038994: marked as done (Upgrading systemd stopped GNOME session)
Your message dated Tue, 22 Aug 2023 15:45:14 +0200 with message-id <1764c540-c896-43d0-b3a3-d0010551f...@debian.org> and subject line Re: Bug#1038994: Upgrading systemd stopped GNOME session has caused the Debian Bug report #1038994, regarding Upgrading systemd stopped GNOME session to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1038994: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038994 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 253-3 Severity: important X-Debbugs-Cc: j...@joshtriplett.org I'm not entirely sure which package this bug belongs to, but it happened when upgrading systemd, and systemd is my best guess here. Please feel free to reassign. When upgrading to systemd 253-3, my GNOME session restarted. From the logs: Jun 24 00:24:07 o systemd[1]: Reloading. Jun 24 00:24:07 o systemd[1]: /lib/systemd/system/systemd-udevd.service:21: Failed to parse service type, ignoring: notify-reload Jun 24 00:24:07 o systemd[1]: /lib/systemd/system/systemd-logind.service:63: Failed to parse service type, ignoring: notify-reload Jun 24 00:24:07 o systemd[1]: /lib/systemd/system/systemd-networkd.service:50: Failed to parse service type, ignoring: notify-reload Jun 24 00:24:07 o systemd[1]: /lib/systemd/system/user@.service:20: Failed to parse service type, ignoring: notify-reload Jun 24 00:24:07 o systemd[1]: Stopping systemd-udevd.service - Rule-based Manager for Device Events and Files... Jun 24 00:24:07 o systemd[1]: systemd-udevd.service: Deactivated successfully. Jun 24 00:24:07 o systemd[1]: Stopped systemd-udevd.service - Rule-based Manager for Device Events and Files. Jun 24 00:24:07 o systemd[1]: systemd-udevd.service: Consumed 7.243s CPU time. Jun 24 00:24:07 o systemd[1]: Started systemd-udevd.service - Rule-based Manager for Device Events and Files. Jun 24 00:24:07 o systemd[1]: Reloading. ... Jun 24 00:24:10 o systemd[1]: Reloading requested from client PID 237159 (unit user@1000.service)... ... Jun 24 00:24:48 o gdm-autologin][824]: pam_unix(gdm-autologin:session): session closed for user josh Jun 24 00:24:48 o systemd[840]: Stopped target gnome-session-wayland@gnome.target - GNOME Wayland Session (session: gnome). Jun 24 00:24:48 o systemd[840]: Stopped target graphical-session.target - Current graphical user session. Jun 24 00:24:48 o systemd[840]: Stopped target gnome-session.target - GNOME Session. Jun 24 00:24:48 o systemd[840]: Stopped target gnome-session-wayland.target - GNOME Wayland Session. Jun 24 00:24:48 o systemd[840]: Stopped target gnome-session@gnome.target - GNOME Session (session: gnome). ... I'm wondering if this might have happened because /lib/systemd/system/user@.service was changed (to use notify-reload, as indicated in the above log messages)? Yes, I'm aware of the general guidance to do upgrades from within a screen/tmux/etc session or similar. However, ordinarily upgrading systemd does not result in killing the whole session. -- Package-specific info: -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii libacl12.3.1-3 ii libaudit1 1:3.0.9-1 ii libblkid1 2.38.1-5+b1 ii libc6 2.36-9 ii libcap21:2.66-4 ii libcryptsetup122:2.6.1-4 ii libfdisk1 2.38.1-5+b1 ii libgcrypt201.10.2-2 ii libkmod2 30+20230519-1 ii liblz4-1 1.9.4-1 ii liblzma5 5.4.1-0.2 ii libmount1 2.38.1-5+b1 ii libp11-kit00.24.1-2 ii libseccomp22.5.4-1+b3 ii libselinux13.4-1+b6 ii libssl33.0.9-1 ii libsystemd-shared 253-3 ii libsystemd0253-3 ii libzstd1 1.5.4+dfsg2-5 ii mount 2.38.1-5+b1 ii systemd-dev253-3 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.14.8-1 ii systemd-timesyncd [time-daemon] 253-3 Versions of packages systemd suggests: ii libfido2-11.13.0-1 ii libqrencode4 4.1.1-1 ii libtss2-esys-3.0.2-0 3.2.1-3 ii libtss2-mu0 3.2.1-3 pn libtss2-rc0 ii policykit-1 122-4 ii polkitd 122-4 pn systemd-boot pn systemd-container
Delivery report
Hello, this is the mail server on mail0.boschrexroth-us.com. I am sending you this message to inform you on the delivery status of a message you previously sent. Immediately below you will find a list of the affected recipients; also attached is a Delivery Status Notification (DSN) report in standard format, as well as the headers of the original message. delivery failed; will not continue trying Reporting-MTA: dns;mail0.boschrexroth-us.com X-PowerMTA-VirtualMTA: pmta-vmta0 Received-From-MTA: dns;cofely.de (45.77.9.181) Arrival-Date: Tue, 22 Aug 2023 07:49:55 -0500 Final-Recipient: rfc822;pkg-systemd-maintainers@lists.alioth.debian.org Action: failed Status: 5.0.0 (undefined status) Remote-MTA: dns;alioth-lists-mx.debian.net (185.73.44.171) Diagnostic-Code: smtp;550 This message has been identified as spam (scored 8.3). Please contact postmaster if you feel this is in error. X-PowerMTA-BounceCategory: spam-related From: Cpanel Mail To: pkg-systemd-maintain...@lists.alioth.debian.org Subject: Cpanel Notification !!! Date: 22 Aug 2023 12:49:54 + Message-ID: <20230822124954.ee036e9273c04...@lists.alioth.debian.org> MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Bug#1039987: systemd-gpt-auto-generator(8) - wrong instruction how to disable
On Fri, 30 Jun 2023 19:04:59 +0200 Christoph Brinkhaus wrote: Package: systemd Version: 252.6-1 Severity: wishlist Dear Maintainer, I tried to disable systemd-gpt-auto-generator because I do not need it. man 8 systemd-gpt-auto-generator documents the necessary kernel parameter in the section "KERNEL COMMAND LINE" which is at the bottom of the man page. Incorrect is the original: Those options take an optional boolean argument, and default to yes. The generator is enabled by default, and a negative value may be used to disable it. That did not work. Correct is Those options take an optional boolean argument, and default to yes. The generator is enabled by default, "no" may be used to disable it. systemd-gpt-auto-generator uses the parse_boolean() function, which interprets the following values as false [1]: "0", "no", "n", "false", "f", "off" With "negative value", any of those strings is meant. So changing the documentation as per your suggestion would be incomplete. I suppose, with "negative value", you understood a negative *integer* value, like say -1? I do not have a better suggestion how to phrase it and in any case, this should be addressed upstream. I kindly ask you to raise this at https://github.com/systemd/systemd/issues (maybe you have an idea how the documentation can be improved). Running a # grep boolean man/ -R shows that the documentation is not really consistent in that regard. Sometimes it uses, true, yes, false, no, etc. Regards, Michael [1] For completeness sake, the corresponding positive values are "1", "yes", "y", "true", "t", "on" OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#843256: marked as done (systemd: man systemd-resolved refers to /usr/lib/systemd/resolv.conf instead of /lib/systemd/resolv.conf)
Your message dated Tue, 22 Aug 2023 14:11:19 +0200 with message-id and subject line Re: systemd: man systemd-resolved refers to /usr/lib/systemd/resolv.conf instead of /lib/systemd/resolv.conf has caused the Debian Bug report #843256, regarding systemd: man systemd-resolved refers to /usr/lib/systemd/resolv.conf instead of /lib/systemd/resolv.conf to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 843256: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843256 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 231-9 Severity: normal man systemd-resolved mentions the file /usr/lib/systemd/resolv.conf , however this file is installed as /lib/systemd/resolv.conf. -- Package-specific info: -- System Information: Debian Release: stretch/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (300, 'testing'), (250, 'stable'), (200, 'unstable'), (160, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3 ii libapparmor12.10.95-5 ii libaudit1 1:2.6.7-1 ii libblkid1 2.28.2-1 ii libc6 2.24-5 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.2-5 ii libgcrypt20 1.7.3-2 ii libgpg-error0 1.24-1 ii libidn111.33-1 ii libip4tc0 1.6.0-4 ii libkmod222-1.1 ii liblzma55.2.2-1.2 ii libmount1 2.28.2-1 ii libpam0g1.1.8-3.3 ii libseccomp2 2.3.1-2 ii libselinux1 2.6-1 ii libsystemd0 231-9 ii mount 2.28.2-1 ii util-linux 2.28.2-1 Versions of packages systemd recommends: ii dbus1.10.12-1 ii libpam-systemd 231-9 Versions of packages systemd suggests: ii policykit-10.105-17 pn systemd-container ii systemd-ui 3-4 Versions of packages systemd is related to: ii udev 231-9 -- no debconf information --- End Message --- --- Begin Message --- On Sat, 05 Nov 2016 15:45:13 +0100 Frederik Himpe wrote: Package: systemd Version: 231-9 Severity: normal man systemd-resolved mentions the file /usr/lib/systemd/resolv.conf , however this file is installed as /lib/systemd/resolv.conf. With merged-usr now being mandatory, I think we can safely close this bug report. At some point we should also consider dropping https://salsa.debian.org/systemd-team/systemd/-/blame/debian/master/debian/rules#L172 (possibly once the merged-usr transition is done). @bluca ^ Michael OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message ---
Processed: Re: Bug#1033725: systemd-boot: Sign systemd-boot with Debian Secure Boot CA
Processing control commands: > tags -1 + wontfix Bug #1033725 [systemd-boot] systemd-boot: Sign systemd-boot with Debian Secure Boot CA Added tag(s) wontfix. -- 1033725: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033725 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1033725: systemd-boot: Sign systemd-boot with Debian Secure Boot CA
Control: tags -1 + wontfix On Fri, 31 Mar 2023 09:18:41 +0200 Michael Biebl wrote: Am 31.03.23 um 07:58 schrieb Gihun Nam: > Package: systemd-boot > Severity: wishlist > X-Debbugs-Cc: gihun...@proton.me > > Dear Maintainer, > > Please, sign /usr/lib/systemd/boot/efi/systemd-bootx64.efi with Debian Secure Boot CA > (or maybe create systemd-bootx64.efi.signed) so that systemd-boot can be used with > UEFI Secure Boot and shim out of the box. > > Debian provides systemd-boot but does not sign it with a Debian key. > To use systemd-boot with shim, one needs to enroll its hash with MokManager. > Although systemd-boot is not an official bootloader of Debian, > signing it would be handy to people using systemd-boot and Secure Boot with Debian. We would love too, but this is not in the hands of the systemd(-boot) maintainers. Please see https://salsa.debian.org/systemd-team/systemd/-/merge_requests/132 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202 Since this is not actionable for us at this point, I'm marking the bug as wontfix. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: bug 1050098 is forwarded to https://github.com/systemd/systemd/issues/21368, tagging 1050098 ...
Processing commands for cont...@bugs.debian.org: > forwarded 1050098 https://github.com/systemd/systemd/issues/21368 Bug #1050098 [systemd] systemd: Using systemd-networkd as DHCP server static leases are ignored Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/21368'. > tags 1050098 + fixed-upstream Bug #1050098 [systemd] systemd: Using systemd-networkd as DHCP server static leases are ignored Added tag(s) fixed-upstream. > fixed 1050098 254-1 Bug #1050098 [systemd] systemd: Using systemd-networkd as DHCP server static leases are ignored Marked as fixed in versions systemd/254-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1050098: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050098 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1038994: Upgrading systemd stopped GNOME session
On Tue, Aug 22, 2023 at 11:19:56AM +0200, Michael Biebl wrote: > Control: tags -1 + moreinfo unreproducible > > Hi Josh > > Am 24.06.23 um 10:03 schrieb Josh Triplett: > > Package: systemd > > I'm not entirely sure which package this bug belongs to, but it happened > > when upgrading systemd, and systemd is my best guess here. Please feel > > free to reassign. > > > > When upgrading to systemd 253-3, my GNOME session restarted. From the > > logs: > > ... > > I distupgraded a test-vm running GNOME/Wayland from bookworm to trixie but > couldn't trigger the failure. > > Can you still reproduce the issue? And if so, provide steps how we can > reproduce it ourselves? I can give you the exact set of package upgrades performed in the same run, which might help: === Aptitude 0.8.13: log report Sat, Jun 24 2023 00:19:49 -0700 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 115 packages, and remove 1 packages. 906 kB of disk space will be used [REMOVE, NOT USED] libmujs2:amd64 1.3.2-1 [INSTALL, DEPENDENCIES] fonts-liberation:amd64 1:2.1.5-2 [INSTALL, DEPENDENCIES] libmujs3:amd64 1.3.3-1+b1 [INSTALL, DEPENDENCIES] systemd-dev:amd64 253-3 [UPGRADE] bind9-dnsutils:amd64 1:9.18.13-1 -> 1:9.18.16-1 [UPGRADE] bind9-host:amd64 1:9.18.13-1 -> 1:9.18.16-1 [UPGRADE] bind9-libs:amd64 1:9.18.13-1 -> 1:9.18.16-1 [UPGRADE] binutils:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1 [UPGRADE] binutils-aarch64-linux-gnu:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1 [UPGRADE] binutils-common:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1 [UPGRADE] binutils-multiarch:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1 [UPGRADE] binutils-x86-64-linux-gnu:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1 [UPGRADE] build-essential:amd64 12.9 -> 12.10 [UPGRADE] coinor-libcbc3:amd64 2.10.8+ds1-1 -> 2.10.10+ds1-1 [UPGRADE] cpp:amd64 4:12.2.0-3 -> 4:12.3.0-1 [UPGRADE] cpp-aarch64-linux-gnu:amd64 4:12.2.0-3 -> 4:12.3.0-1 [UPGRADE] crossbuild-essential-arm64:amd64 12.9 -> 12.10 [UPGRADE] cups:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] cups-bsd:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] cups-client:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] cups-common:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] cups-core-drivers:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] cups-daemon:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] cups-ipp-utils:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] cups-ppdc:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] cups-server-common:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] dash:amd64 0.5.12-5 -> 0.5.12-6 [UPGRADE] enscript:amd64 1.6.5.90-3+b1 -> 1.6.5.90-3.1 [UPGRADE] fonts-liberation2:amd64 2.1.5-1 -> 1:2.1.5-2 [UPGRADE] g++:amd64 4:12.2.0-3 -> 4:12.3.0-1 [UPGRADE] g++-aarch64-linux-gnu:amd64 4:12.2.0-3 -> 4:12.3.0-1 [UPGRADE] gcc:amd64 4:12.2.0-3 -> 4:12.3.0-1 [UPGRADE] gcc-aarch64-linux-gnu:amd64 4:12.2.0-3 -> 4:12.3.0-1 [UPGRADE] ghostscript:amd64 10.0.0~dfsg-11 -> 10.01.2~dfsg-1 [UPGRADE] gvfs:amd64 1.50.4-2 -> 1.50.4-3 [UPGRADE] gvfs-backends:amd64 1.50.4-2 -> 1.50.4-3 [UPGRADE] gvfs-common:amd64 1.50.4-2 -> 1.50.4-3 [UPGRADE] gvfs-daemons:amd64 1.50.4-2 -> 1.50.4-3 [UPGRADE] gvfs-fuse:amd64 1.50.4-2 -> 1.50.4-3 [UPGRADE] gvfs-libs:amd64 1.50.4-2 -> 1.50.4-3 [UPGRADE] libaom3:amd64 3.6.0-1 -> 3.6.1-1 [UPGRADE] libbinutils:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1 [UPGRADE] libboost-filesystem1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1 [UPGRADE] libboost-iostreams1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1 [UPGRADE] libboost-locale1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1 [UPGRADE] libboost-regex1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1 [UPGRADE] libboost-thread1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1 [UPGRADE] libctf-nobfd0:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1 [UPGRADE] libctf0:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1 [UPGRADE] libcups2:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] libcupsimage2:amd64 2.4.2-4 -> 2.4.2-5 [UPGRADE] libdata-optlist-perl:amd64 0.113-1 -> 0.114-1 [UPGRADE] libde265-0:amd64 1.0.11-1 -> 1.0.12-1 [UPGRADE] libdrm-amdgpu1:amd64 2.4.114-1+b1 -> 2.4.115-1 [UPGRADE] libdrm-common:amd64 2.4.114-1 -> 2.4.115-1 [UPGRADE] libdrm-intel1:amd64 2.4.114-1+b1 -> 2.4.115-1 [UPGRADE] libdrm-nouveau2:amd64 2.4.114-1+b1 -> 2.4.115-1 [UPGRADE] libdrm-radeon1:amd64 2.4.114-1+b1 -> 2.4.115-1 [UPGRADE] libdrm2:amd64 2.4.114-1+b1 -> 2.4.115-1 [UPGRADE] libfribidi0:amd64 1.0.13-2 -> 1.0.13-3 [UPGRADE] libgprofng0:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1 [UPGRADE] libgs-common:amd64 10.0.0~dfsg-11 -> 10.01.2~dfsg-1 [UPGRADE] libgs10:amd64 10.0.0~dfsg-11 -> 10.01.2~dfsg-1 [UPGRADE] libgs10-common:amd64 10.0.0~dfsg-11 -> 10.01.2~dfsg-1 [UPGRADE] libijs-0.35:amd64 0.35-15 -> 0.35-15.1 [UPGRADE] libldb2:amd64 2:2.7.2+samba4.18.3+dfsg-2 -> 2:2.7.2+samba4.18.3+dfsg-3 [UPGRADE] libnftables1:amd64 1.0.7-1 -> 1.0.7-2 [UPGRADE] libnss3:amd64 2:3.89-2 -> 2:3.90-3 [UPGRADE]
Bug#1033569: marked as done (systemd-boot-efi: Secure Boot via shim broken on arm64 due to missing SBAT section)
Your message dated Tue, 22 Aug 2023 11:53:02 +0200 with message-id and subject line Re: Bug#1033569: systemd-boot-efi: Secure Boot via shim broken on arm64 due to missing SBAT section has caused the Debian Bug report #1033569, regarding systemd-boot-efi: Secure Boot via shim broken on arm64 due to missing SBAT section to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1033569: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033569 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd-boot-efi Version: 252.6-1 Hi, booting in Secure Boot mode with a self-signed systemd-bootaa64.efi works well on arm64. However, trying to boot via shimaa64.efi fails with the following error: shim.c:866:load_image() attempting to load \EFI\BOOT\grubaa64.efi pe.c:844:verify_sbat_section() No .sbat section data Verification failed: Security Policy Violation Looking for the SBAT section in systemd-bootaa64.efi confirms that indeed it is missing: objdump -x /usr/lib/systemd/boot/efi/systemd-bootaa64.efi | grep .sbat # <- no output Instead, on amd64: $ objdump -x /usr/lib/systemd/boot/efi/systemd-bootx64.efi | grep .sbat 7 .sbat 00d9 00028040 00028040 0001dc00 2**2 [136](sec 8)(fl 0x00)(ty0)(scl 3) (nx 0) 0x sbat Note that .sbat is not the only section missing. On arm64 there's only .text and .data: Sections: Idx Name Size VMA LMA File off Algn 0 .text 0001a000 1000 1000 1000 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 2000 0001b000 0001b000 0001b000 2**2 CONTENTS, ALLOC, LOAD, DATA While amd64 has: Sections: Idx Name Size VMA LMA File off Algn 0 .text 00015710 5000 5000 0400 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .reloc000c 0001b000 0001b000 00015c00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .data 64b8 0001c000 0001c000 00015e00 2**4 CONTENTS, ALLOC, LOAD, DATA 3 .dynamic 0100 00023000 00023000 0001c400 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .rela 1038 00024000 00024000 0001c600 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .dynsym 0018 00026000 00026000 0001d800 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .sdmagic 002b 00028000 00028000 0001da00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .sbat 00d9 00028040 00028040 0001dc00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 8 .osrel003f 00028120 00028120 0001de00 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA --- End Message --- --- Begin Message --- Version: 254-1 On Fri, 31 Mar 2023 09:12:52 +0200 Michael Biebl wrote: Control: tags -1 + fixed-upstream Am 28.03.23 um 20:46 schrieb Emanuele Rocca: > Hi, > > On Mon, Mar 27, 2023 at 06:23:57PM +0200, Michael Biebl wrote: >> Please consider raising this issue upstream > > There's no need, the bug is fixed in main (currently at 3a051522). Ah nice, good to know. Marking accordingly > It is however reproducible checking out tag v253, so presumably upstream > version v254 will be the first release fixing this. > > I see that there's been quite some work in the area, eg. commit 2afeaf16. Yeah, the way systemd-boot is built has been reworked completely. Closing this issue for v254. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#959840: marked as done (dbus-daemon: random crash (SIGABRT))
Your message dated Tue, 22 Aug 2023 11:42:25 +0200 with message-id and subject line Re: dbus-daemon: random crash (SIGABRT) has caused the Debian Bug report #959840, regarding dbus-daemon: random crash (SIGABRT) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 959840: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959840 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: dbus Version: 1.12.16-2 Severity: normal File: /usr/bin/dbus-daemon Usertags: crash The last few days I have been getting dbus-daemon crashing randomly with SIGABRT. I don't know how to reproduce this, so if the below backtrace isn't useful, please close this bug. $ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'bt full' -ex 'thread apply all bt full' --core /var/crash/1000/490277-1000-1000-6-1588644032-chianamo--usr-bin-dbus-daemon.core /usr/bin/dbus-daemon [New LWP 490277] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 --ses'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x7f1d488a455b in __GI_abort () at abort.c:79 #2 0x7f1d485d17ea in log_assert_failed_realm (realm=, text=0x7f1d485fa7be "fclose_nointr(f) != -EBADF", file=0x7f1d485fa3e9 "src/basic/fd-util.c", line=121, func=0x7f1d485faff8 <__PRETTY_FUNCTION__.10669> "safe_fclose") at ../src/basic/log.c:809 #3 0x7f1d485f0c79 in safe_fclose (f=) at ../src/basic/fd-util.c:121 #4 safe_fclose (f=0x55c3577d4610) at ../src/basic/fd-util.c:114 #5 0x7f1d485db359 in fclosep (f=) at ../src/basic/fd-util.h:41 #6 json_variant_format (ret=, flags=(unknown: 0), v=) at ../src/shared/json.c:1732 #7 varlink_enqueue_json (v=0x55c3577d34e0, m=) at ../src/shared/varlink.c:1233 #8 0x7f1d485e08f6 in varlink_observe (parameters=, method=0x7f1d485f92f0 "io.systemd.UserDatabase.GetMemberships", v=0x55c3577d34e0) at ../src/shared/varlink.c:1404 #9 userdb_connect (iterator=iterator@entry=0x55c3577c2a70, path=path@entry=0x55c3577cb210 "/run/systemd/userdb/io.systemd.DynamicUser", method=method@entry=0x7f1d485f92f0 "io.systemd.UserDatabase.GetMemberships", more=more@entry=true, query=) at ../src/shared/userdb.c:356 #10 0x7f1d485e6a5e in userdb_start_query (iterator=0x55c3577c2a70, method=0x7f1d485f92f0 "io.systemd.UserDatabase.GetMemberships", more=true, query=0x55c3577cb250, flags=USERDB_AVOID_NSS) at ../src/shared/userdb.c:469 #11 0x7f1d485f29d5 in membershipdb_by_user (ret=, flags=, name=0x55c3577ca660 "pabs") at ../src/shared/userdb.c:997 #12 _nss_systemd_initgroups_dyn (user_name=user_name@entry=0x55c3577ca660 "pabs", gid=gid@entry=1000, start=start@entry=0x7fffd3dcba20, size=size@entry=0x7fffd3dcba78, groupsp=groupsp@entry=0x7fffd3dcba80, limit=limit@entry=-1, errnop=0x7f1d4864d6a0) at ../src/nss-systemd/nss-systemd.c:561 #13 0x7f1d48946056 in internal_getgrouplist (user=user@entry=0x55c3577ca660 "pabs", group=group@entry=1000, size=size@entry=0x7fffd3dcba78, groupsp=groupsp@entry=0x7fffd3dcba80, limit=limit@entry=-1) at initgroups.c:111 #14 0x7f1d489462b9 in getgrouplist (user=user@entry=0x55c3577ca660 "pabs", group=group@entry=1000, groups=groups@entry=0x55c3577ca6a0, ngroups=ngroups@entry=0x7fffd3dcbaf0) at initgroups.c:169 #15 0x7f1d48be7eae in fill_user_info (info=info@entry=0x55c3577c8120, uid=uid@entry=1000, username=username@entry=0x0, error=error@entry=0x7fffd3dcbbe0) at ../../../dbus/dbus-sysdeps-unix.c:2548 #16 0x7f1d48be808a in _dbus_user_info_fill_uid (info=info@entry=0x55c3577c8120, uid=uid@entry=1000, error=error@entry=0x7fffd3dcbbe0) at ../../../dbus/dbus-sysdeps-unix.c:2672 #17 0x7f1d48beba4a in _dbus_user_database_lookup (db=0x55c3577c7e30, uid=, username=username@entry=0x0, error=error@entry=0x7fffd3dcbbe0) at ../../../dbus/dbus-userdb.c:176 #18 0x7f1d48bebc8b in _dbus_user_database_get_uid (db=, uid=, info=info@entry=0x7fffd3dcbbd8, error=error@entry=0x7fffd3dcbbe0) at ../../../dbus/dbus-userdb.c:672 #19 0x7f1d48bebcfa in init_system_db () at ../../../dbus/dbus-userdb.c:247 #20 0x7f1d48bebefd in init_system_db () at ../../../dbus/dbus-userdb.c:408 #21 _dbus_homedir_from_current_process (homedir=homedir@entry=0x7fffd3dcbc48) at ../../../dbus/dbus-userdb.c:400 #22
Bug#1037559: systemd-networkd-wait-online waits undefinitely if no networkd managed interfaces
Since upstream(systemd) take it as a bug, I think it also can be patch into current stable package. Please ask on the upstream bug tracker for a stable backport for v252-stable. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: fixed 1037559 in 253-1, tagging 1037559 ...
Processing commands for cont...@bugs.debian.org: > fixed 1037559 253-1 Bug #1037559 [systemd] systemd-networkd-wait-online waits undefinitely if no networkd managed interfaces Marked as fixed in versions systemd/253-1. > tags 1037559 + fixed-upstream Bug #1037559 [systemd] systemd-networkd-wait-online waits undefinitely if no networkd managed interfaces Added tag(s) fixed-upstream. > forwarded 1037559 https://github.com/systemd/systemd/issues/25813 Bug #1037559 [systemd] systemd-networkd-wait-online waits undefinitely if no networkd managed interfaces Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/25813'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1037559: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037559 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: tagging 1037559
Processing commands for cont...@bugs.debian.org: > tags 1037559 - newcomer Bug #1037559 [systemd] systemd-networkd-wait-online waits undefinitely if no networkd managed interfaces Removed tag(s) newcomer. > thanks Stopping processing here. Please contact me if you need assistance. -- 1037559: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037559 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1028417: marked as done (udev deletes symlink to a device according to a rule and then deletes it as "no longer belonging to this device")
Your message dated Tue, 22 Aug 2023 11:25:15 +0200
with message-id <933acc69-acd9-43a7-b2e3-14f983e7e...@debian.org>
and subject line Re: udev deletes symlink to a device according to a rule and
then deletes it as "no longer belonging to this device"
has caused the Debian Bug report #1028417,
regarding udev deletes symlink to a device according to a rule and then deletes
it as "no longer belonging to this device"
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1028417: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028417
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: udev
Version: 252.4-1
Severity: important
I have encountered an issue with `udev` after upgrade from the latest Ubuntu
Impish (the issue was not experienced on it). A symlink defined in the rules
for device is not visible. The investigation has shown that it was created and
then deleted by `udev`.
When the rule of the form `ATTR{idVendor}=="VID", ATTR{idProduct}=="PID",
SYMLINK+="symlink_name-%n", MODE="0666"` is used, the following records apper
in the log
```
Successfully created symlink '/dev/symlink_name-2' to '/dev/bus/usb/XXX/YYY'
...
Removing/updating old device symlink '/dev/symlink_name-2', which is no longer
belonging to this device.
No reference left for '/dev/symlink_name-2', removing
```
Notice the number 2. Why is it using 2, where is 1, there is no `
/dev/symlink_name-1` ? Only one physical device of the same type is connected
to the PC.
The problem has encountered with a USB device emulating a serial port (I
haven't investigated which chip is used internally), but since you likely have
no such device, I have rewritten the rule to be used
against any widespread trash-tier flash drive with the identifier abcd:1234
most of you surely have access to.
The issue reproduces on both udev 252.4-1 from testing/unstable and on the one
from stable 247.3-7+deb11u1
In order to test if the issue is caused by kernel, I have tried udev version
252.4-1 on the 9 kernel images (and the corresponding 6 initrds).
From Debian:
```
linux-image-5.10.0-20-amd64/stable,now 5.10.158-2 amd64 [installed]
linux-image-5.18.0-0.deb11.4-amd64/bullseye-backports,now 5.18.16-1~bpo11+1
amd64 [installed]
linux-image-5.19.0-0.deb11.2-amd64/bullseye-backports,now 5.19.11-1~bpo11+1
amd64 [installed]
linux-image-6.0.0-6-amd64/testing,now 6.0.12-1 amd64 [installed]
```
from Ubuntu:
```
linux-image-5.13.0-35-generic/now 5.13.0-35.40~20.04.1 amd64 [installed,local]
linux-image-5.14.0-1055-oem/now 5.14.0-1055.62 amd64 [installed,local]
linux-image-5.15.0-57-generic/now 5.15.0-57.63 amd64 [installed,local]
linux-image-5.17.0-1003-oem/now 5.17.0-1003.3 amd64 [installed,local]
linux-image-5.19.0-21-generic/now 5.19.0-21.21 amd64 [installed,local]
```
The issue reproduces on all of them (including the ones there was no issue on
when I used to be using Ubuntu).
So it is likely that the issue is in udev or in some of its rules and
not in the hardware or kernel.
1. Here is the udev rule (abcd:1234 are the real IDs exposed by some flash
drives)
```
SUBSYSTEM!="usb_device", ACTION!="add", GOTO="test_rules_end"
ATTR{idVendor}=="abcd", ATTR{idProduct}=="1234", SYMLINK+="test_device-%n",
MODE="0666"
LABEL="test_rules_end"
```
2. here are the commands used to reproduce
```
udevadm control --log-priority=debug
journalctl -f | grep systemd-udevd
```
After typing them the flash drive has been attached, then ctrl+c was hit. Here
is the relevant piece of the log (sensitive info was replaces with `censored`,
irrelevant info, like date and time (except seconds), removed).
```
20: 1-1.2: Device is queued (SEQNUM=2845, ACTION=add)
20: 1-1.2: Device ready for processing (SEQNUM=2845, ACTION=add)
20: Successfully forked off 'n/a' as PID 3710.
20: 1-1.2: Worker [3710] is forked for processing SEQNUM=2845.
20: 1-1.2: Device is queued (SEQNUM=2846, ACTION=bind)
20: 1-1.2: SEQNUM=2846 blocked by SEQNUM=2845
20: 1-1.2: Processing device (SEQNUM=2845, ACTION=add)
20: 1-c.e:n.s: Device is queued (SEQNUM=2847, ACTION=add)
20: 1-c.e:n.s: SEQNUM=2847 blocked by SEQNUM=2845
20: 1-1.2: Removing watch handle -1.
20: scsi_tmf_2: Device is queued (SEQNUM=2848, ACTION=add)
20: scsi_tmf_2: Device ready for processing (SEQNUM=2848, ACTION=add)
20: 1-1.2: /usr/lib/udev/rules.d/10-test.rules:13 MODE 0666
20: 1-1.2: /usr/lib/udev/rules.d/10-test.rules:13 LINK 'test_device'
20: Successfully forked off 'n/a' as PID 3711.
20: scsi_tmf_2: Worker [3711] is forked for processing SEQNUM=2848.
20: 1-1.2: /usr/lib/udev/rules.d/50-udev-default.rules:17 Importing properties
Processed: Re: Bug#1038994: Upgrading systemd stopped GNOME session
Processing control commands: > tags -1 + moreinfo unreproducible Bug #1038994 [systemd] Upgrading systemd stopped GNOME session Added tag(s) moreinfo and unreproducible. -- 1038994: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1038994 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1038994: Upgrading systemd stopped GNOME session
Control: tags -1 + moreinfo unreproducible Hi Josh Am 24.06.23 um 10:03 schrieb Josh Triplett: Package: systemd I'm not entirely sure which package this bug belongs to, but it happened when upgrading systemd, and systemd is my best guess here. Please feel free to reassign. When upgrading to systemd 253-3, my GNOME session restarted. From the logs: ... I distupgraded a test-vm running GNOME/Wayland from bookworm to trixie but couldn't trigger the failure. Can you still reproduce the issue? And if so, provide steps how we can reproduce it ourselves? Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#923964: marked as done (systemd-sysv: shutdown should accept a date)
Your message dated Tue, 22 Aug 2023 11:09:31 +0200 with message-id and subject line Re: Bug#923964: systemd-sysv: shutdown should accept a date has caused the Debian Bug report #923964, regarding systemd-sysv: shutdown should accept a date to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 923964: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923964 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd-sysv Version: 241-1 Severity: wishlist Dear Maintainer, Thanks to the diligent effort of people like yourself, my Debian computers usually run without rebooting for months and sometimes even years. But sometimes some external issue, like a scheduled power outage, mandates a clean scheduled shut down. This just happened to me: there is a scheduled power outage at my workplace at 04:00 about two weeks from today, so I need to power down a handful of machines beforehand. Naturally I’d wish to $ sudo shutdown --poweroff '2019-03-19 03:00' But that doesn’t work, shutdown only accepts a time, or a delay in minutes. Instead I end up converting the delay to minutes: $ sudo shutdown --poweroff +$(echo "($(date --date='2019-03-19 03:00' '+%s') - $(date '+%s')) / 60" | bc) Yuck. The shutdown executable (which is just a symlink to systemctl, so in fact already links to date parsing routines) really should take a proper date string. Perhaps this functionality can be accessed with "systemctl poweroff --some-option=TIMESPEC", although I didn’t see it in systemctl(1). It might make sense to add that, either the option or the documentation. It might also make sense for shutdown(1) to mention "systemctl shutdown". --- End Message --- --- Begin Message --- Version: 254-1 On Thu, 7 Mar 2019 22:01:44 +0100 Michael Biebl wrote: Am 07.03.19 um 18:39 schrieb Barak A. Pearlmutter: > Perhaps this functionality can be accessed with "systemctl poweroff > --some-option=TIMESPEC", although I didn’t see it in systemctl(1). It > might make sense to add that, either the option or the documentation. It > might also make sense for shutdown(1) to mention "systemctl shutdown". The current code is at https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c#L8430 Afaics, it provides minimal compatibility with the old, legacy shutdown utility. I can see your use case though. Would you mind filing this upstream as a feature request at https://github.com/systemd/systemd/issues/new/choose systemctl gained a "--when" option in v254 that can be used for shutdown. This option is only available for systemctl, not the legacy "/sbin/shutdown" interface. Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature --- End Message ---
Bug#1033192: Acknowledgement (systemd-resolved - stub resolver does not provide AD by default)
Am 19.03.23 um 12:53 schrieb Bastian Blank: Upstream changed the default for the DNSSEC option to "allow-downgrade" and that is whats everywhere is documented. Debian overrides it to "no". See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959996 Both, Ubuntu and Fedora, which use resolved more extensively, have disabled DNSSEC by default, since it caused too many issues. If the situation has significantly nowadays, I can't tell, but it would probably be a good idea to get input from those downstreams. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: fixed 1039508 in 254-1
Processing commands for cont...@bugs.debian.org: > fixed 1039508 254-1 Bug #1039508 [systemd-boot] systemd-boot: UEFI ZFS boot "Error preparing initrd: Bad Buffer Size" Marked as fixed in versions systemd/254-1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1039508: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039508 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1036949: marked as done (systemd-networkd.service fails with Assertion 'a' failed at src/network/networkd-address.c:1868, function address_is_ready(). Aborting.)
Your message dated Tue, 22 Aug 2023 10:33:24 +0200 with message-id <967e2edc-532f-447d-8b0b-286c0a384...@debian.org> and subject line Re: Bug#1036949: Aw: Re: Bug#1036949: systemd-networkd.service fails with Assertion 'a' failed at src/network/networkd-address.c:1868, function address_is_ready(). Aborting. has caused the Debian Bug report #1036949, regarding systemd-networkd.service fails with Assertion 'a' failed at src/network/networkd-address.c:1868, function address_is_ready(). Aborting. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1036949: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036949 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 247.3-7+deb11u2 Severity: important Hello, systemd-networkd is crashing with the error message systemd-networkd.service fails with Assertion 'a' failed at src/network/networkd-address.c:1868, function address_is_ready(). Aborting. It can be forced into a running state by running "systemctl restart systemd-networkd.service" several times. The following information can be provided to reproduce the issue. OS: Debian 11 systemd version: 247 (247.3-7+deb11u2) Linux kernel version used: 6.1.0-0.deb11.7-amd64 CPU architecture: x86_64 The following error is reported in syslog/journal: May 30 17:28:13 omv6box systemd[1]: Starting Network Service... May 30 17:28:13 omv6box systemd-networkd[10005]: bond0: netdev ready May 30 17:28:13 omv6box systemd-networkd[10005]: vethcdaf262a: Gained IPv6LL May 30 17:28:13 omv6box systemd-networkd[10005]: veth2a72a113: Gained IPv6LL May 30 17:28:13 omv6box systemd-networkd[10005]: Enumeration completed May 30 17:28:13 omv6box systemd[1]: Started Network Service. May 30 17:28:13 omv6box systemd-networkd[10005]: bond0: netdev exists, using existing without changing its parameters May 30 17:28:13 omv6box systemd-networkd[10005]: bond0: DHCPv4 address 192.172.16.165/24 via 192.172.16.1 May 30 17:28:13 omv6box systemd-networkd[10005]: ens6: DHCPv4 address 192.168.121.219/24 via 192.168.121.1 May 30 17:28:13 omv6box systemd-networkd[10005]: Assertion 'a' failed at src/network/networkd-address.c:1868, function address_is_ready(). Aborting. May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Main process exited, code=killed, status=6/ABRT May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Failed with result 'signal'. May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Scheduled restart job, restart counter is at 1. May 30 17:28:13 omv6box systemd[1]: Stopped Network Service. May 30 17:28:13 omv6box systemd[1]: Starting Network Service... May 30 17:28:13 omv6box systemd-networkd[10007]: bond0: netdev ready May 30 17:28:13 omv6box systemd-networkd[10007]: vethcdaf262a: Gained IPv6LL May 30 17:28:13 omv6box systemd-networkd[10007]: veth2a72a113: Gained IPv6LL May 30 17:28:13 omv6box systemd-networkd[10007]: Enumeration completed May 30 17:28:13 omv6box systemd[1]: Started Network Service. May 30 17:28:13 omv6box systemd-networkd[10007]: bond0: netdev exists, using existing without changing its parameters May 30 17:28:13 omv6box systemd-networkd[10007]: bond0: DHCPv4 address 192.172.16.165/24 via 192.172.16.1 May 30 17:28:13 omv6box systemd-networkd[10007]: Assertion 'a' failed at src/network/networkd-address.c:1868, function address_is_ready(). Aborting. May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Main process exited, code=killed, status=6/ABRT May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Failed with result 'signal'. May 30 17:28:13 omv6box systemd[1]: systemd-networkd.service: Scheduled restart job, restart counter is at 2. May 30 17:28:13 omv6box systemd[1]: Stopped Network Service. May 30 17:28:13 omv6box systemd[1]: Starting Network Service... May 30 17:28:13 omv6box systemd-networkd[10008]: bond0: netdev ready May 30 17:28:13 omv6box systemd-networkd[10008]: vethcdaf262a: Gained IPv6LL May 30 17:28:13 omv6box systemd-networkd[10008]: veth2a72a113: Gained IPv6LL May 30 17:28:13 omv6box systemd-networkd[10008]: Enumeration completed May 30 17:28:13 omv6box systemd[1]: Started Network Service. May 30 17:28:13 omv6box systemd-networkd[10008]: bond0: netdev exists, using existing without changing its parameters May 30 17:28:13 omv6box systemd-networkd[10008]: bond0: DHCPv4 address 192.172.16.165/24 via 192.172.16.1 May 30 17:28:13 omv6box systemd-networkd[10008]: ens6: DHCPv4 address 192.168.121.219/24 via 192.168.121.1 May 30 17:28:13 omv6box systemd-networkd[10008]: Assertion 'a' failed at
Bug#1039508: systemd-boot: UEFI ZFS boot "Error preparing initrd: Bad Buffer Size"
On Mon, 26 Jun 2023 15:39:32 -0400 James L Baker wrote: https://github.com/systemd/systemd/issues/25911 Should be fixed in 252.13 (which might be a candidate for the next Debian stable update). Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Processed: bug 1039508 is forwarded to https://github.com/systemd/systemd/issues/25911
Processing commands for cont...@bugs.debian.org: > forwarded 1039508 https://github.com/systemd/systemd/issues/25911 Bug #1039508 [systemd-boot] systemd-boot: UEFI ZFS boot "Error preparing initrd: Bad Buffer Size" Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/25911'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1039508: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039508 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: found 1039508 in 252.12-1~deb12u1
Processing commands for cont...@bugs.debian.org: > found 1039508 252.12-1~deb12u1 Bug #1039508 [systemd-boot] systemd-boot: UEFI ZFS boot "Error preparing initrd: Bad Buffer Size" Marked as found in versions systemd/252.12-1~deb12u1. > thanks Stopping processing here. Please contact me if you need assistance. -- 1039508: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039508 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 1042015 is forwarded to https://github.com/systemd/systemd/issues/28902
Processing commands for cont...@bugs.debian.org: > forwarded 1042015 https://github.com/systemd/systemd/issues/28902 Bug #1042015 [systemd] reboot/poweroff throw errors if dbus/systemd-logind is not running Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/28902'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1042015: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042015 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 1040956 is forwarded to https://github.com/systemd/systemd/issues/28411
Processing commands for cont...@bugs.debian.org: > forwarded 1040956 https://github.com/systemd/systemd/issues/28411 Bug #1040956 [systemd] systemd: Internal USB devices disconnected when `udevadm settle` run in early boot Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/28411'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1040956: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040956 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bug 1050045 is forwarded to https://github.com/systemd/systemd/issues/28901
Processing commands for cont...@bugs.debian.org: > forwarded 1050045 https://github.com/systemd/systemd/issues/28901 Bug #1050045 [systemd] systemd-nspawn fails to start systemd >=253 in QEMU-emulated container Set Bug forwarded-to-address to 'https://github.com/systemd/systemd/issues/28901'. > thanks Stopping processing here. Please contact me if you need assistance. -- 1050045: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050045 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
