On Thu, 2015-05-28 at 17:28 +0200, sfr...@googlemail.com wrote:
Hi,
i've experienced the problem minutes ago after a d-u (qcontrol 0.5.4-2).
And i found the problem:
In /etc/qcontrol.conf i had the line
register(evdev, /dev/input/by-path/platform-gpio-keys-event,
408,
Hi,
i've experienced the problem minutes ago after a d-u (qcontrol 0.5.4-2).
And i found the problem:
In /etc/qcontrol.conf i had the line
register(evdev, /dev/input/by-path/platform-gpio-keys-event,
408, restart_button,
133, media_button)
while:
# ls /dev/input/by-path/
On Thu, 2015-04-16 at 09:53 +0200, Michael Stapelberg wrote:
I can’t recall seeing this (qcontrol works fine on my qnaps) and I
don’t have time to debug this, sorry.
No problem, I'll keep digging and hit up pkg-systemd lists for help.
Ian.
--
To UNSUBSCRIBE, email to
On Thu, Apr 16, 2015 at 10:21:06 +0100, Ian Campbell wrote:
BTW, when this fails the system still booted and you could login and fix
it, i.e. it didn't stall the boot or anything, is that right? If that is
the case a release note might be the most plausible action at this
point.
When I saw
I can’t recall seeing this (qcontrol works fine on my qnaps) and I don’t
have time to debug this, sorry.
On Wed, Apr 15, 2015 at 10:09 PM, Ian Campbell i...@debian.org wrote:
On Wed, 2015-04-15 at 21:07 +0200, Michael Stapelberg wrote:
I’ve added the systemd service files manually
On Wed, Apr 15, 2015 at 19:19:24 +0100, Ian Campbell wrote:
@reportbug (sorry I don't seem to know your real name), could you try
adding a call to udev settle to the qcontrold initscript, in the start
case right before the daemon is launched (I can be more specific if you
need).
Hi. It pains
On Thu, Apr 16, 2015 at 10:36:32 +0100, Ian Campbell wrote:
On Thu, 2015-04-16 at 11:28 +0200, reportbug wrote:
But I did have one occasion where one out of my 3 qnaps repeatedly failed
to
boot after the latest kernel update (or at least the latest flash-kernel
trigger, maybe it was
On Thu, 2015-04-16 at 10:28 +0200, reportbug wrote:
On Wed, Apr 15, 2015 at 19:19:24 +0100, Ian Campbell wrote:
@reportbug (sorry I don't seem to know your real name), could you try
adding a call to udev settle to the qcontrold initscript, in the start
case right before the daemon is
On Thu, 2015-04-16 at 11:28 +0200, reportbug wrote:
On Thu, Apr 16, 2015 at 10:21:06 +0100, Ian Campbell wrote:
BTW, when this fails the system still booted and you could login and fix
it, i.e. it didn't stall the boot or anything, is that right? If that is
the case a release note might be
Hi,
Am 14.04.2015 um 21:56 schrieb Michael Stapelberg:
On Tue, Apr 14, 2015 at 8:59 PM, Ian Campbell i...@debian.org wrote:
On Tue, 2015-04-14 at 10:02 +0200, Michael Stapelberg wrote:
Apr 02 12:08:28 hostname systemd[1]: Started LSB: Start
qcontrol daemon.
This line in
On Wed, 2015-04-15 at 17:35 +0200, Michael Biebl wrote:
[...]
pkg-systemd-maintainers, see above: is there a way to wait for udev devices
to be available? What’s the current take on udev-settle, would that be a
reasonable workaround for this situation?
Possible solutions, in order of
On Tue, 2015-04-14 at 10:02 +0200, Michael Stapelberg wrote:
Ian, it seems like you should be following
https://wiki.debian.org/systemd/Packaging#Using_debhelper_with_dh_systemd to
get the package to properly pick up the systemd service files
I tried this (in preparation for the changes I
On Wed, Apr 15, 2015 at 8:39 PM, Ian Campbell i...@debian.org wrote:
On Tue, 2015-04-14 at 10:02 +0200, Michael Stapelberg wrote:
Ian, it seems like you should be following
https://wiki.debian.org/systemd/Packaging#Using_debhelper_with_dh_systemd
to get the package to properly pick up the
On Wed, 2015-04-15 at 21:07 +0200, Michael Stapelberg wrote:
I’ve added the systemd service files manually on my qnaps
before I
contributed them upstream, hence I never ran into this
issue.
What did you do manually? Does it match what I
On Sat, Apr 4, 2015 at 3:43 PM, Ian Campbell i...@debian.org wrote:
On Sat, 2015-04-04 at 14:48 +0200, reportbug wrote:
Package: qcontrol
Version: 0.5.4-1
Severity: normal
After a recent wheezy-jessie upgrade, I noticed that qcontrol sometimes
fails to start on boot (or qcontrold?
On Tue, 2015-04-14 at 10:02 +0200, Michael Stapelberg wrote:
Apr 02 12:08:28 hostname systemd[1]: Started LSB: Start
qcontrol daemon.
This line in the logfile indicates that systemd is using the sysvinit
script (hence the “LSB: ” prefix) of qcontrold, not the native
[+cc pkg-systemd-maintainers]
On Tue, Apr 14, 2015 at 8:59 PM, Ian Campbell i...@debian.org wrote:
On Tue, 2015-04-14 at 10:02 +0200, Michael Stapelberg wrote:
Apr 02 12:08:28 hostname systemd[1]: Started LSB: Start
qcontrol daemon.
This line in the logfile indicates
On Sat, 2015-04-04 at 14:48 +0200, reportbug wrote:
Package: qcontrol
Version: 0.5.4-1
Severity: normal
After a recent wheezy-jessie upgrade, I noticed that qcontrol sometimes
fails to start on boot (or qcontrold? not sure what the difference is).
qcontrold starts the qcontrol daemon at
Package: qcontrol
Version: 0.5.4-1
Severity: normal
After a recent wheezy-jessie upgrade, I noticed that qcontrol sometimes
fails to start on boot (or qcontrold? not sure what the difference is).
I noticed this because on one QNAP TS-419, journalctl -f seemed to log
temperatures occasionally,
On Sat, Apr 04, 2015 at 14:43:23 +0100, Ian Campbell wrote:
On Sat, 2015-04-04 at 14:48 +0200, reportbug wrote:
[...]
Apr 02 12:08:28 hostname qcontrol[617]: qcontrol 0.5.4 daemon starting.
Apr 02 12:08:28 hostname qcontrold[480]: Starting qcontrol daemon: qcontrol.
Apr 02 12:08:28
20 matches
Mail list logo
