On Wed, Dec 22, 2021 at 04:16:30PM -0500, Leo Famulari wrote:
> On Tue, Dec 21, 2021 at 09:19:20PM -0500, Leo Famulari wrote:
> > Would someone like to write a proper commit message and add a code
> > comment?
>
> How about the attached patch? I'd like to push this soon, because it's a
> severe
On Tue, Dec 21, 2021 at 09:19:20PM -0500, Leo Famulari wrote:
> Would someone like to write a proper commit message and add a code
> comment?
How about the attached patch? I'd like to push this soon, because it's a
severe problem for some users.
From ab9c4de76dea889e5d05bcf7fa173868357d5f44 Mon
On Wed, Dec 22, 2021 at 01:46:41AM +, Luis Felipe via Bug reports for GNU
Guix wrote:
> Hello,
>
> Just wanted to inform that I ran
>
> `guix pull --branch=wip-fix-52051 && guix system reconfigure [...]`
>
> and I could log in without problems now. Thanks.
Awesome!
Would someone like to
Hello,
Just wanted to inform that I ran
`guix pull --branch=wip-fix-52051 && guix system reconfigure [...]`
and I could log in without problems now. Thanks.
publickey - luis.felipe.la@protonmail.com - 0x12DE1598.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital
On Tue, Dec 21, 2021 at 05:51:28PM +, Maxime Devos wrote:
> I don't think commenting new code is a drastic and extreme action.
> I assume you were referring you were referring to the ‘16.6 hours’?
Right. We don't want to use a timeout of 16.6 hours. From the
perspective of a user, that's not
Leo Famulari schreef op di 21-12-2021 om 12:32 [-0500]:
> > A comment like
> >
> > > ;; Set timeout to a huge number (16.6 hours), because
> > > ;; upstream often sets timeouts low for spinning disks,
> > > ;; slow CPUs, etc.
> > > (limit [...] "6")
> >
> > could be useful (I'm assuming the
On Tue, Dec 21, 2021 at 12:37:30PM -0500, Leo Famulari wrote:
> With this patch, I can boot and login to X on my X200s with HDD.
> Obviously this failure and subsequent fix are not deterministic, but
> it's a good sign! Let's get some more testing!
I pushed the patch to a Savannah branch to ease
On Tue, Dec 21, 2021 at 11:36:22AM -0500, Timothy Sample wrote:
> diff --git a/gnu/services/dbus.scm b/gnu/services/dbus.scm
> index 85a4c3e..a680ed7 100644
> --- a/gnu/services/dbus.scm
> +++ b/gnu/services/dbus.scm
> @@ -106,6 +106,7 @@ (define-syntax directives
> (define
On Tue, Dec 21, 2021 at 04:52:19PM +, Maxime Devos wrote:
> Are there any good reasons for having a timeout at all?
> (Except for the local-user denial of service, but local users can do
> "guix build -f something-that-allocates-almost-all-memory-and-melts-
> the-cpu.scm" anyway ...)
>
> If
Timothy Sample schreef op di 21-12-2021 om 11:36 [-0500]:
> + (limit (@ (name "auth_timeout")) "6")
Are there any good reasons for having a timeout at all?
(Except for the local-user denial of service, but local users can do
"guix build -f
Hi Leo,
Leo Famulari writes:
> On Tue, Dec 21, 2021 at 04:31:27AM -0500, Timothy Sample wrote:
>> [1] https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/NEWS#L2487
>> [2] https://bugs.freedesktop.org/show_bug.cgi?id=86431#c3
>>
>> After reading that I tried with the timeout bumped up to a
On Tue, Dec 21, 2021 at 04:31:27AM -0500, Timothy Sample wrote:
> [1] https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/NEWS#L2487
> [2] https://bugs.freedesktop.org/show_bug.cgi?id=86431#c3
>
> After reading that I tried with the timeout bumped up to a minute, and
> the X200 booted into GDM
I am using an X200 Tablet with an HDD. This happened on my system. I
am now on Fedora with Guix until this issue is fixed.
OpenPGP_0x42E4FDF80F03CA7C.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Hi Guillaume,
Guillaume Le Vaillant writes:
> I just got this login error when updating an old machine with a HDD as
> storage. On some other faster machines using SSD or NVME storage this
> issue never happened, so I thought the error might be triggered by
> slow IO.
>
> Do some of you also see
Hello Maxim and Ludovic,
Seeing all the new activity on this bug, I decided to take a closer
look.
It doesn't seem to me that the credential byte read is the problem, as
can be seen by the elogind strace: it sends
--8<---cut here---start->8---
374
Hello,
I am getting the same errors others have mentioned. I can't login via
tty and GDM wouldn't launch either. This happened after I pulled this
commit 73eb941b8b3793aec6110a4ae28bdbfc3ab4f6c5 with guix pull and ran
system reconfigure.
--
Abhiseck Paira
E34E 825B 979E EB9F 8505 F80E E93D
Hi Maxim,
I currently have this (very annoying) issue on _one_ of my machines (two
others work with nearly the same config).
I can't login at all not via console nor ssh or sddm.
I spend some time to reproduce it in a vm, but no success so far.
These are the relevant messages from syslog:
Dec 15
Hi Maxim!
Maxim Cournoyer skribis:
[...]
> Oh! Marius found this interesting issue [0] that they shared on IRC
> today; I wonder if it may be related. sd-bus apparently pipeline things
> aggressively, which is not always handled well by other D-bus
> participants.
>
> [0]
Hello!
Maxim Cournoyer skribis:
> 374 connect(11, {sa_family=AF_UNIX,
> sun_path="/var/run/dbus/system_bus_socket"}, 34) = 0
[...]
> 374 epoll_wait(5, [{events=EPOLLIN|EPOLLOUT|EPOLLHUP, data={u32=24802800,
> u64=24802800}}], 20, -1) = 1
> 374 sendmsg(11, {msg_name=NULL,
Hi,
Maxim Cournoyer skribis:
> Dec 7 15:55:02 localhost shepherd[1]: Service dbus-system has been started.
> [...]
> Dec 7 15:55:10 localhost shepherd[1]: Service ntpd has been started.
> [...]
> Dec 7 15:54:46 localhost ntpd[341]: ntpd 4.2.8p15@1.3728-o Thu Jan 1
> 12:00:01 AM UTC 1970
Hello,
Josselin Poiret writes:
> Maxim Cournoyer writes:
>
>> Hello,
>>
>> I've found a workaround: restarting elogind via SSH resolved the issue.
>>
>> I guess itt may be a race between elogind and dbus-system (elogind gets
>> started before dbus-system is fully up, and the communication with
Hi again,
Maxim Cournoyer writes:
[...]
> I noticed that dbus system session times out on every boot on that
> machine. I also notice that when the NTPD daemon starts, it rewinds
> time by about 25 s on every boot
Not NTP related; the same occurs when removing the ntp-service-type from
Hello!
Josselin Poiret writes:
> Maxim Cournoyer writes:
>
>> Hello,
>>
>> I've found a workaround: restarting elogind via SSH resolved the issue.
>>
>> I guess itt may be a race between elogind and dbus-system (elogind gets
>> started before dbus-system is fully up, and the communication with
Maxim Cournoyer writes:
> Hello,
>
> I've found a workaround: restarting elogind via SSH resolved the issue.
>
> I guess itt may be a race between elogind and dbus-system (elogind gets
> started before dbus-system is fully up, and the communication with the
> session bus is somehow crippled from
Hi,
Maxim Cournoyer skribis:
> Nov 24 21:23:58 localhost dbus-daemon[341]: [system] Activating service
> name='org.freedesktop.login1' requested by ':1.16' (uid=0 pid=324
> comm="/gnu/store/ximad0zvg12r4x0x80mvym8hzg0n33jl-shadow") (using
> servicehelper)
> Nov 24 21:23:58 localhost
Hello,
I've found a workaround: restarting elogind via SSH resolved the issue.
I guess itt may be a race between elogind and dbus-system (elogind gets
started before dbus-system is fully up, and the communication with the
session bus is somehow crippled from there?).
I'll experiment with the
Hello Josselin,
Josselin Poiret writes:
> Hello Maxim,
>
> Maxim Cournoyer writes:
>
>> --8<---cut here---start->8---
>> Nov 23 01:09:14 localhost dbus-daemon[383]: [system] Activating
>> service name='org.freedesktop.login1' requested by ':1.17' (uid=0
>>
Hello Maxim,
Maxim Cournoyer writes:
> --8<---cut here---start->8---
> Nov 23 01:09:14 localhost dbus-daemon[383]: [system] Activating service
> name='org.freedesktop.login1' requested by ':1.17' (uid=0 pid=370
>
Hello,
I'm not 100% sure this is the cause, but these are the last messages I
have before I rebooted:
--8<---cut here---start->8---
Nov 23 01:09:14 localhost dbus-daemon[383]: [system] Activating service
name='org.freedesktop.login1' requested by ':1.17'
29 matches
Mail list logo
