0

I have a problem with shutting down my systems. When I shutdown my laptop everything looks normal but after few seconds it powers on by itself. I tried to shut it down through terminal with "shutdown -h now" and it worked but only on Arch in Ubuntu with "shutdown -hH now" or "shutdown -H now" it hangs on spash screen. I also looked for some "wake on LAN" BIOS entries (as those are mentioned to cause that problem) but I don't have those.

How can I fix my distros to be able to shutdown distros form DE's menu without using terminal ?

Improve this question
3
  • That's typically a problem with ACPI tables. What exact model of laptop do you have? What kernels do you run on the working distribution and on the non-working one?
    – Gilles 'SO- stop being evil'
    Aug 9, 2014 at 22:31
  • It's kind of strange because it looks like shutdown works fine while the power cord in connected but on battery not so much. So what didn't fix it was this and this and what did (at least for the moment) was removing from GRUB_CMDLINE_LINUX_DEFAULT= something like this: "quiet resume=UUID=6gwe72ic-3alp..." (I've overriten grub file so I can't quote it exactly) and simply replaced it with "quiet splash"...
    – banuy
    Aug 10, 2014 at 3:14
  • @banuy You broke hibernation and didn't even fix your problem really. Don't do that.
    – wizzwizz4
    Mar 26, 2019 at 18:17

2 Answers 2

Reset to default
0

On your hardware, it is possible that this is not supported via an OS interface. THus when you shutdown it reboots. I have run into this many times.

BTW, have you tried 'init 0' instead of shutdown?

The other thing I'd be looking is a BIOS option addressing this. All the BIOS makers are a little different, so I cannot provide a canned answer.

Improve this answer
2
  • depending on distro, you might have to use telinit 0 instead of init 0.
    – Dani_l
    Aug 9, 2014 at 22:21
  • init 0 does the same thing as shutdown -h now.
    – Gilles 'SO- stop being evil'
    Aug 9, 2014 at 22:30
0

Some Intel Ivy Bridge and Haswell chipsets included an XHCI USB3 controller version that needs to be shut down in a very specific way, or else it will just power on the system again after a few seconds.

The trouble is, the specific way is different for different versions of the chipsets, and the shutdown procedure that fixes the problem for one chipset version will actually cause it for another version.

Because the system firmware will in most cases start up the XHCI controller to probe for USB keyboards and mice, blacklisting the xhci_hcd driver will not help in this cause, and might in fact make the problem worse.

https://bugzilla.kernel.org/show_bug.cgi?id=66171

If you have this problem and a system with a chipset of this era, you might try adding one of these kernel module options to /etc/modprobe.d/xhci.conf:

options xhci-hcd quirks=270336 

options xhci-hcd quirks=8192

options xhci-hcd quirks=262144

Try just one of these lines at a time. The correct quirks value will depend on the exact chipset version your system has.

Improve this answer

You must log in to answer this question.

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