Re: No halt/poweroff on an EliteBook 840 G1 after upgrade [solved?]
Hi again,
Just for completeness: the laptop went power off normally after a normal
day of work. No idea what my have triggered the odd behaviour from
Monday 15 to Wednesday 17, neither about what solved the issue today: I
haven't made any significant upgrade since Monday...
Thanks to all who proposed ideas, I've learnt something about systemd.
Cheers,
Miguel
El 18/12/14 a las 11:27, Miguel Ortiz Lombardía escribió:
> 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: