On 17/01/14 06:29, Andreas Cadhalpun wrote:
Hi,
On 16.01.2014 11:33, iiNET wrote:
Just installed a new laptop with Jessie testing and found that suspend
events do not trigger suspend action.
Looking through the threads of the included bugs reports there seems
to be a bit of an overlap so I've CC'ed you all in.
Have you tried installing systemd-shim or systemd-sysv?
A bit of investigation found that the acpi-support-base scripts have a
small problem, With the 'su' is in place a call to CheckPolicy from a
non root account prompts for a password. The following patch fixed the
password prompt and allowed suspend to initiate.
--- /usr/share/acpi-support/policy-funcs.orig 2014-01-16
19:24:48.828610060 +1100
+++ /usr/share/acpi-support/policy-funcs 2014-01-16
19:25:31.169186162 +1100
@@ -44,7 +44,7 @@
test -r /proc/$p/environ || continue
DBUS_SESS=$(grep -a -z "DBUS_SESSION_BUS_ADDRESS="
/proc/$p/environ || :)
test "$DBUS_SESS" != "" || continue
- su $(ps -o user= $p) -s /bin/sh -c "$DBUS_SESS dbus-send
--print-reply --dest='$DEST' '$DBUS_PATH' '$METHOD'"
+ $DBUS_SESS dbus-send --print-reply --dest='$DEST' '$DBUS_PATH'
'$METHOD'
done
}
The pacth allows the lid to initiate and complete a suspend, the problem
now is the power button issues a shutdown. gnome-tweak-tool suggests
that the power button is set to suspend ( this could be a problem with
my gnome profile though ).
This patch does not change anything for me. Suspend on lid close works with
systemd-shim | systemd-sysv and does not work without one of those installed.
I'm guessing that sysvinit and systemd-sysv, have a side effect of setting up a
difference power management paths.
Installing systemd-sysv, fixes lid and power button suspend. However when the
machine boots, the root file system is mounted read only thus gdm3 does not
start. Running 'mount / -o remount,rw' allows the startup to continue and gdm3
will start.
Installing upstart, hangs the boot process consistently at "Starting
acpi_fakekey...done."
Installing systemd-shim, seems to of given the best result. Lid and power
button suspend/resume working, and system boots:)
Best regards,
Andreas
I think there needs to be some decisions made by the sysvinit package
maintainers on what the preferred init path is.
My install was a vanilla install using the daily disk builds at:
http://d-i.debian.org/daily-images/amd64/daily/netboot/debian-installer/amd64/
From the the install logs the sysvinit package prefers sysvinit-core:
Jan 15 03:35:33 debootstrap: sysvinit pre-depends on sysvinit-core | upstart |
systemd-sysv
Jan 15 03:35:33 debootstrap: dpkg: regarding .../sysvinit_2.88dsf-45_amd64.deb
containing sysvinit, pre-dependency problem:
Jan 15 03:35:33 debootstrap: sysvinit pre-depends on sysvinit-core | upstart |
systemd-sysv
Jan 15 03:35:33 debootstrap: sysvinit-core is not installed.
Jan 15 03:35:33 debootstrap: upstart is not installed.
Jan 15 03:35:33 debootstrap: systemd-sysv is not installed.
Jan 15 03:35:33 debootstrap:
Jan 15 03:35:33 debootstrap: dpkg: warning: ignoring pre-dependency problem!
Jan 15 03:35:33 debootstrap: Preparing to unpack
.../sysvinit_2.88dsf-45_amd64.deb ...
Jan 15 03:35:33 debootstrap: Unpacking sysvinit (2.88dsf-45) ...
Jan 15 03:35:33 debootstrap: Selecting previously unselected package
sysvinit-core.
Jan 15 03:35:33 debootstrap: Preparing to unpack
.../sysvinit-core_2.88dsf-45_amd64.deb ...
Jan 15 03:35:33 debootstrap: Unpacking sysvinit-core (2.88dsf-45) ...
Jan 15 03:35:33 debootstrap: Selecting previously unselected package
sysvinit-utils.
Jan 15 03:35:33 debootstrap: Preparing to unpack
.../sysvinit-utils_2.88dsf-45_amd64.deb ...
Jan 15 03:35:33 debootstrap: Unpacking sysvinit-utils (2.88dsf-45) ...
Hope this helps,
Darren
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org