Bug#801737: udev: A better trace

Package: udev Version: 227-2 Followup-For: Bug #801737 Dear Maintainer, Hi, As the bug happens with packagekit, consolekit, modemmanage!, virtualbox, it's often related to services. I tried a simple one, modemmanager, to analyze. Here's what renders: strace deb-systemd-invoke try-restart ModemMa

Bug#801563: (no subject)

Yes, I confirm. With timeout=1min everything goes fine, but with timeout=2min the situation I have described in the beginning happens again. I've heard about 1.30min systemd timeout for all units. Could it be because of this timeout? -- Yours sincerely, Jayson Willson

Bug#801563: But..

However, if I set timeout=2min, then I get just the same behavior (lagging emergency mode and system does not boot). Seems like there is some other timeout between 1min and 2min, and when systemd-cryptsetup reaches this timeout, systemd goes mad. ___

Bug#801563: Seems like I have managed to solve the problem

I have added "timeout=1" to the fourth row of crypttab, and now systemd falls to emergency mode correctly. -- Yours sincerely, Jayson Willson ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.

Bug#801215: systemd: Re-booting results in systemd "Timed out waiting for device dev-mapper-..."

we are seeing the exact same behavior on one of our system - is there anything we can do to help debug what's going on? -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi _

Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

Hi Martin, On Fr, 2015-10-23 at 17:10 +0200, Martin Pitt wrote: (..) > > 227-2, sid: Fails, retval 6: > > # root? systemctl restart non-existing.service > > Failed to restart non-existing.service: Unit non-existing.service failed > > to load: No such file or directory. > > # root? systemctl re

Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

Am 23.10.2015 um 17:10 schrieb Martin Pitt: > Hello Stephan, > > Stephan Suerken [2015-10-23 13:32 +]: >> with 227-2 (not found in 226-2), systemctl behaves differently >> in chroots for (at least) services that only provide a sysv init >> script, breaking package install or removal: > >> 226

Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

Hello Stephan, Stephan Suerken [2015-10-23 13:32 +]: > with 227-2 (not found in 226-2), systemctl behaves differently > in chroots for (at least) services that only provide a sysv init > script, breaking package install or removal: > 226-2, jessie: Ignored, retval 0: > # root? systemctl rest

Processed: Re: Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

Processing control commands: > severity -1 important Bug #802780 [systemd] systemd: systemctl 227 fails in chroots (instead of ignoring) Severity set to 'important' from 'normal' > tags -1 confirmed Bug #802780 [systemd] systemd: systemctl 227 fails in chroots (instead of ignoring) Added tag(s)

Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

Control: severity -1 important Control: tags -1 confirmed Am 23.10.2015 um 15:32 schrieb Stephan Suerken: > Package: systemd > Version: 227-2 > Severity: normal > > Dear Maintainers, > > with 227-2 (not found in 226-2), systemctl behaves differently > in chroots for (at least) services that only

Bug#802780: systemd: systemctl 227 fails in chroots (instead of ignoring)

Package: systemd Version: 227-2 Severity: normal Dear Maintainers, with 227-2 (not found in 226-2), systemctl behaves differently in chroots for (at least) services that only provide a sysv init script, breaking package install or removal: 226-2, jessie: Ignored, retval 0: # root? systemctl res

Bug#788050: systemd-fsck : Check disks at each reboot

Dear maintainer, according to the suggestion from message #65 I have increased the timeout to 30min. But fsck still ends with error 13 checking big partitions. Manually fsck ends succeesfully. It seems to be the same behaviour described in message #70.