Andreas
I just re-installed an older Dell E6400 laptop which results in similar suspend
issue. Installing systemd-sysv on the old laptop fixes suspend.
Read below for the solution to the mount problem reported earlier, seems to be
an issue with me trying to preserve my home directory.
Let me know if there is any testing you would like me to do.
On 17/01/14 10:07, Andreas Cadhalpun wrote:
Hi,
On 16.01.2014 23:20, Darren Williams wrote:
I'm guessing that sysvinit and systemd-sysv, have a side effect of
setting up a difference power management paths.
As far as I understand it, systemd-sysv provides a certain set of dbus services
for power management, that sysvinit has not, but that can be provided by
systemd-shim on top of sysvinit (or upstart).
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.
This seems to be broken on your system. I don't have such issues using
systemd-sysv.
Installing upstart, hangs the boot process consistently at "Starting
acpi_fakekey...done."
Again it seems something on your machine is badly broken. I switched often
between sysvinit-core/systemd-sysv/upstart and did not experience these
problems.
Found the error here, fstab did not have any mount lines only the single line:
# UNCONFIGURED FSTAB FOR BASE SYSTEM
this could be a side effect of me trying to preserve my home dir which sits on
the root partition. During the install I delete all the files and directories
except for home (Yeah, I know, one should partition better). After adding the
appropriate fstab mount entires systemd-sysv boots and also fixes Lid and power
button suspend/resume.
Could you provide some logs (e.g. /var/log/syslog), or even better, a way to
reproduce this on a fresh install?
Installing systemd-shim, seems to of given the best result. Lid and
power button suspend/resume working, and system boots:)
At least this works for you. :)
I think there needs to be some decisions made by the sysvinit package
maintainers on what the preferred init path is.
Do you mean that Debian needs to decide what the default init system should be?
This is currently discussed as bug #727708 [1].
Exactly, at least they are discussing the issue.
Best regards,
Andreas
1: http://bugs.debian.org/727708
Thanks for your help
Darren
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
