Bug#892360: core: do not free stack-allocated strings

* Jindřich Makovička [2018-03-08 19:46 +]: > There is a fix in upstream master. > > https://github.com/systemd/systemd/pull/8391 Patched Debian sources and tried to build packages: OK: 239 FAIL: 1 SKIP: 15 TIMEOUT:0 debian/rules:281: recipe for

Bug#892360: systemd: No problem on my amd64 systems

* Diederik de Haas [2018-03-08 20:29 +0100]: > Package: systemd > Followup-For: Bug #892360 > > Wanting to let you know that I had no problem on my PC (from which I'm > reporting) and also not on my laptop. > > I did not have to specify any (systemd related) kernel

Bug#892360: core: do not free stack-allocated strings

There is a fix in upstream master. https://github.com/systemd/systemd/pull/8391 -- Jindřich Makovička ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org

Bug#892360: systemd: Breaks also all my tested amd64 machines

* Elimar Riesebieter [2018-03-08 19:13 +0100]: [...] > ATM I am building a x86 with CONFIG_CGROUP_CPUACCT=not set. Let's > wait and see "CONFIG_CGROUP_CPUACCT is not set" gives the same error as shown in the picture of my initial bug report. The problem must be triggerd

Bug#892360: systemd: No problem on my amd64 systems

Package: systemd Followup-For: Bug #892360 Wanting to let you know that I had no problem on my PC (from which I'm reporting) and also not on my laptop. I did not have to specify any (systemd related) kernel parameters $ cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.15.0-1-amd64

Bug#892360: systemd: Breaks also all my tested amd64 machines

On 3/8/18 7:26 PM, Eric Valette wrote: On 3/8/18 7:13 PM, Elimar Riesebieter wrote: I do have CONFIG_CGROUP_CPUACCT=y on my amd64 kernels and systemd runs fine... Ok. So still in line with hypothesis... ATM I am building a x86 with CONFIG_CGROUP_CPUACCT=not set. Let's wait and see

Bug#892360: systemd: Breaks also all my tested amd64 machines

On 3/8/18 7:13 PM, Elimar Riesebieter wrote: I do have CONFIG_CGROUP_CPUACCT=y on my amd64 kernels and systemd runs fine... Ok. So still in line with hypothesis... ATM I am building a x86 with CONFIG_CGROUP_CPUACCT=not set. Let's wait and see And I'm rebuilding my failing kernel

Bug#892360: systemd: Breaks also all my tested amd64 machines

* Eric Valette [2018-03-08 19:08 +0100]: > On 3/8/18 7:03 PM, Elimar Riesebieter wrote: > > * Michael Biebl [2018-03-08 18:54 +0100]: > > > > [...] > > > Can you check your custom kernel config, specifically if > > > CONFIG_CGROUP_CPUACCT=y > > > > I do

Bug#892360: systemd: Breaks also all my tested amd64 machines

On 3/8/18 7:03 PM, Elimar Riesebieter wrote: * Michael Biebl [2018-03-08 18:54 +0100]: [...] Can you check your custom kernel config, specifically if CONFIG_CGROUP_CPUACCT=y I do have CONFIG_CGROUP_CPUACCT=y Well, but why does 237 works with the very same kernel? In my

Bug#892360: systemd: Breaks also all my tested amd64 machines

* Michael Biebl [2018-03-08 18:54 +0100]: [...] > Can you check your custom kernel config, specifically if > CONFIG_CGROUP_CPUACCT=y I do have CONFIG_CGROUP_CPUACCT=y Well, but why does 237 works with the very same kernel? Elimar -- Numeric stability is probably not all

Bug#892360: systemd: Breaks also all my tested amd64 machines

Can you check your custom kernel config, specifically if CONFIG_CGROUP_CPUACCT=y Probably easiest if you just use grep grep CGROUP /boot/config-$(uname -r) Done in another private email. Can copy here: diff config-4.14.0-3-amd64 config-4.14.23 | grep CGROUP < CONFIG_BLK_CGROUP=y < #

Bug#892360: systemd: Breaks also all my tested amd64 machines

Am 08.03.2018 um 18:31 schrieb Elimar Riesebieter: > * Michael Biebl [2018-03-08 17:09 +0100]: > >> Am 08.03.2018 um 17:05 schrieb Michael Biebl: >>> Control: tags -1 moreinfo >>> >>> Am 08.03.2018 um 16:23 schrieb valette: >>> > [...] > >> Could you check if >>

Bug#892360: systemd: Breaks also all my tested amd64 machines

* Michael Biebl [2018-03-08 17:09 +0100]: > Am 08.03.2018 um 17:05 schrieb Michael Biebl: > > Control: tags -1 moreinfo > > > > Am 08.03.2018 um 16:23 schrieb valette: > > [...] > Could you check if > https://github.com/systemd/systemd/issues/8387 > looks related > > I.e.

Bug#892360: systemd pid 1 freezes at startup on x86 systems

Am 08.03.2018 um 18:27 schrieb Elimar Riesebieter: > * Michael Biebl [2018-03-08 17:05 +0100]: > >> Control: tags -1 moreinfo >> >> Am 08.03.2018 um 16:23 schrieb valette: >> >>> Kernel: Linux 4.14.23 (SMP w/2 CPU cores; PREEMPT) >> >> Is this also happening with a Debian

Bug#892360: systemd pid 1 freezes at startup on x86 systems

* Michael Biebl [2018-03-08 17:05 +0100]: > Control: tags -1 moreinfo > > Am 08.03.2018 um 16:23 schrieb valette: > > > Kernel: Linux 4.14.23 (SMP w/2 CPU cores; PREEMPT) > > Is this also happening with a Debian provided kernel? > I see both you and Elimar use a custom

Bug#846377: discovered likely cause of this issue

Am 08.03.2018 um 12:11 schrieb Michael Biebl: > Dirk, can you confirm that adding pam_keyinit.so to > /etc/pam.d/systemd-user solves the problem for you as well? No, it doesn't. After adding it and logging out and back in I still get this: % keyctl show @s Keyring  918482795 ---lswrv  0

Bug#892360: systemd: Breaks also all my tested amd64 machines

Am 08.03.2018 um 17:09 schrieb Michael Biebl: > Could you check if > https://github.com/systemd/systemd/issues/8387 > looks related > > I.e. if booting with systemd.unified_cgroup_hierarchy avoids the problem. If not, follow the instructions at

Bug#892360: systemd: Breaks also all my tested amd64 machines

Am 08.03.2018 um 17:05 schrieb Michael Biebl: > Control: tags -1 moreinfo > > Am 08.03.2018 um 16:23 schrieb valette: > >> Kernel: Linux 4.14.23 (SMP w/2 CPU cores; PREEMPT) > > Is this also happening with a Debian provided kernel? > I see both you and Elimar use a custom one. > > Is this a

Bug#892360: systemd: Breaks also all my tested amd64 machines

Control: tags -1 moreinfo Am 08.03.2018 um 16:23 schrieb valette: > Kernel: Linux 4.14.23 (SMP w/2 CPU cores; PREEMPT) Is this also happening with a Debian provided kernel? I see both you and Elimar use a custom one. Is this a virtualized environment or read hardware? Do you get a coredump? If

Processed: Re: Bug#892360: systemd: Breaks also all my tested amd64 machines

Processing control commands: > tags -1 moreinfo Bug #892360 [systemd] systemd pid 1 freezes at startup on x86 systems Added tag(s) moreinfo. -- 892360: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892360 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems

Bug#892360: systemd: Breaks also all my tested amd64 machines

Package: systemd Version: 238-1 Followup-For: Bug #892360 I also get a sigsegv on two diferent machines after today upgrade. You can reboot and use sysvinit mode => bug is realy in systemd. Kernel and packages uptodate -- Package-specific info: -- System Information: Debian Release:

Bug#892360: same here on amd64 system

I also have a system crash at init, witha sigsegv that points in libc. I use unstable today (8 march). --eric ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org

Bug#892357: deb-systemd-invoke: if one unit is forbidden by policy-rc.d, all requested units are skipped

Package: init-system-helpers Version: 1.51 Severity: normal dh_systemd_start generates a deb-systemd-invoke command listing all the binary package's units. For snapd in Ubuntu, for example, this looks like this: deb-systemd-invoke start snapd.autoimport.service snapd.core-fixup.service

Bug#883569: libpam-systemd: Prefer systemd-sysv over systemd-shim

Hello Michael, Michael Biebl [2018-03-08 12:16 +0100]: > Am 08.03.2018 um 09:22 schrieb Martin Pitt: > There is one case: someone installs a minimal system without > libpam-systemd, then switches to sysvinit-core, then installs a desktop > environment which pulls libpam-systemd (via polkit in

Bug#883569: libpam-systemd: Prefer systemd-sysv over systemd-shim

Am 08.03.2018 um 09:22 schrieb Martin Pitt: > Hello, > > Julian Andres Klode [2017-12-05 11:43 +0100]: >> libpam-systemd depending on systemd-shim first causes severe trouble with >> resolving dependencies, as APT picks systemd-shim but then later sees a >> package which needs systemd-sysv and

Bug#846377: discovered likely cause of this issue

Thanks Trent for further investigating this. Dirk, can you confirm that adding pam_keyinit.so to /etc/pam.d/systemd-user solves the problem for you as well? Am 08.03.2018 um 09:47 schrieb Trent Lloyd: > I believe I know the cause for this issue.  I ran into the same issue > when trying to use

Bug#892321: attempts to suspend failing after crash

Package: systemd Version: 232-25+deb9u1 Severity: important Laptop was connected to a Thunderbolt dock, lid closed, using desktop monitor and keyboard, everything connected through the dock.  It is a laptop with encrypted LVM and swap on LVM. Laptop's thunderbolt cable was bumped very slightly

Bug#846377: discovered likely cause of this issue

I believe I know the cause for this issue.  I ran into the same issue when trying to use fscrypt to setup ext4 encryption for /home on Ubuntu Bionic /etc/pam.d/systemd-user does not currently call pam_keyinit.so. This means that the keyring does not link to the user keyring as it should, and

Bug#883569: libpam-systemd: Prefer systemd-sysv over systemd-shim

Hello, Julian Andres Klode [2017-12-05 11:43 +0100]: > libpam-systemd depending on systemd-shim first causes severe trouble with > resolving dependencies, as APT picks systemd-shim but then later sees a > package which needs systemd-sysv and fails. > > I understand the order was necessary for