Package: systemd-sysv,cryptsetup
Severity: important
Dear Maintainer,
Booting in jessie is currently nearly impossible with multiple cryptsetup
volumes which are mounted at boot time. systemd spews messages over the
prompt and there's a 90-second timeout while typing blind. Please see
the bug r
Am 03.03.2015 um 01:05 schrieb Michael Biebl:
> I've chosen severity important, because if you run that command on the
> console, it makes any input impossible.
What I mean by that: If you e.g. run daemon-reexec on tty1, plymouth
shows its splash screen, but for some reason, no keyboard input is
p
Package: systemd
Version: 219-4
Severity: important
I have plymouth installed and enabled (via "splash" on the kernel
command line").
When I run "systemctl daemon-reexec", plymouth is (re)started:
# systemctl --all | grep plymouth
systemd-ask-password-plymouth.path
On 2015-02-25 21:08, Christian Seiler wrote:
> Package: release.debian.org
> Severity: normal
> X-Debbugs-CC: pkg-systemd-maintainers@lists.alioth.debian.org
>
> Dear release team,
>
> [... long reason ...]
>
> The systemd maintainers do plan to remove support for this after
> Jessie, so this is
#
# bts-link upstream status pull for source package systemd
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#
user bts-link-upstr...@lists.alioth.debian.org
# remote status report for #779057 (http://bugs.debian.org/779057)
# Bug title: emergency mode: Error getting aut
Processing commands for cont...@bugs.debian.org:
> fixed 779571 217-1
Bug #779571 [systemd] systemd: stop v4 dhcpclient when the carrier is lost
Marked as fixed in versions systemd/217-1.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
779571: http://bugs.debian.o
Package: systemd
Version: 215-12
Severity: important
The check for a running v4 dhcp client is using DHCP_SUPPORT_V6
flag instead of DHCP_SUPPORT_V4.
As a result, when the carrier was lost, systemd was not cleaning up the
relevant addresses and routes. If the carrier was regained in another
envi
I did some more tests on this and there is one key thing that I
misunderstood: SO_SNDBUF of the socket that is used to send the
datagrams is used as a limit in the kernel, not of the socket syslog
uses to receive them.
I actually tried setting SendBuffer=1 and ReceiveBuffer=1 on
syslog.socket (to
