On 18 décembre 2014 11:27:28 HNEC, "Miguel Ortiz Lombardía" <miguel.ortizlombardia@laposte.net> wrote:
Hi,
Big thanks to Eddy (yes, I can read French :-) ), Michael and Bjørn for
your responses.
Just a note: in /etc/default/halt I already had:
HALT=poweroff
Having said that, great mystery: I touched nothing, and poweroff works
today... Well, this is actually what I did after reading your three
messages:
1/ Closed everything running (as I usually do before switching off the
computer) then run from a terminal (in gnome):
sudo halt -p
I had forgotten to unplug two external usb disks, the system went down
and tried to reboot, but it couldn't for these are not system disks.
This was kind of expected after these later days behaviour and having
made that mistake with respect to the external disks.
2/ Unplug the disks. Press the power button > complete power off, first
time from Monday. Surprise.
3/ Boot the machine from the same button. Log
ging
in, open a terminal,
write:
sudo halt -p
This also resulted in complete power off. Good.
4/ As 3/ but writing:
sudo poweroff
Also resulted in complete power off. Excellent.
5/ Repeated 3/ and 4/ after having plugged, then unplugged the external
disks. Again, both resulted in complete poweroff. Amazing.
6/ Boot the machine, logging in, work for a while and this time try to
power off from the gnome menu. To my complete astonishment, it did work...
Now, may the problem be related with something I do during my normal
work in the day (normally I switch on the laptop in the morning then off
in the evening) ? I don't think so, but I will now this evening, I suppose.
Thanks again !
Cheers,
Miguel
PS: I will unsubscribe and re-subscribe from a different address... My
email provider checks the DKIM signatures and because mailman seems to
break th
em, it
sends all DKIM-signed mail from the list to my spam
folder. Including my own posts ! Oh, dear, security will be the end of us.
Le 18/12/2014 10:26, Bjørn Mork a écrit :
Michael <michael.wordehoff@posteo.de> writes:
Edit /etc/default/halt and change the value as Eddy writes.
Yes, systemd is probably the cause, it replaced pm acpi by its own
terminology, disregarding the legacy convention.
Yes, systemd will happily break existing ACPI PM setups without any
warning.
The systemd point of view is that any breakage is caused by other
packages failing to detect that systemd is installed. Their
interpretation of "not breaking unrelated
software" is that any software
they break should detect that systemd is present and disable itself.
This systemd breakage is intentional, and any errors you experience is
entirely acpi-support's fault if you have configured it in such a way
that the disabling logic fails.
See https://bugs.debian.org/768025
if nothing else helps, replace systemd with systemd-shim emulation
(maybe also switching back to sysvinit).
This won't help. systemd-shim needs systemd to provide
e.g. systemd-logind and that's where the breakage is. You can disable
the systemd interference in this case by setting
HandlePowerKey=ignore
HandleSuspendKey=ignore
HandleHibernateKey=ignore
HandleLidSwitch=igno
re
in /etc/systemd/logind.conf
BTW, I have given up reporting systemd bugs. What's the point? The
Debian maintainers have inherited the upstream point-of-view: "If
something broke when you installed systemd, then that is someone else's
fault for not adapting properly to systemd". And "broken by design is a
feature".
Bjørn