Hi,
On Wed, 05 Jan 2022 at 00:21, zimoun wrote:
> On Fri, 26 Nov 2021 at 18:21, Mark H Weaver wrote:
>>> On Mon, 12 Nov 2018 at 20:09, Mark H Weaver wrote:
>>>
As I write this, there are two system test builds that have been stuck
for many hours, endlessly printing "shepherd[1]: waiti
Hi Mark,
CC: Mathieu, maybe they have an insight for Cuirass.
On Fri, 26 Nov 2021 at 18:21, Mark H Weaver wrote:
>> On Mon, 12 Nov 2018 at 20:09, Mark H Weaver wrote:
>>
>>> As I write this, there are two system test builds that have been stuck
>>> for many hours, endlessly printing "shepherd[1
Hi Simon,
zimoun writes:
> On Mon, 12 Nov 2018 at 20:09, Mark H Weaver wrote:
>
>> As I write this, there are two system test builds that have been stuck
>> for many hours, endlessly printing "shepherd[1]: waiting for udevd...":
>>
>> https://hydra.gnu.org/build/3153725
>> https://hydra.gnu
Hi Mark,
On Mon, 12 Nov 2018 at 20:09, Mark H Weaver wrote:
> As I write this, there are two system test builds that have been stuck
> for many hours, endlessly printing "shepherd[1]: waiting for udevd...":
>
> https://hydra.gnu.org/build/3153725
> https://hydra.gnu.org/build/3154365
>
> The
I just found that 4 out of 6 Intel build slots on Hydra have been
occupied for the last 10+ hours on more instances of this bug:
https://hydra.gnu.org/build/3281985
https://hydra.gnu.org/build/3281874
https://hydra.gnu.org/build/3281957
https://hydra.gnu.org/build/3281830
I killed these j
I found two more instances of this problem, in evaluation 110355:
https://hydra.gnu.org/build/3253071
https://hydra.gnu.org/build/3252182
I killed these jobs, and cancelled all pending 'test.*' jobs.
Mark
In recent evaluations of 'master', there have been two more instances of
this problem occurring, on x86_64 and i686:
https://hydra.gnu.org/build/3252398 (from eval 110355, commit 08861d25)
https://hydra.gnu.org/build/3225361 (from eval 110351, commit 69f867b1)
I aborted these jobs.
M
Hmm, I wonder whether it might make sense to add "--debug" to udevd in
gnu/services/base.scm in order to track down this problem.
The loop looks rather harmless and only checks whether the actual udev socket
is available - which it must be for udevd to work.
It does the following right now:
Mark H Weaver writes:
> Mark H Weaver writes:
>
>> As I write this, there are two system test builds that have been stuck
>> for many hours, endlessly printing "shepherd[1]: waiting for udevd...":
>>
>> https://hydra.gnu.org/build/3153725
>> https://hydra.gnu.org/build/3154365
>>
>> They are
Hi Mark,
Mark H Weaver skribis:
> As I write this, there are two system test builds that have been stuck
> for many hours, endlessly printing "shepherd[1]: waiting for udevd...":
Basic system tests pass for me on current-ish ‘core-updates’, on x86_64:
--8<---cut here---
Mark H Weaver writes:
> As I write this, there are two system test builds that have been stuck
> for many hours, endlessly printing "shepherd[1]: waiting for udevd...":
>
> https://hydra.gnu.org/build/3153725
> https://hydra.gnu.org/build/3154365
>
> They are both on i686-linux, and on the 'c
As I write this, there are two system test builds that have been stuck
for many hours, endlessly printing "shepherd[1]: waiting for udevd...":
https://hydra.gnu.org/build/3153725
https://hydra.gnu.org/build/3154365
They are both on i686-linux, and on the 'core-updates' branch, but with
two di
12 matches
Mail list logo
