On Tue, 5 Mar 2019 23:39:00 +0100
Michael Biebl wrote:
> Strictly speaking, we should only need either --notify-await when
> starting the daemon via s-s-d, or --wait-daemon when calling udevadm
> trigger. Using both probably doesn't hurt, but isn't really necessary.
correct, actually only the
Am 05.03.19 um 22:40 schrieb Trek:
> On Tue, 5 Mar 2019 09:46:53 +0100
> Andreas Henriksson wrote:
>
>> You likely also want to include in your patch a debian/control
>> change that makes udev depend on a new enough dpkg which has the
>> new flags you're making use of.
>
> right, a new patch is
On Tue, 5 Mar 2019 09:46:53 +0100
Andreas Henriksson wrote:
> You likely also want to include in your patch a debian/control
> change that makes udev depend on a new enough dpkg which has the
> new flags you're making use of.
right, a new patch is attached
thank you!diff --git a/debian/control
Hello Trek,
On Mon, Mar 04, 2019 at 08:47:41PM +0100, Trek wrote:
> Control: tag -1 patch
>
> hello,
>
> the new dpkg version finally landed to testing, so I send you a little
> patch to enable both --notify-await and --wait-daemon options
>
> this patch was tested against dpkg 1.19.5 and udev
Control: tag -1 patch
hello,
the new dpkg version finally landed to testing, so I send you a little
patch to enable both --notify-await and --wait-daemon options
this patch was tested against dpkg 1.19.5 and udev 241-1 (unstable)
all is running fine! (boot and shutdown)
I would say a big
On Fri, 25 Jan 2019 19:14:54 -0800
Bill Brelsford wrote:
> It works with a 2-second sleep inserted before the udevadm call.
> Sounds familiar..
too much familiar.. :)
well, at least we found this patch is absolutely useless regarding this
issue
hopefully it seems dpkg version 1.19.3 will
With the tests removed, it builds and installs successfully. But
during boot,
udevadm trigger --type=subsystems --action=add --wait-daemon
fails with something like
Failed to connect to udev daemon (connection refused).
It works with a 2-second sleep inserted before the
On Thu, 24 Jan 2019 19:02:54 -0800
Bill Brelsford wrote:
> Thanks for the build instructions, Trek. However, dpkg-buildpackage
> fails (at test-condition, line 4259 in attached trace file).
to workaround these @#!%^&* tests, you should go in the systemd-240
directory and type as user:
sed
On Tue, 22 Jan 2019 18:21:43 -0800
Bill Brelsford wrote:
> I'm still using version 1.19.2+test2 of dpkg, but without udev's
> --wait-daemon argument. The next dpkg (1.19.3) will handle
> --wait-daemon; I assume including it in udev will fix the problem..?
these are two independent ways to fix
On Mon Jan 21 2019 at 07:14 AM -0800, Bill Brelsford wrote:
> On Mon Jan 21 2019 at 08:36 AM +0100, Trek wrote:
> > @Bill Brelsford: is the problem gone with the 240-4 version? if not,
> > can you test udev with these patches applied? thanks!
>
> Yes, 240-4 fixed the problem.
Well, not quite --
On Mon Jan 21 2019 at 08:36 AM +0100, Trek wrote:
> @Bill Brelsford: is the problem gone with the 240-4 version? if not,
> can you test udev with these patches applied? thanks!
Yes, 240-4 fixed the problem. Thanks Trek, Michael and others who
helped resolve it!
Regards.. Bill
On Mon, 21 Jan 2019 08:36:51 +0100
Trek wrote:
> and the one in the attach
missed, sorry
attached to this message--- udev.init.orig 2019-01-12 21:49:44.0 +0100
+++ udev.init 2019-01-21 01:54:51.047997585 +0100
@@ -178,7 +178,7 @@
fi
log_action_begin_msg "Synthesizing the
On Sun, 13 Jan 2019 20:11:04 +0100
Michael Biebl wrote:
> Can you test https://github.com/systemd/systemd/pull/11349
I have built and tested udev 240-4 with these patches:
https://github.com/systemd/systemd/commit/3797776e11d2a242517c3a20a953b5d0e80384f8.patch
On Sun, 13 Jan 2019 20:11:04 +0100
Michael Biebl wrote:
> Can you test https://github.com/systemd/systemd/pull/11349
I've just figured out how to download the patch from github
I assume that you would apply this patch
On Wed, 9 Jan 2019 15:05:38 +0100 Trek wrote:
> if dpkg will not be updated with the new sd-notify interface, I think
> it would be better to rollback the #791944 patch: the system will not
> shutdown correctly with cryptsetup, but at least it can boot (with and
> without cryptsetup)
Can you
Version: 240-2
after upgrading from 239-13 to 240-2, the VGA card is no more
recognized on my system, but adding a small sleep fixes the problem
if dpkg will not be updated with the new sd-notify interface, I think
it would be better to rollback the #791944 patch: the system will not
shutdown
Hi,
is there any blocking to fix this bug? can I help in some way?
this is nearly a release critical bug, as it "makes unrelated software
on the system break" (cryptsetup) and "the whole system" (some system
don't boot)
if dpkg can't be upgraded before the freeze, can we add a workaround to
the
On Tue, 16 Oct 2018 22:26:40 +0200
Michael Biebl wrote:
> > to Guilhem Moulin: I made a little patch because the socket
> > permissions seems to be wrong when --chuid is specified
> I think you meant Guillem (our dear dpkg maintainer) here?
yes, I'm sorry, please Guillem Jover can you check
Am 16.10.18 um 22:24 schrieb Trek:
> good job!
>
> with cryptsetup the new patches are running fine
>
> thank you to every one!
>
> to Guilhem Moulin: I made a little patch because the socket permissions
> seems to be wrong when --chuid is specified
I think you meant Guillem (our dear dpkg
good job!
with cryptsetup the new patches are running fine
thank you to every one!
to Guilhem Moulin: I made a little patch because the socket permissions
seems to be wrong when --chuid is specified
ciao :)>From 67d080cc7c195f1a34cb6a0dc7ac7a5d9dbad28d Mon Sep 17 00:00:00 2001
From: Trek
On Mon Oct 15 2018 at 12:19 AM +0200, Michael Biebl wrote:
> I was a bit too eager. The sd-notify support in dpkg was not quite ready
> yet. The dpkg maintainer has improved the code.
> Could you test again with version 1.19.2+test2,
This one fixes it (3 successful boots so far). Thanks,
Am 11.10.18 um 01:00 schrieb Bill Brelsford:
> On Wed Oct 10 2018 at 09:03 PM +0200, Michael Biebl wrote:
>> I've compiled a dpkg test package from this branch [1].
>> Bill, it would be great if you can install this dpkg package and try it
>> along with the attached patch for the udev init script.
On Wed Oct 10 2018 at 09:03 PM +0200, Michael Biebl wrote:
> I've compiled a dpkg test package from this branch [1].
> Bill, it would be great if you can install this dpkg package and try it
> along with the attached patch for the udev init script.
I installed your new dpkg and patched the udev
Am 10.10.18 um 22:28 schrieb Bill Brelsford:
> On Wed Oct 10 2018 at 09:03 PM +0200, Michael Biebl wrote:
>> I've compiled a dpkg test package from this branch [1].
>> Bill, it would be great if you can install this dpkg package and try it
>> along with the attached patch for the udev init script.
Am 10.10.18 um 21:00 schrieb Michael Biebl:
> I quickly looked at the branch, and noticed a a few typos. Patch attached.
^^^
oh the irony :-)
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from
On Wed Oct 10 2018 at 09:03 PM +0200, Michael Biebl wrote:
> Am 10.10.18 um 09:37 schrieb Guillem Jover:
> > Hah, this is already almost implemented. Was planning on finishing the
> > couple of XXX (including setting the envvar) and docs, testing and
> > merging it for 1.19.3 or so (targeted at 1w
Am 10.10.18 um 09:37 schrieb Guillem Jover:
> Hah, this is already almost implemented. Was planning on finishing the
> couple of XXX (including setting the envvar) and docs, testing and
> merging it for 1.19.3 or so (targeted at 1w or 2w from now). :)
>
>
>
On Wed, 10 Oct 2018 11:10:38 -0300 Felipe Sateler
wrote:
> Awesome. This should help a lot.
This is great indeed, thanks Guillem!
I quickly looked at the branch, and noticed a a few typos. Patch attached.
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in
(Dropping original bug, adding cloned bug, full quote for context)
On Wed, Oct 10, 2018 at 4:38 AM Guillem Jover wrote:
> Hi!
>
> On Tue, 2018-10-09 at 22:01:21 -0300, Felipe Sateler wrote:
> > Control: clone -1 -2
> > Control: retitle -2 start-stop-daemon: please implement service
> readiness
Hi!
On Tue, 2018-10-09 at 22:01:21 -0300, Felipe Sateler wrote:
> Control: clone -1 -2
> Control: retitle -2 start-stop-daemon: please implement service readiness
> protocol
> Control: severity -2 wishlist
> On Sun, Sep 30, 2018 at 8:15 PM Michael Biebl wrote:
> > The only supported way in
Control: clone -1 -2
Control: retitle -2 start-stop-daemon: please implement service readiness
protocol
Control: severity -2 wishlist
On Sun, Sep 30, 2018 at 8:15 PM Michael Biebl wrote:
>
> The only supported way in udev to signal readiness is the sd-notify API.
> My gut feeling is, that
On Tue Oct 09 2018 at 08:29 PM +0200, Michael Biebl wrote:
> On Mon, 1 Oct 2018 13:20:47 -0700 Bill Brelsford wrote:
> > On Mon Oct 01 2018 at 06:45 AM +0200, Trek wrote:
> > > to Bill Brelsford: please, can you try again if this new patch fixes the
> > > problem? thank you!
> >
> > No --
On Sun, 7 Oct 2018 23:49:57 +0200 Trek wrote:
> On Sun, 7 Oct 2018 01:57:31 +0200
> Michael Biebl wrote:
>
> > > - We tweak the LSB headers to make sure the udev init script is
> > > called before sendsigs on shutdown. This is important!
> >
> > I have to add, that this change has the
On Mon, 1 Oct 2018 13:20:47 -0700 Bill Brelsford wrote:
> On Mon Oct 01 2018 at 06:45 AM +0200, Trek wrote:
> > to Bill Brelsford: please, can you try again if this new patch fixes the
> > problem? thank you!
>
> No -- $CTRLFILE must already be there as it doesn't sleep ($timeout
> stays at
On Sun, 7 Oct 2018 01:57:31 +0200
Michael Biebl wrote:
> > - We tweak the LSB headers to make sure the udev init script is
> > called before sendsigs on shutdown. This is important!
>
> I have to add, that this change has the potential to significantly
> change the shutdown order or cause a
Am 07.10.18 um 01:57 schrieb Michael Biebl:
> Am 07.10.18 um 01:06 schrieb Michael Biebl:
>
>> We change the init script as follows:
>> - We revert most the changes from #791944, we only keep the stop
>> symlinks for rc0 and rc6 and the cleanup of /run/udev/control file on stop.
>> - We tweak the
Am 07.10.18 um 01:06 schrieb Michael Biebl:
> We change the init script as follows:
> - We revert most the changes from #791944, we only keep the stop
> symlinks for rc0 and rc6 and the cleanup of /run/udev/control file on stop.
> - We tweak the LSB headers to make sure the udev init script is
Am 05.10.18 um 10:25 schrieb Trek:
> On Thu, 4 Oct 2018 21:58:38 +0200
> Michael Biebl wrote:
>
>>> 1) revert the 791944 patch, create a new init.d/udev-clear script to
>>> remove the control file and run it just after sendsigs (this will
>>> restore the old well tested behavior)
>>
>> The
On Thu, 4 Oct 2018 21:58:38 +0200
Michael Biebl wrote:
> > 1) revert the 791944 patch, create a new init.d/udev-clear script to
> > remove the control file and run it just after sendsigs (this will
> > restore the old well tested behavior)
>
> The removal of the control file should be bound to
Am 03.10.18 um 13:20 schrieb Trek:
>
> thanks to Bill Brelsford, the last test confirmed we are in the worst
> situation: udev is running, the control file is created, but udev is
> not ready to listen new events
>
> so we must to rethink about the 791944 bug: it was caused because udev
> no
thanks to Bill Brelsford, the last test confirmed we are in the worst
situation: udev is running, the control file is created, but udev is
not ready to listen new events
so we must to rethink about the 791944 bug: it was caused because udev
no longer removes the control file on stop
we have at
On Mon Oct 01 2018 at 06:45 AM +0200, Trek wrote:
> to Bill Brelsford: please, can you try again if this new patch fixes the
> problem? thank you!
No -- $CTRLFILE must already be there as it doesn't sleep ($timeout
stays at 150).
(Even so, it worked consistently for a number of boots, then began
On Mon, 1 Oct 2018 01:11:30 +0200
Michael Biebl wrote:
> The only supported way in udev to signal readiness is the sd-notify
> API. My gut feeling is, that having an sd-notify wrapper for
> non-systemd systems (e.g. directly built into start-stop-daemon via
> say an --wait-for-sd-notify switch)
Am 01.10.18 um 00:55 schrieb Trek:
> On Sat, 29 Sep 2018 18:41:45 +0200
> Michael Biebl wrote:
>
>>> +# wait for udev to be ready (see #908796)
>>> +timeout=15
>>> +until udevadm control -S || [ $timeout -le 0 ]; do
>>> +timeout=$((timeout-1))
>>> +
On Sat, 29 Sep 2018 18:41:45 +0200
Michael Biebl wrote:
> > +# wait for udev to be ready (see #908796)
> > +timeout=15
> > +until udevadm control -S || [ $timeout -le 0 ]; do
> > +timeout=$((timeout-1))
> > +sleep 1
> > +done
> > +
Hi Trek,
thanks for the patch
Am 15.09.18 um 06:28 schrieb Trek:
> +
> +# wait for udev to be ready (see #908796)
> +timeout=15
> +until udevadm control -S || [ $timeout -le 0 ]; do
> +timeout=$((timeout-1))
> +sleep 1
> +done
> +
On Thu, 13 Sep 2018 19:02:26 -0700
Bill Brelsford wrote:
> With the --background argument, a race condition exists and
> "udevadm trigger" starts too soon.
> A workaround is to add a short sleep:
can you try if this patch fixes the problem?
my system is not affected so I can't check
thank you!
On Sat Sep 15 2018 at 06:28 AM +0200, Trek wrote:
> On Thu, 13 Sep 2018 19:02:26 -0700
> Bill Brelsford wrote:
>
> > With the --background argument, a race condition exists and
> > "udevadm trigger" starts too soon.
> > A workaround is to add a short sleep:
>
> can you try if this patch fixes
Package: udev
Version: 239-9
Severity: important
After upgrading udev to 239-8, most devices are no longer detected
during boot (e.g. usb, network card, video, ..). The problem
appears to be caused by /etc/init.d/udev now using
start-stop-daemon (thanks Sven Joachim for pointing me there).
With
49 matches
Mail list logo
