Re: No halt/poweroff on an EliteBook 840 G1 after upgrade [solved?]
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. Logging 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 them, 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=ignore
>
> 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
>
>
Reply to: