6

After upgrading to debian jessie my dated desktop system no longer powers off reliably (/sbin/poweroff - via systemctl on tty1). Instead, it shuts down, pauses and reboots and only powers off if I press the power-button. I tried various recommendations like acpi=force playing with bios settings, adding nouveau.modeset=0 and many more.

The only thing I found so far, is that not starting a graphical session seems to "fix" the problem. My Xsession is a simple .xsession file, there is no session manager involved (afaik) and all I do is start a number of programs. When I strip this file down to just an xterm or I do not log in at all, the system powers down.

I tried to uncomment more programs in my .xsession file in the hope of finding a culprit, but this did not lead to a conclusion. There seems to be some randomness involved. I am sure than none of my programs are still runnig at the time I issue the poweroff because I kill them all (uncluding a user systemd which was started by I-dont-know-who)

In the last messages before it reboots I see

System wakeup enabled by ACPI
Preparing to enter systel sleep state 5
GPU lockup - switching to software fbcon

But I see the same messages when it does poweroff (not 100% sure, because they are visible only for a short moment then)

Also I notice that in the bad cases, there are long pauses in the shutdown process, e.g. after Stopping target network there is like a 2-minute pause and I don't know what the system is waiting for.

What I am after is a way to diagnose the problem, rather than shooting at the moon.

  • How can I find out what the system is waiting for in those long pauses
  • Or more generally: how can I get more information about what's going on during shutdown, is there a "shutdown log"?
  • How is acpi involved in the shutdown process and how can I find out why it is doing what it is doing?
Improve this question
3
  • 1
    Trick to read messages only visible for a short while (other than a serial console, which is hard if your laptop doesn't have serial ports—and I'm sure it doesn't): use a cell phone (etc.) camera to take a video of the screen. Then you can pause the video to read messages that are only there for a fraction of a second.
    – derobert
    Oct 13, 2015 at 19:25
  • Have you tried the steps described in the section "Diagnosing Shutdown Problems" in Debugging systemd?
    – Timothée Ravier
    Jul 8, 2017 at 11:44
  • Some Intel chipsets (IvyBridge/Haswell or about that time) had a quirky USB3 XHCI controller: if the XHCI controller was not shut down properly, it would cause the system to restart after power-down. The quirk even was subtly different in various versions of the chipset, so pinning down the required shutdown procedure in each case was quite tricky. See bug #66171 in Linux kernel bugzilla.
    – telcoM
    Apr 13, 2019 at 9:44

1 Answer 1

Reset to default
1

I had the same issue on two different systems, albeit with Wheezy.

The solutions were different:

Solution 1

Blacklisting the kernel module mei_me (Intel Management Engine) fixed the issue on one machine.

Solution 2

On another machine it was a pm-utils issue, try to write on to /sys/bus/*/devices/*/power/control and shutdown.

Source: https://askubuntu.com/questions/132882/why-do-i-get-a-reboot-instead-of-a-shutdown

Improve this answer
1
  • INTEL_MEI is set to "No" in my kernel config. And I don't have any "control" files in /sys/bus/*/devices/*/power/. I don't think this is it.
    – Martin Drautzburg
    Oct 13, 2015 at 19:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .