Bug#901991: LogLevel vs log_level vs --log-level
Done, see https://github.com/systemd/systemd/issues/9439 . But I am not very optimistic about this. Regards Harri ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Información sobre ICO
Iberfinancia @media only screen { html { min-height: 100%; background:
#f3f3f3; } } @media only screen and (max-width: 596px) { .small-float-center
{ margin: 0 auto !important; float: none !important; text-align: center
!important; } .small-text-center { text-align: center !important; }
.small-text-left { text-align: left !important; } .small-text-right {
text-align: right !important; } } @media only screen and (max-width: 596px)
{ .hide-for-large { display: block !important; width: auto !important;
overflow: visible !important; max-height: none !important; font-size:
inherit !important; line-height: inherit !important; } } @media only screen
and (max-width: 596px) { table.body table.container .hide-for-large,
table.body table.container .row.hide-for-large { display: table !important;
width: 100% !important; } } @media only screen and (max-width: 596px) {
table.body table.container .callout-inner.hide-for-large { display:
table-cell !important; width: 100% !important; } } @media only screen and
(max-width: 596px) { table.body table.container .show-for-large { display:
none !important; width: 0; mso-hide: all; overflow: hidden; } } @media only
screen and (max-width: 596px) { table.body img { width: auto; height: auto;
} table.body center { min-width: 0 !important; } table.body .container {
width: 95% !important; } table.body .columns, table.body .column { height:
auto !important; -moz-box-sizing: border-box; -webkit-box-sizing:
border-box; box-sizing: border-box; padding-left: 16px !important;
padding-right: 16px !important; } table.body .columns .column, table.body
.columns .columns, table.body .column .column, table.body .column .columns {
padding-left: 0 !important; padding-right: 0 !important; } table.body
.collapse .columns, table.body .collapse .column { padding-left: 0
!important; padding-right: 0 !important; } td.small-1, th.small-1 { display:
inline-block !important; width: 8.3% !important; } td.small-2,
th.small-2 { display: inline-block !important; width: 16.7% !important;
} td.small-3, th.small-3 { display: inline-block !important; width: 25%
!important; } td.small-4, th.small-4 { display: inline-block !important;
width: 33.3% !important; } td.small-5, th.small-5 { display:
inline-block !important; width: 41.7% !important; } td.small-6,
th.small-6 { display: inline-block !important; width: 50% !important; }
td.small-7, th.small-7 { display: inline-block !important; width: 58.3%
!important; } td.small-8, th.small-8 { display: inline-block !important;
width: 66.7% !important; } td.small-9, th.small-9 { display:
inline-block !important; width: 75% !important; } td.small-10, th.small-10 {
display: inline-block !important; width: 83.3% !important; }
td.small-11, th.small-11 { display: inline-block !important; width:
91.7% !important; } td.small-12, th.small-12 { display: inline-block
!important; width: 100% !important; } .columns td.small-12, .column
td.small-12, .columns th.small-12, .column th.small-12 { display: block
!important; width: 100% !important; } table.body td.small-offset-1,
table.body th.small-offset-1 { margin-left: 8.3% !important;
Margin-left: 8.3% !important; } table.body td.small-offset-2, table.body
th.small-offset-2 { margin-left: 16.7% !important; Margin-left:
16.7% !important; } table.body td.small-offset-3, table.body
th.small-offset-3 { margin-left: 25% !important; Margin-left: 25%
!important; } table.body td.small-offset-4, table.body th.small-offset-4 {
margin-left: 33.3% !important; Margin-left: 33.3% !important; }
table.body td.small-offset-5, table.body th.small-offset-5 { margin-left:
41.7% !important; Margin-left: 41.7% !important; } table.body
td.small-offset-6, table.body th.small-offset-6 { margin-left: 50%
!important; Margin-left: 50% !important; } table.body td.small-offset-7,
table.body th.small-offset-7 { margin-left: 58.3% !important;
Margin-left: 58.3% !important; } table.body td.small-offset-8,
table.body th.small-offset-8 { margin-left: 66.7% !important;
Margin-left: 66.7% !important; } table.body td.small-offset-9,
table.body th.small-offset-9 { margin-left: 75% !important; Margin-left: 75%
!important; } table.body td.small-offset-10, table.body th.small-offset-10 {
margin-left: 83.3% !important; Margin-left: 83.3% !important; }
table.body td.small-offset-11, table.body th.small-offset-11 { margin-left:
91.7% !important; Margin-left: 91.7% !important; } table.body
table.columns td.expander, table.body table.columns th.expander { display:
none !important; } table.body .right-text-pad, table.body .text-pad-right {
padding-left: 10px !important; } table.body .left-text-pad, table.body
.text-pad-left { padding-right: 10px !important; } table.menu { width: 100%
!important; } table.menu td, table.menu th { width: auto !important;
display: inline-block !important; } table.menu.vertical td,
table.menu.vertical th, table.menu.small-vertical td,
Bug#902185:
On 06/26/2018 04:45 PM, Christopher Obbard wrote: A reinstall of Debian on my main PC seemed to fix it. I was able to fix it by booting into a recovery shell and running: $ apt-get install systemd which updates systemd to the latest version. I then ran $ apt-get install to finish reconfiguring udev. YMMV. My laptop boots to the WM but with no keyboard/mouse. This is because udev is failing to start. A text-based recovery console will still work, and udev will work properly again once systemd is fully upgraded. This is a grave bug. Agreed. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902185:
this has happened to me on both my laptop and pc when doing an upgrade. A reinstall of Debian on my main PC seemed to fix it. My laptop boots to the WM but with no keyboard/mouse. This is a grave bug. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902185: (no subject)
This bug broke my Sid instance, I had to use a recovery shell to manually upgrade systemd because udev wouldn't start. This is a system-breaking bug. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902336: systemd: sddm login screen does not appear until after more than a minute
Michael Biebl - 26.06.18, 13:30: > Am 26.06.2018 um 13:02 schrieb Michael Biebl: > > The only thing we could do is add a versioned > > Breaks: libffi6 >> 3.3~ to systemd, but I feel a bit uncomfortable > > doing that. > > After further consideration, such a Breaks will not really be helpful, > as it will not trigger an automatic downgrade of libffi6. > > So there is not really anything we can do about this, and I'm afraid > I'll simply have to close this bug report. Fair enough, Michael. Thanks for all your help to get these nailed down to their root causes. -- Martin ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902336: marked as done (upower fails to start with outdated libffi6 from experimental using MemoryDenyWriteExecute=true)
Your message dated Tue, 26 Jun 2018 13:30:22 +0200 with message-id and subject line Re: Bug#902336: systemd: sddm login screen does not appear until after more than a minute has caused the Debian Bug report #902336, regarding upower fails to start with outdated libffi6 from experimental using MemoryDenyWriteExecute=true 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.) -- 902336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902336 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: systemd Version: 239-1 Severity: normal Dear Michael, dear Maintainers, Since using kernel 4.17-rc7 I think (now using self compiled 4.17 vanilla kernel), I see a strange new behavior on this ThinkPad T520. I did not yet test whether it is related to the kernel or something else I upgraded at around the same time. On a fresh boot system sddm login screen does not appear until after more than a minute. There is just tty1 login prompt. Often as I logged in as root to see what is up, sddm comes up. But this might just be a co-incidence. I´d need to test whether it comes up without me doing anything. Or whether logging in as root on tty1 is a necessary pre-condition for sddm to come up (unlikely I think). What I see is this: % systemd-analyze blame | head -20 1min 30.108s chrony.service 4.671s NetworkManager-wait-online.service 1.987s keyboard-setup.service 1.974s dev-mapper-sata\x2ddebian.device 1.061s privoxy.service 909ms udisks2.service 653ms postfix@-.service 614ms networking.service 508ms ModemManager.service 504ms NetworkManager.service 455ms sysfsutils.service 440ms systemd-logind.service 439ms thermald.service 404ms avahi-daemon.service 399ms wpa_supplicant.service 378ms rtkit-daemon.service 260ms tlp.service 252ms libvirtd.service 222ms mnt-home\x2dzeit.mount 212ms home.mount % systemctl --state=failed UNIT LOAD ACTIVE SUBDESCRIPTION ● chrony.service loaded failed failed chrony, an NTP client/server ● upower.service loaded failed failed Daemon for power management […] I think at some time I also saw NetworkManager-wait-online.service not coming up properly. % systemctl status upower ● upower.service - Daemon for power management Loaded: loaded (/lib/systemd/system/upower.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2018-06-25 08:58:19 CEST; 10min ago Docs: man:upowerd(8) Process: 3263 ExecStart=/usr/lib/upower/upowerd (code=exited, status=127) Main PID: 3263 (code=exited, status=127) Jun 25 08:58:19 merkaba systemd[1]: upower.service: Service RestartSec=100ms expired, scheduling restart. Jun 25 08:58:19 merkaba systemd[1]: upower.service: Scheduled restart job, restart counter is at 5. Jun 25 08:58:19 merkaba systemd[1]: Stopped Daemon for power management. Jun 25 08:58:19 merkaba systemd[1]: upower.service: Start request repeated too quickly. Jun 25 08:58:19 merkaba systemd[1]: upower.service: Failed with result 'exit-code'. Jun 25 08:58:19 merkaba systemd[1]: Failed to start Daemon for power management. % systemctl status chrony ● chrony.service - chrony, an NTP client/server Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Mon 2018-06-25 08:49:28 CEST; 19min ago Docs: man:chronyd(8) man:chronyc(1) man:chrony.conf(5) Process: 1574 ExecStart=/usr/sbin/chronyd $DAEMON_OPTS (code=killed, signal=TERM) Jun 25 08:47:59 merkaba systemd[1]: Starting chrony, an NTP client/server... Jun 25 08:47:59 merkaba chronyd[1599]: chronyd version 3.3 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) Jun 25 08:47:59 merkaba chronyd[1599]: Frequency -3.369 +/- 0.300 ppm read from /var/lib/chrony/chrony.drift Jun 25 08:49:28 merkaba systemd[1]: chrony.service: Start operation timed out. Terminating. Jun 25 08:49:28 merkaba systemd[1]: chrony.service: Failed with result 'timeout'. Jun 25 08:49:28 merkaba systemd[1]: Failed to start chrony, an NTP client/server. Often I start up DSL modem, Omnia Turris router and laptop at the same time. Omnia Turris may take a file to provide a working network. But I do not know whether the issue is network related. I also see this on reboots while Omnia Turris and DSL modem are already up and running. I
Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade
Am 26.06.2018 um 13:20 schrieb Joel Cross: > On Tue, 26 Jun 2018, at 12:12 PM, Michael Biebl wrote: >> Which backend have you configured in pm-hibernate? the in-kernel >> hibernate mechanism, Tux0nIce, uswsusp? > > Sorry, I have no idea how to find that out. I do not recall ever configuring > a pm-hibernate backend, so I would guess whichever is the default. If you don't have uswsusp installed or patched your kernel with TuxOnIce support, then you should be using the in-kernel mechanism. >>> Please let me know what further information you need from me (if any) in >>> order >>> to be able to correctly diagnose this bug. >> >> What happens if you run >> >> echo "disk" > /sys/power/state >> >> Does the system resume properly? > > Yes, that works fine. This is strange, because internally systemd simply uses echo "disk" > /sys/power/state Do you have any hooks in /lib/systemd/system-sleep/ ? If so, could you temporarily move them away? Could you provide a journalctl -alb log from such a failed resume + a separate output of dmesg. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade
On Tue, 26 Jun 2018, at 12:12 PM, Michael Biebl wrote: > Which backend have you configured in pm-hibernate? the in-kernel > hibernate mechanism, Tux0nIce, uswsusp? Sorry, I have no idea how to find that out. I do not recall ever configuring a pm-hibernate backend, so I would guess whichever is the default. > > Please let me know what further information you need from me (if any) in > > order > > to be able to correctly diagnose this bug. > > What happens if you run > > echo "disk" > /sys/power/state > > Does the system resume properly? Yes, that works fine. ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902416: systemd: systemctl hibernate: unable to resume after upgrade
Am 26.06.2018 um 12:54 schrieb Joel Cross: > Package: systemd > Version: 239-1 > Severity: normal > > Dear Maintainer, > > Over the last few days (since my last system upgrade) I am unable to > successfully hibernate/resume using the `systemctl hibernate` command. This is > what happens: > > - I run the command > - The screen blinks a few times and my machine switches off, as expected > - When I boot my machine back up, it takes me to the login screen, rather than > restoring my pre-hibernate state. > > In contrast, when I use the command `pm-hibernate` as root, my system is able > to resume from hibernation as expected. Which backend have you configured in pm-hibernate? the in-kernel hibernate mechanism, Tux0nIce, uswsusp? > Please let me know what further information you need from me (if any) in order > to be able to correctly diagnose this bug. What happens if you run echo "disk" > /sys/power/state Does the system resume properly? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: retitle 902336 to upower fails to start with outdated libffi6 from experimental using MemoryDenyWriteExecute=true
Processing commands for cont...@bugs.debian.org: > retitle 902336 upower fails to start with outdated libffi6 from experimental > using MemoryDenyWriteExecute=true Bug #902336 [systemd] systemd: sddm login screen does not appear until after more than a minute Changed Bug title to 'upower fails to start with outdated libffi6 from experimental using MemoryDenyWriteExecute=true' from 'systemd: sddm login screen does not appear until after more than a minute'. > thanks Stopping processing here. Please contact me if you need assistance. -- 902336: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902336 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902336: systemd: sddm login screen does not appear until after more than a minute
Am 26.06.2018 um 12:45 schrieb Martin Steigerwald: > Michael Biebl - 26.06.18, 12:28: >> Am 25.06.2018 um 18:33 schrieb Michael Biebl: >>> Am 25.06.2018 um 17:45 schrieb Martin Steigerwald: So for that booting with Debian kernel would not be necessary I think, but in order to check for the upower issues after restoring the original service file. >>> >>> The upower related start failure looks indeed like an entirely >>> different issue. If I had to guess I'd say it's a missing kernel >>> option. >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902411 seem relevant >> for you. Could you check which version of libffi you have installed >> and is used by upower. > > Gotcha. > > % LANG=C apt policy libffi6 > libffi6: > Installed: 3.3~20160224-1 > Candidate: 3.3~20160224-1 > Version table: > *** 3.3~20160224-1 100 > 100 /var/lib/dpkg/status > 3.2.1-8 500 > 500 http://ftp.de.debian.org/debian sid/main amd64 Packages > > Downgraded to version in Sid, re-installed original upower.service file > and upower starts up correctly on next boot. > > I did not think about checking libffi6 version, sorry. Thanks for checking. Ok, so both cases (sddm and upower) are not really related to the latest systemd upgrade. Reassigning to libffi6 won't really help either, as libffi6 in experimental has been replaced by libffi7 (which is a bit of an unfortunate situation). The only thing we could do is add a versioned Breaks: libffi6 >> 3.3~ to systemd, but I feel a bit uncomfortable doing that. We already have an open bug report for the sddm issue. I'll keep this one open and repurpose it for the MemoryDenyWriteExecute=true + outdated libffi issue. Should more users run into this, I'll reconsider adding such a Breaks, otherwise I'll probably just close it in a few weeks. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902336: systemd: sddm login screen does not appear until after more than a minute
Michael Biebl - 25.06.18, 17:20: > Am 25.06.2018 um 15:11 schrieb Michael Biebl: > > Am 25.06.2018 um 09:18 schrieb Martin Steigerwald: > >> Package: systemd > >> Version: 239-1 > >> Severity: normal > >> > >> Dear Michael, dear Maintainers, > >> > >> Since using kernel 4.17-rc7 I think (now using self compiled 4.17 > >> vanilla kernel), I see a strange new behavior on this ThinkPad > >> T520. I did not yet test whether it is related to the kernel or > >> something else I upgraded at around the same time. > > > > I vaguely remember that recently there were issues related to > > missing > > entropy for the RNG, delaying boot in certain cases. > > This was a kernel related change ttbomk. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897572 > https://lists.debian.org/debian-user/2018/05/msg00599.html I now just typed stuff into the login prompt without actually logging in and sddm appeared after just a few seconds of doing so. Kernel put [ 25.043568] random: crng init done [ 25.043760] random: 3 urandom warning(s) missed due to ratelimiting to console (and in dmesg). -- Martin ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902336: systemd: sddm login screen does not appear until after more than a minute
Michael Biebl - 26.06.18, 12:28: > Am 25.06.2018 um 18:33 schrieb Michael Biebl: > > Am 25.06.2018 um 17:45 schrieb Martin Steigerwald: > >> So for that booting with Debian kernel would not be necessary I > >> think, but in order to check for the upower issues after restoring > >> the original service file. > > > > The upower related start failure looks indeed like an entirely > > different issue. If I had to guess I'd say it's a missing kernel > > option. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902411 seem relevant > for you. Could you check which version of libffi you have installed > and is used by upower. Gotcha. % LANG=C apt policy libffi6 libffi6: Installed: 3.3~20160224-1 Candidate: 3.3~20160224-1 Version table: *** 3.3~20160224-1 100 100 /var/lib/dpkg/status 3.2.1-8 500 500 http://ftp.de.debian.org/debian sid/main amd64 Packages Downgraded to version in Sid, re-installed original upower.service file and upower starts up correctly on next boot. I did not think about checking libffi6 version, sorry. Thanks, -- Martin ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#902336: systemd: sddm login screen does not appear until after more than a minute
Am 25.06.2018 um 18:33 schrieb Michael Biebl: > Am 25.06.2018 um 17:45 schrieb Martin Steigerwald: >> So for that booting with Debian kernel would not be necessary I think, >> but in order to check for the upower issues after restoring the original >> service file. > > The upower related start failure looks indeed like an entirely different > issue. If I had to guess I'd say it's a missing kernel option. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902411 seem relevant for you. Could you check which version of libffi you have installed and is used by upower. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
