Bug#850855: [rtkit] rtkit daemon fails to start

On Fri, 20 Jan 2017 11:38:54 -0300 Felipe Sateler wrote: > Control: tags -1 - unreproducible moreinfo > Control: reassign -1 systemd > Control: affects -1 rtkit > Control: retitle -1 Units with PrivateTmp fail when /var is a symlink > Control: severity -1 normal > > On 12 January 2017 at 04:46, B

Re: Restarts of journald

Am 17.01.2017 um 03:51 schrieb Zbigniew Jędrzejewski-Szmek: > On Sat, Jan 14, 2017 at 06:40:49PM +0100, Jarek Kamiński wrote: >> Hello, >> >> #771122 explains that journald can't be restarted, as all stdout and >> stderr fds used by daemons to log would be lost. If I understand [..] > There were

Bug#854699: Shutdown fails with an encrypted filesystem on virtio device

I've uploaded test packages to https://people.debian.org/~biebl/systemd/stretch/ You can install them by first installing apt-transport-https, then adding to your sources.list: deb [trusted=yes] https://people.debian.org/~biebl/systemd/stretch/ ./ Please report back if those packages fix your

Bug#856337: systemd: please support kernel 4.4, or don't hardcode dm interface versions

I've uploaded test packages to https://people.debian.org/~biebl/systemd/stretch/ You can install them by first installing apt-transport-https, then adding to your sources.list: deb [trusted=yes] https://people.debian.org/~biebl/systemd/stretch/ ./ Please report back if those packages fix your

Re: [Install] for static systemd unit file?

Am 01.03.2017 um 21:51 schrieb Patrick Schleizer: > Michael Biebl: >> Am 01.03.2017 um 21:35 schrieb Patrick Schleizer: >>> Hi! >>> >>> TLDR: >>> >>> How should the [Install] section for static systemd unit file look like? >> >> Th

Re: [Whonix-devel] [Install] for static systemd unit file?

Am 01.03.2017 um 23:58 schrieb Patrick Schleizer: > Michael Biebl: >> Am 01.03.2017 um 21:51 schrieb Patrick Schleizer: >>> Michael Biebl: >>>> Am 01.03.2017 um 21:35 schrieb Patrick Schleizer: >>>>> Hi! >>>>> >>>>> TLDR

Re: [Install] for static systemd unit file?

Am 01.03.2017 um 21:51 schrieb Patrick Schleizer: > Michael Biebl: >> Am 01.03.2017 um 21:35 schrieb Patrick Schleizer: >>> Hi! >>> >>> TLDR: >>> >>> How should the [Install] section for static systemd unit file look like? >> >> Th

Re: [Install] for static systemd unit file?

Am 01.03.2017 um 21:35 schrieb Patrick Schleizer: > Hi! > > TLDR: > > How should the [Install] section for static systemd unit file look like? The obvious question is: why does this service need to be statically enabled? -- Why is it that all of the instruments seeking intelligent life in t

Bug#787028: systemd-cryptsetup@.service fails, although encrypted swap is enabled nevertheless

Am 28.02.2017 um 21:39 schrieb Felipe Sateler: > Control: forwarded -1 https://github.com/systemd/systemd/pull/5480 > > On Thu, 28 May 2015 00:25:49 +0200 Roland Hieber wrote: >> Package: systemd >> Version: 219-10 >> Severity: normal >> >> Dear Maintainers, >> >> I have now the situation that so

Bug#856415: -n (dry-run) seems to be broken completely

Package: init-system-helpers Version: 1.47 Severity: important File: /usr/sbin/update-rc.d update-rc.d -n seems to be broken i.e. ignored completely. I've tested the sysv fallback and the systemd_toggle, but it looks like upstart and insserv are affected as well (no idea about openrc). While fix

Bug#856337: systemd: please support kernel 4.4, or don't hardcode dm interface versions

Am 28.02.2017 um 02:19 schrieb Marc Lehmann: > I upgraded to stretch, using kernel 4.4.47. When rebooting, system could > not clean up device mapper targets, leading to a hard crash for all cache > targets, requiring many hours of heavy I/O after bootup and creating a > high-risk window for data co

Re: Bug#818978: New issues with bridges in Debian Jessie/Stretch

Am 28.02.2017 um 16:49 schrieb Maciej Delmanowski: > On Feb 28, Michael Biebl wrote: >> You can still use "ifdown br0" and "ifup br0" if this an auto interface. >> But I get your point, that then the resulting processes are no longer >> part of networking.

Re: Bug#818978: New issues with bridges in Debian Jessie/Stretch

Am 28.02.2017 um 17:09 schrieb Guus Sliepen: > Maybe it is better to remove the current split between hotplug and other > interfaces, and have everything managed by ifupdown again. But as you > say, the issue then is cgroups, so ifupdown then has to learn to start > its processes in its own dedicat

Re: Bug#818978: New issues with bridges in Debian Jessie/Stretch

Am 28.02.2017 um 16:02 schrieb Maciej Delmanowski: > On Feb 28, Michael Biebl wrote: >>>> allow-hotplug br0 >>> >>> Using allow-hotplug for bridge interfaces is not a good idea. You really >>> should use that for physical hardware only, which actual

Bug#856337: systemd: please support kernel 4.4, or don't hardcode dm interface versions

Control: forwarded -1 https://github.com/systemd/systemd/issues/5492 I've forwarded this upstream. Please followup there if you have further information. Thanks again Christian for your valuable input. -- Why is it that all of the instruments seeking intelligent life in the universe are pointe

Re: Bug#818978: New issues with bridges in Debian Jessie/Stretch

Am 28.02.2017 um 15:02 schrieb Michael Biebl: > Am 28.02.2017 um 14:21 schrieb Maciej Delmanowski: >> Package: systemd >> Version: 215-17+deb8u6 >> Severity: important >> Tags: jessie stretch >> >> It seems that the latest changes in the 'systemd'

Bug#856337: systemd: please support kernel 4.4, or don't hardcode dm interface versions

Am 28.02.2017 um 14:27 schrieb Marc Lehmann: > On Tue, Feb 28, 2017 at 02:25:34AM +0100, Michael Biebl > wrote: >>> The specific error I got was something like (from memory): >>> >>>Could not detach DM dm-11: ioctl mismatch, kernel(4.34.4), user(4.35.4) &

Bug#856337: systemd: please support kernel 4.4, or don't hardcode dm interface versions

Am 28.02.2017 um 02:19 schrieb Marc Lehmann: > Package: systemd > Version: 232-18 > Severity: normal > > Dear Maintainer, > > I upgraded to stretch, using kernel 4.4.47. When rebooting, system could > not clean up device mapper targets, leading to a hard crash for all cache > targets, requiring m

Bug#856306: add tilegx architecture support to systemd

Dear Helmut Am 27.02.2017 um 14:51 schrieb Helmut Grohne: > systemd fails to cross build for tilegx (and likely fails to build Please file that issue directly upstream and report back with the bug number so we can mark it as fowarded accordingly. Once it has been accepted upstream, we can consid

Bug#856265: systemd-journald: RuntimeMaxUse is not properly obeyed

Am 27.02.2017 um 13:57 schrieb Martin Pitt: > Felipe Sateler [2017-02-27 9:39 -0300]: >> For avoidance of doubt, RuntimeMaxUse does not refer to RSS, but >> rather to the "disk" space used in /run when the persistent journal is >> not active. So this flag does not control what you want. AFAIK, the

Bug#856265: systemd-journald: RuntimeMaxUse is not properly obeyed

Am 27.02.2017 um 13:11 schrieb Stephan Sokolow (You actually CAN reply): > Is there currently any functionality in journald for controlling > flushing to limit RSS Not that I'm aware of. That said, if you have constrained memory requirements, I wouldn't log to /run (which is a tmpfs, i.e. uses you

Bug#854805: systemd: dbus interraction problems leading to timeouts

Am 27.02.2017 um 09:51 schrieb Stephan Sokolow (You actually CAN reply): > I'm not sure if it's relevant, but I managed to get similar connection > timeouts (specifically, `systemctl` consistently failing with timeouts > on `org.freedesktop.systemd1`) when I ran `apt-get install systemd-cron` > and

Bug#854805: systemd: dbus interraction problems leading to timeouts

Am 27.02.2017 um 11:04 schrieb Vincent Danjean: > I forgot to update this bug report. > On my machine, I did some cleanup (apt-get autoremove + manual > removal of package that are not available in stretch any more). > This solve the problem: the machine boots correctly without > any problema

Bug#856217: [/lib/systemd/system/user@.service:13] Invalid user/group name or numeric ID, ignoring: .service

Am 26.02.2017 um 18:56 schrieb Patrick Schleizer: > Do you think this warning could / should be removed? > No, why? The warning is correct. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digita

Bug#856217: [/lib/systemd/system/user@.service:13] Invalid user/group name or numeric ID, ignoring: .service

Am 26.02.2017 um 18:26 schrieb Patrick Schleizer: > Package: systemd > Severity: normal > X-Debbugs-CC: whonix-de...@whonix.org > > sudo service user@.service status > ● user@.service.service - User Manager for UID .service >Loaded: loaded (/lib/systemd/system/user@.service; static; vendor > p

Bug#856005: systemd-udevd.service: Failed at step ADDRESS_FAMILIES during upgrade

Am 24.02.2017 um 22:32 schrieb Marcel Šebek: > Yes, the problem is reproducible after reboot, the system cannot > start udev manager and boots into single-user mode. > > Maybe it is irrelevant for this bug report, but about a week ago, I > accidentally upgraded my system to unstable (except kernel

Bug#856035: Assertion 'path' failed .. Freezing execution.

Control: tags -1 + confirmed Control: forwarded -1 https://github.com/systemd/systemd/issues/5441 Am 24.02.2017 um 14:38 schrieb Peter Palfrader: > Package: systemd > Version: 215-17+deb8u6 > Severity: normal > > Hi, on jessie (amd64 kvm/qemu VM) I can reliably trigger this: > > | systemd[1]: Go

Bug#856031: systemd: /lib/systemd/system-shutdown/ is ignored

Control: forcemerge -1 856028 Am 24.02.2017 um 14:28 schrieb Frank Breitling: > Package: systemd > Version: 232-18 > Severity: normal > > Dear Maintainer, > >I need to run a script at shutdown and reboot. > >Linking my script to /etc/rc0.d and rc6.d was not successful so I added >

Bug#851402: failed unmounting /var during shutdown

Am 23.02.2017 um 09:39 schrieb Carlchen: > Hi, > > I have the same problem. I have installed a few days ago a fresh Debian > Stretch System to my new HDD and I use some more partitions. > > I have /, /home, /tmp, /var and swap on separate partitions, so Debian > is recomming it on there german In

Bug#855798: udev: MemoryDenyWriteExecute=yes should not be applied to udev plugins

Am 21.02.2017 um 17:37 schrieb Marco d'Itri: > On Feb 21, Mike Manning wrote: > >> Some executables outside of systemd are no longer run as plugins after >> an upgrade from Debian 8 to Debian 9 RC2, even though they should be > Do you have a list? I would like to better understand the impact of

Bug#855345: jessie-pu: package systemd/215-17+deb8u7

.d utility does not provide is-enabled, so implement it ourselves in systemctl using the same logic as systemd-sysv-install from Stretch. (Closes: #809405) -- Michael Biebl Fri, 17 Feb 2017 00:26:38 +0100 The complete debdiff is attached. Regards, Michael -- System Information: Debi

Re: unblock: systemd/231-18

Am 16.02.2017 um 22:12 schrieb Martin Pitt: > Package: release.debian.org > User: release.debian@packages.debian.org > Usertags: unblock > > Hello release team, > > The current systemd in unstable (232-18) fixes an RC bug on architectures that > don't support seccomp (https://bugs.debian.org/

Bug#855272: systemd: policykit does not show TUI for remote logins

Am 16.02.2017 um 18:38 schrieb Ritesh Raj Sarraf: > On Thu, 2017-02-16 at 18:14 +0100, Michael Biebl wrote: >> So, you have hostA and hostB, both run an X server. > >> You login from hostA to hostB via SSH as userC (and X-forwarding enabled). >> If you run an action which

Bug#855272: systemd: policykit does not show TUI for remote logins

Am 16.02.2017 um 18:14 schrieb Michael Biebl: > Am 16.02.2017 um 18:05 schrieb Ritesh Raj Sarraf: >> 1. When X11 forwarding is enabled, it shows the policykit prompt on gdm >> display >> server. And even with the gdm screen locked, one can still feed in the >> passwor

Bug#855272: systemd: policykit does not show TUI for remote logins

Am 16.02.2017 um 18:05 schrieb Ritesh Raj Sarraf: > 1. When X11 forwarding is enabled, it shows the policykit prompt on gdm > display > server. And even with the gdm screen locked, one can still feed in the > password > there. So, you have hostA and hostB, both run an X server. You login from

Bug#855272: systemd: policykit does not show TUI for remote logins

Am 16.02.2017 um 10:42 schrieb Ritesh Raj Sarraf: > Package: systemd > Version: 232-17 > Severity: important > > Hello, > > *** > rrs@chutzpah:~$ echo $DISPLAY > localhost:10.0 > 14:22 __ _ If that is set, do you have X forwardin

Bug#854041: me too, but not getting past "apt-get -f install"

Am 16.02.2017 um 10:32 schrieb Daniel Pocock: > > I've tried upgrading two systems from jessie to stretch > > The first one didn't experience this issue, the second one did. Both > systems had been upgraded through several versions of Debian over many > years, they had not been clean installs of

Bug#809405: systemd: Backport systemctl is-enabled support for SysV init scripts to Debian Jessie

ing intelligent life in the universe are pointed away from Earth? From 74a55eee2e4fdc15d4b7857e2f2454dd00730fc0 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Wed, 15 Feb 2017 10:03:37 +0100 Subject: [PATCH] Support is-enabled for SysV init scripts As update-rc.d does not provide is-enabled, w

Bug#854648: systemd-sysv: Immediate shutdown can happen despite future time argument if unable to talk to shutdownd

Hi Will Am 09.02.2017 um 00:09 schrieb Will Aoki: > After upgrading a system from wheezy to jessie, I attempted to schedule a > reboot at 8:27 AM by executing '/sbin/shutdown -r 08:27 completing upgrade'. > It produced this (partial) error, which did not stay on the screen long enough > to copy: >

Re: Bug#854911: dbus fails to start on package installation on very minimal systems

Am 12.02.2017 um 00:39 schrieb Alexander Kurtz: > Control: severity -1 normal > > Hi! > > Thanks for your quick reply! I tried to make this bug reproducible and > eventually succeeded: The crucial point was, that the package > installation must happen *before* systemd considers the system fully >

Bug#854814: Fails to start systemd-resolved

Am 11.02.2017 um 17:17 schrieb Martin Pitt: > Michael Biebl [2017-02-10 19:20 +0100]: >> I guess this should only be used in addition with ProtectSystem=, which >> is a recent upstream change but the Debian version does not use that yet. > > No, I did test it with our curren

Bug#854699: Shutdown fails with an encrypted filesystem on virtio device

Am 11.02.2017 um 16:21 schrieb Yuri D'Elia: > On Sat, Feb 11 2017, Michael Biebl wrote: >>> reached? If I cannot get a clean journal out, there's nothing much I can >>> debug. >> >> You could try to attach a serial device to your VM and log the output to

Bug#854699: Shutdown fails with an encrypted filesystem on virtio device

Am 11.02.2017 um 14:38 schrieb Yuri D'Elia: > reached? If I cannot get a clean journal out, there's nothing much I can > debug. You could try to attach a serial device to your VM and log the output to that device [1]. This will get us a more complete log. Attach the complete file. [1] https://fr

Bug#854699: Shutdown fails with an encrypted filesystem on virtio device

Am 10.02.2017 um 12:14 schrieb Yuri D'Elia: > On Fri, Feb 10 2017, Michael Biebl wrote: >> Looks similar to >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848044 and a lot like >> https://github.com/systemd/systemd/issues/1620 > > Uhm, it does. Aside fr

Bug#854814: Fails to start systemd-resolved

Control: severity -1 important Am 10.02.2017 um 17:49 schrieb Yuri D'Elia: > > With the update to 232-17, systemd-resolved fails to start with the > following error: > > -- The error number returned by this process is 2. > Feb 10 17:46:31 test systemd[1]: systemd-resolved.service: Main process

Bug#854814: Fails to start systemd-resolved

Am 10.02.2017 um 17:49 schrieb Yuri D'Elia: > Package: systemd > Version: 232-17 > Severity: normal > > With the update to 232-17, systemd-resolved fails to start with the > following error: > > -- The error number returned by this process is 2. > Feb 10 17:46:31 test systemd[1]: systemd-resolved

Bug#854699: Shutdown fails with an encrypted filesystem on virtio device

Am 09.02.2017 um 16:39 schrieb Yuri D'Elia: > Package: systemd > Version: 232-15 > Severity: normal > > I've setup a VM using kvm with a virtio block device, running debian > unstable > and an encrypted root filesystem (automatically setup during > installation as > lvm+encrypted volume). > > Som

Bug#848044: Any solution?

Am 10.02.2017 um 02:16 schrieb lumin: > Version: 232-16 > > Same here. > Does anyone have a solution to this problem? I suspect this is a problem in either LVM/DM or cryptsetup. You should probably talk to those maintainers. -- Why is it that all of the instruments seeking intelligent life in

Bug#808884: filesystem check progress messages to boot console always remain at 0.0% if more than one filesystem is being checked

Control: tags -1 moreinfo On Thu, 24 Dec 2015 10:52:16 +0800 =?utf-8?B?56mN5Li55bC8?= Dan Jacobson wrote: > Package: systemd > Version: 228-2+b1 > Severity: minor > > If there are any "(checking 2 filesystems)" type messages to the console > upon boot, the progress will always just show 0.0%. >

Bug#854041: systemd: dpkg fails for systemd package when upgrading from jessie to stretch

Am 03.02.2017 um 15:19 schrieb Carsten Brandt: > Am 03.02.2017 um 14:15 schrieb Michael Biebl: >> Carsten, can you attach /var/lib/dpkg/status from before the upgrade. >> This should give us an opportunity to reproduce the problem. > > > You can download it from here: &g

Bug#854392: Run "make check" as root via autopkgtest

Running the test-suite as unprivileged user on my development laptop, only 11 tests are skipped: test-barrier test-boot-timestamps test-bus-benchmark test-bus-kernel test-bus-kernel-bloom test-bus-zero-copy test-capability (**) test-dhcp-server test-execute (**) test-namespace (**) test/udev-test.

Bug#854392: Run "make check" as root via autopkgtest

Looking through the build logs, we currently skip 21 tests on arm64, armel, armhf, i386, mipsel, mips, powerpc, ppc64el, s390x and x32: test-barrier test-boot-timestamps test-bus-benchmark test-bus-chat test-bus-cleanup test-bus-creds test-bus-gvariant test-bus-kernel test-bus-kernel-bloom test-bu

Bug#854400: systemd: FTBFS if /tmp is an overlayfs

Am 06.02.2017 um 18:07 schrieb James Cowgill: > Source: systemd > Version: 232-15 > Severity: important > > Hi, > > While testing #852811 I discovered that systemd does not build within an > overlayfs schroot (which all my mips chroots are setup as). Specifically > the "test-copy" test fails with

Bug#854396: test_exec_privatenetwork is not run due to missing ip

Source: systemd Version: 232-15 Severity: normal In test-execute.c the test_exec_privatenetwork test is not run if the ip binary is not found: src/test/test-execute.c:r = find_binary("ip", NULL); src/test/test-execute.c-if (r < 0) { src/test/test-execute.c-log_erro

Bug#854394: test_exec_capabilityboundingset is not run due to missing capsh

Source: systemd Version: 232-15 Severity: normal In test/test-execute.c the test_exec_capabilityboundingset is skipped if capsh is not found: test/test-execute.c:/* We use capsh to test if the capabilities are test/test-execute.c:r = find_binary("capsh", NULL); test/test-execute.c

Bug#854392: Run "make check" as root via autopkgtest

Source: systemd Version: 232-15 Severity: normal Several of the upstream tests require root privileges as otherwise they do nothing: if (geteuid() != 0) return; It seems we missed issues because of that like the recent RAS/seccomp incident has shown [1]. E.g. test-seccomp was rightfully f

Bug#852811: udev: Doesn't start after upgrade mipsel, powerpc

Am 06.02.2017 um 11:21 schrieb James Cowgill: > On Sun, 5 Feb 2017 12:16:41 + James Cowgill wrote: >> Control: retitle -1 udev: Doesn't start after upgrade mipsel, powerpc >> >> Hi, >> >> FWIW, and as predicted by comments on the upstream bugreport, this also >> fails on at least mipsel. I hav

Bug#854041: systemd: dpkg fails for systemd package when upgrading from jessie to stretch

Am 03.02.2017 um 14:04 schrieb Felipe Sateler: > So, apt decided it needed to temporarily remove systemd for some > reason, and systemd errors out because removing systemd while running > under it is a bad idea[1]. > > Dear apt maintainers, any idea on what conditions could result in apt > decidin

Bug#853940: systemd: RestrictAddressFamilies causes services to fail to start on powerpc

Am 02.02.2017 um 20:58 schrieb Phil Armstrong: > On 02/02/17 16:04, Phil Armstrong wrote: > >> On Feb 2 2017, Michael Biebl wrote: >> >>> I guess it would be worthwile testing 232-1 from snapshot.d.o [1] >> >> Downgrading systemd, udev, libud

Bug#853755: Processed: severity of 853755 is important

severity -1 serious Am 02.02.2017 um 16:33 schrieb Debian Bug Tracking System: > Processing commands for cont...@bugs.debian.org: > >> severity 853755 important > Bug #853755 [src:systemd] installation-reports: ppc64el fails to boot after > installation > Severity set to 'important' from 'normal

Bug#853755: installation-reports: ppc64el fails to boot after installation

Am 02.02.2017 um 15:56 schrieb Erwan Prioul: > On 02/02/2017 02:46 PM, Michael Biebl wrote: >> >> Erwan, could you try 232-1 from snapshots.debian.org and see if the >> problem is reproducible there? > > I ran few tests. > 232-1 is OK, same result for 232-8 and 232-1

Bug#853940: systemd: RestrictAddressFamilies causes services to fail to start on powerpc

Am 02.02.2017 um 15:19 schrieb Phil Armstrong: > > Were these entries added to the systemd service files only recently? > These services all started breaking for me about a week or two ago. They > were fine beforehand. > > The machine in question vaguely tracks sid. It did track testing until > p

Bug#853940: systemd: RestrictAddressFamilies causes services to fail to start on powerpc

Am 02.02.2017 um 11:46 schrieb Phil Armstrong: > Package: systemd > Version: 232-15 > Severity: normal > > A recent update to systemd enabled SECCOMP, after which any service using > RestrictAddressFamilies, MemoryDenyWriteExecute or RestrictRealtime fails > to start. This includes udev, systemd-lo

Bug#853755: installation-reports: ppc64el fails to boot after installation

14 (current version), and it worked. > > Ah, right, that's one of the big differences between a boot to d-i and > a boot to the installed system… Good catch! > >> I'll reassign this to systemd. > > An easy suspect would be: > | commit 7b17f7c824429e

Bug#852806: /lib/systemd/systemd-networkd: complains about invalid config section

Control: tags -1 + upstream Hi Am 27.01.2017 um 14:43 schrieb Ritesh Raj Sarraf: > rrs@learner:~$ cat /etc/systemd/network/tap.netdev > [NetDev] > Name=tap0 > Kind=tap > > [Tap] > Group=uml-net > User=uml-net > 2017-01-27 / 19:07:13 ♒♒♒ ☺ > > I keep getting the following warning/error in j

Re: Bug#853276: udev: Upgrade from 232-8 to 232-14 results in 'systemd-udevd.service: Failed with result 'timeout'

Am 31.01.2017 um 21:34 schrieb ant: > FWIW, when i had the recent upgrade to 232-14 go through > it did not complete the first attempt. i just ran apt-get > upgrade again and it completed. Do you have systemd 232-14 installed now -- Why is it that all of the instruments seeking intelligent

Bug#853276: udev: Upgrade from 232-8 to 232-14 results in 'systemd-udevd.service: Failed with result 'timeout'

Control: forcemerge 853078 -1 Am 31.01.2017 um 04:30 schrieb Jehster: > Package: udev > Version: 232-14 [..] > Architecture: i386 (i686) [..] > Versions of packages udev is related to: > ii systemd 232-8 Duplicate of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853078 You have a parti

Bug#852461: systemd: Creating scopes with systemd-run unreliable

Am 28.01.2017 um 00:02 schrieb Michael Biebl: > > > Am 27. Januar 2017 21:16:52 MEZ schrieb Michael Gebetsroither > : >> On 2017-01-27 20:50, Michael Biebl wrote: >> >>>> The error sent from systemd back to systemd-run seems to be: >>>> "Un

Bug#824532: [Pkg-auth-maintainers] Bug#848327: RFS: libu2f-host/1.1.3-1

Am 29.01.2017 um 22:07 schrieb Luca Capello: > Hi there, > > On Fri, 27 Jan 2017 23:08:08 +0100, Nicolas Braud-Santoni wrote: >> On Sun, Dec 25, 2016 at 03:29:39PM +0100, Luca Capello wrote: >>> >>> sorry for the late reply, the package was rejected: >>> >>> >>>

Bug#852883: systemd: FTBFS: Test failures

Am 29.01.2017 um 17:47 schrieb Lucas Nussbaum: > On 29/01/17 at 17:28 +0100, Michael Biebl wrote: >> Am 29.01.2017 um 17:10 schrieb Lucas Nussbaum: >> >>> Yes, tzdata is no longer build-essential, and is not installed in the >>> chroot. >> >> [..] >

Bug#852883: systemd: FTBFS: Test failures

Am 29.01.2017 um 17:10 schrieb Lucas Nussbaum: > Yes, tzdata is no longer build-essential, and is not installed in the > chroot. [..] > Actually, I did a rebuild specifically for that some time ago (to file > all bugs in that category). I assume that something changed on the > systemd side, caus

Bug#852883: systemd: FTBFS: Test failures

Hi Lucas Am 29.01.2017 um 08:15 schrieb Lucas Nussbaum: > On 28/01/17 at 10:40 +0100, Michael Biebl wrote: >> The package built fine on the buildds just a couple of days ago. Do you have >> an idea how the aws build environment differs? > > No, sorry I had a closer look a

Bug#853078: udev: fails to start under systemd due to partial upgrade (seccomp error)

Package: udev Version: 232-14 Severity: important Am 29.01.2017 um 15:09 schrieb Michael Biebl: > Am 29.01.2017 um 11:53 schrieb Teemu Ikonen: >> Package: udev >> Version: 232-14 >> Followup-For: Bug #852811 >> >> I got same behaviour from udev as Ch

Bug#852811: marked as done (udev: Doesn't start after upgrade powerpc)

Dear powerpc porters, it would be great if you could look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852811 From a cursory glance it seems that seccomp support is broken on ppc64. Your input would be appreciated. Am 27.01.2017 um 16:21 schrieb Michael Biebl: > Am 27.01.2017 um 15

Bug#852811: udev: Doesn't start after upgrade powerpc

Am 27.01.2017 um 15:27 schrieb Christian Marillat: > On 27 janv. 2017 15:16, m...@linux.it (Marco d'Itri) wrote: > >> On Jan 27, Christian Marillat wrote: >> >>> Maybe the problem is because / is a RAID0 ? >>> >>> Setting up udev (232-14) ... >> No. This is the problem: >> >>> addgroup: The group

Bug#852811: udev: Doesn't start after upgrade

Am 29.01.2017 um 11:53 schrieb Teemu Ikonen: > Package: udev > Version: 232-14 > Followup-For: Bug #852811 > > I got same behaviour from udev as Christian on i386 (Apple MacBook2,1). > Commenting out the lines mentioned above in systemd-udevd.service made > udev start. > > The problem was version

Bug#852883: systemd: FTBFS: Test failures

The package built fine on the buildds just a couple of days ago. Do you have an idea how the aws build environment differs? Am 28. Januar 2017 09:28:00 MEZ schrieb Lucas Nussbaum : >Source: systemd >Version: 232-14 >Severity: serious >Tags: stretch sid >User: debian...@lists.debian.org >Usertags

Bug#852461: systemd: Creating scopes with systemd-run unreliable

Am 27. Januar 2017 21:16:52 MEZ schrieb Michael Gebetsroither : >On 2017-01-27 20:50, Michael Biebl wrote: > >>> The error sent from systemd back to systemd-run seems to be: >>> "Unit run-24908.scope already exists." >> >> >> Could you ch

Bug#852461: systemd: Creating scopes with systemd-run unreliable

Am 27. Januar 2017 18:56:31 MEZ schrieb Michael Gebetsroither : >On 2017-01-24 20:20, Michael Biebl wrote: >Hi Michael, > >>> The creation of scopes with systemd-run --scope is unreliable. >>> It seems to depend on system "load" or some other factors

Bug#852811: marked as done (udev: Doesn't start after upgrade powerpc)

Am 27.01.2017 um 16:30 schrieb Christian Marillat: > On 27 janv. 2017 16:21, Michael Biebl wrote: > >> Christian, I think it's best if you approach the ppc64 porters about >> this. We need their input regarding seccomp support on that architecture. > > Well

Bug#852811: marked as done (udev: Doesn't start after upgrade powerpc)

Am 27.01.2017 um 15:54 schrieb Christian Marillat: > #MemoryDenyWriteExecute=yes > #RestrictRealtime=yes > #RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 > > But I see others problems after a reboot : There are quite a few services which use seccomp features to restrict the service.

Bug#852811: marked as done (udev: Doesn't start after upgrade powerpc)

Am 27.01.2017 um 15:40 schrieb Christian Marillat: > On 27 janv. 2017 15:26, Michael Biebl wrote: > >> Am 27.01.2017 um 15:21 schrieb Debian Bug Tracking System: > > [...] > >> seccomp is supposed to work on ppc64 [1], but maybe it's not. &g

Bug#852811: marked as done (udev: Doesn't start after upgrade powerpc)

Am 27.01.2017 um 15:26 schrieb Michael Biebl: > Am 27.01.2017 um 15:21 schrieb Debian Bug Tracking System: >>> Maybe the problem is because / is a RAID0 ? >>> >>> Setting up udev (232-14) ... >> No. This is the problem: >> >>> addgroup: The grou

Bug#852811: marked as done (udev: Doesn't start after upgrade powerpc)

Am 27.01.2017 um 15:21 schrieb Debian Bug Tracking System: >> Maybe the problem is because / is a RAID0 ? >> >> Setting up udev (232-14) ... > No. This is the problem: > >> addgroup: The group `input' already exists as a system group. Exiting. I suspect this to be the problem: Jan 27 14:51:23 fa

Bug#823577: Patches

On Sat, 3 Dec 2016 00:43:49 +0100 Michael Biebl wrote: > control: tags -1 + moreinfo > control: user pkg-systemd-maintainers@lists.alioth.debian.org > control: usertag -1 + jessie-backport > Hi > > On Mon, 6 Jun 2016 15:26:31 +0200 Michael Biebl wrote: > > Am 06.05.2

Bug#774430: systemd: service makes as not reloadable

Am 26.01.2017 um 15:44 schrieb Michael Biebl: > Am 18.01.2017 um 14:31 schrieb James Cowgill: >> After debugging a bit I found this commit which seems likely to be the >> cause. I haven't actually tested 215 with the patch though: >> https://github.

Bug#774430: systemd: service makes as not reloadable

Hi James Am 18.01.2017 um 14:31 schrieb James Cowgill: > I've checked for this bug across various mips machines, and it is only > present on the big-endian machines running jessie. I then managed to > bisect it to somewhere between 215 and 217. > > After debugging a bit I found this commit which

Re: Bug#852597: iio-sensor-proxy: process keeps running after package purge

Am 25.01.2017 um 16:27 schrieb Ritesh Raj Sarraf: > So a "static" service is: > > The state will usually be "enabled", "disabled", "static", or "masked". In > this > context, static means that the unit file does not contain an "install" > section, > which is used to enable a unit. As such, thes

Bug#808429: systemd: Please add logcheck rules

control: reassign -1 logcheck-database Am 20.12.2015 um 02:32 schrieb Kevin Locke: > Hi Michael, > > Thanks for the very fast response! > > On 12/19/2015 06:24 PM, Michael Biebl wrote: >> Am 20.12.2015 um 02:11 schrieb Kevin Locke: >>> systemd currently logs many

Bug#852461: systemd: Creating scopes with systemd-run unreliable

Am 24.01.2017 um 16:13 schrieb Michael Gebetsroither: > Source: systemd > Version: 215-17+deb8u5 > Severity: normal > > Dear Maintainer, > > The creation of scopes with systemd-run --scope is unreliable. > It seems to depend on system "load" or some other factors affected > by system "load". > On

Bug#852229: failing to log output at boot time

Am 22.01.2017 um 18:55 schrieb 積丹尼 Dan Jacobson: > Package: systemd > Version: 232-12 > > As you see in Bug#852194, systemd is failing to log its output at boot time. This bug report does not contain any useful information. Please provide more details. You know the drill. -- Why is it that a

Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots

Control: found -1 232-8 Hi David Am 22.01.2017 um 18:20 schrieb David Taylor: > On Sun, 22 Jan 2017, Michael Biebl wrote: > >> Control: tags -1 + moreinfo >> >> Am 22.01.2017 um 14:14 schrieb David Taylor: >>> Currently running systemd_231-9, first experience

Bug#852202: systemd 232-13 aborts during upgrade and subsequent boots

Control: tags -1 + moreinfo Am 22.01.2017 um 14:14 schrieb David Taylor: > Currently running systemd_231-9, first experienced this problem when > trying to upgrade to 232-8, 232-13 is still giving the same problem. Upgrading from -9 to -8? I guess you mistyped this. What is the first version you

Re: Which symlink to use to disable predictable network interface names?

On 19.01.2017 15:36, Patrick Schleizer wrote: > Which way is the way to go? > > ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules > > or > > ln -s /dev/null /etc/systemd/network/99-default.link > > ? > > (and rebuild the initrd with "update-initramfs -u".) Please see /usr/share/doc/ud

Re: Bug#851747: sysvinit-utils: unmaintained package should not be Essential

Am 18.01.2017 um 15:23 schrieb Felipe Sateler: >> /sbin/fstab-decode > > I see only drbl and open-iscsi use this[1], so they could start > depending on sysvinit-utils too. > open-iscsi ships a native service file, so this would only matter for the case where sysvinit is the active PID 1 in which

Bug#851730: init-system-helpers: update-rc.d fails to disable nbd-server

Am 18.01.2017 um 13:53 schrieb Felipe Sateler: > But the nbd-server initscript has trailing whitespace. > > I wonder if update-rc.d should relax the match to not include the line > ending. For reference, both the systemd sysv-generator and insserv > have such a relaxed parsing: > > https://source

Bug#851402: failed unmounting /var during shutdown

Control: forwarded -1 https://github.com/systemd/systemd/issues/867 Control: tags -1 - moreinfo Control: severity -1 normal Am 14.01.2017 um 16:37 schrieb Daniel Pocock: > Package: systemd > Version: 232-8 > Severity: important > > > The box is running stretch, updated from jessie yesterday. >

Bug#851412: Bug#850887: To the right bug this time: Why do you want us to keep this open?

clone 851412 -1 reassign -1 binutils forwarded -1 https://sourceware.org/bugzilla/show_bug.cgi?id=21054 retitle -1 Forced local symbol rearranging messes up GOT Hi James Am 17.01.2017 um 12:18 schrieb James Cowgill: > On 17/01/17 09:10, Michael Biebl wrote: >> Am 17.01.2017 um 10:0

Bug#851688: systemd: Redirect try-restart in SysV init scripts

Am 17.01.2017 um 19:46 schrieb Ondrej Novy: > Hi, > > 2017-01-17 19:26 GMT+01:00 Michael Biebl <mailto:bi...@debian.org>>: > > I think this would be useful but this would need changes in invoke-rc.d, > > > no, invoke-rc.d supports this. Well, not qui

Bug#851688: systemd: Redirect try-restart in SysV init scripts

Hi Am 17.01.2017 um 18:52 schrieb Ondřej Nový: > Package: systemd > Version: 232-8 > Severity: wishlist > > When i call /etc/init.d/

<    1   2   3   4   5   6   7   8   9   10   >