system does not power off on “poweroff”, just halts












11














I've installed Xubuntu 15.04 on a Lenovo IdeaCentre A740 QHD with a Haswell CPU (BIOS revision 00KT19AUS) and NVIDIA GeForce GTX 850A 2GB. It's mostly working, except when I do a shutdown or reboot, it doesn't actually turn off the power after quitting everything:



IMG:



So I have to click the power button to actually turn it off.





I've kept the Windows 8.1 installation in case there's any future firmware. Before installing Xubuntu, I turned off Fastboot from Windows, then installed Xubuntu. Unfortunately, the UEFI BIOS didn't let me change boot order so that Ubuntu actually started as default. I tried bcdedit /set {bootmgr} path EFIubuntushimx64.efi, tried turning off "quickboot" (whatever that is) in BIOS, tried the Boot-Repair program from a Live Session, and tried turning off SecureBoot, but still it would just boot Windows. I ended up, with the help of EricC^^ of #ubuntu on freenode, just switching around the .efi files to trick the boot manager into thinking Ubuntu was Windows:



cp /boot/efi/efi/boot/bootx64.efi{,.backup}
cp /boot/efi/efi/microsoft/boot/bootmgfw.efi{,.backup}
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/bootmgfw.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/grubx64.efi
sudo vim /usr/lib/os-probes/mounted/efi/20microsoft
# and changed bootmgfw.efi to bootmgfw.efi.backup
update-grub


I don't know if any of this has a bearing on the shutdown trouble.



EDIT: Come to think of it, the reboot from the Xubuntu installation (when I was booted through a USB drive) didn't work either.





What I've tried so far to get it to shut down:




  • acpi=off → no difference

  • acpi=force → no difference

  • install proprietary Nvidia drivers → that just made X not start with the message "bbswitch: No discrete VGA device found"

  • various variations on sudo poweroff, sudo shutdown now, sudo shutdown -h now etc.




Also, if I reboot instead of shutdown, I get this psychedelic lightshow on my monitor and have to long-click the power button to turn it off:



reboot fun



If it's helpful, here's a journalctl --all output right after booting up and perhaps even better: journalctl -b -1 (journal from bootup to shutdown).





Also, perhaps related, I notice now that pressing the power button while logged in to XFCE turns the computer right off, even though I have XFCE power settings to "Ask when power button pressed" and "Do nothing" on any other buttons.



My /etc/systemd/logind.conf has no uncommented lines apart from the [Login] header.



There is a /usr/sbin/acpid process running as root.





EDIT: More revelations: Ctrl+Alt+Delete actually reboot fine from GRUB.



EDIT2: I've filed a bug report since this doesn't seem fixable with the regular tricks.



EDIT3: Solved with acpi=noirq and kernel 4.4 and newer.










share|improve this question
























  • I have similar issues on Ubuntu 15.04 Desktop/Server where the system hangs during shutdown/startup. My theory is that both may be related. I narrowed down the startup issue by checking dmesg and found that it was attempting to mount a filesystem that didn't exist and waited for a minute it before would continue booting, Also the shutdown issues were related a mount because if I shutdown my desktop with an open NFS connection to my server without forcefully un-mounting it will hang. I am not sure if these issues are related to your problem but I thought I'd bring them up just encase.
    – Michael Lindman
    Jun 5 '15 at 11:41








  • 1




    M. Lindman's comment makes a good point obliquely. There's a log that shows you in detail what's going on. Read it with journalctl --all. edit your answer and show it to people if you want help understanding it.
    – JdeBP
    Jun 5 '15 at 11:55










  • JdeBP: added, but from what I can tell, journalctl only gives info from this bootup – is there a way to make it keep previous ones?
    – unhammer
    Jun 5 '15 at 12:36






  • 1




    unix.stackexchange.com/questions/159221
    – JdeBP
    Jun 5 '15 at 17:37










  • Thanks JdeBP, wondered why those logs weren't stored :) I added a new link to the bottom of the question, though I can't find anything suspicious myself.
    – unhammer
    Jun 6 '15 at 10:40
















11














I've installed Xubuntu 15.04 on a Lenovo IdeaCentre A740 QHD with a Haswell CPU (BIOS revision 00KT19AUS) and NVIDIA GeForce GTX 850A 2GB. It's mostly working, except when I do a shutdown or reboot, it doesn't actually turn off the power after quitting everything:



IMG:



So I have to click the power button to actually turn it off.





I've kept the Windows 8.1 installation in case there's any future firmware. Before installing Xubuntu, I turned off Fastboot from Windows, then installed Xubuntu. Unfortunately, the UEFI BIOS didn't let me change boot order so that Ubuntu actually started as default. I tried bcdedit /set {bootmgr} path EFIubuntushimx64.efi, tried turning off "quickboot" (whatever that is) in BIOS, tried the Boot-Repair program from a Live Session, and tried turning off SecureBoot, but still it would just boot Windows. I ended up, with the help of EricC^^ of #ubuntu on freenode, just switching around the .efi files to trick the boot manager into thinking Ubuntu was Windows:



cp /boot/efi/efi/boot/bootx64.efi{,.backup}
cp /boot/efi/efi/microsoft/boot/bootmgfw.efi{,.backup}
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/bootmgfw.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/grubx64.efi
sudo vim /usr/lib/os-probes/mounted/efi/20microsoft
# and changed bootmgfw.efi to bootmgfw.efi.backup
update-grub


I don't know if any of this has a bearing on the shutdown trouble.



EDIT: Come to think of it, the reboot from the Xubuntu installation (when I was booted through a USB drive) didn't work either.





What I've tried so far to get it to shut down:




  • acpi=off → no difference

  • acpi=force → no difference

  • install proprietary Nvidia drivers → that just made X not start with the message "bbswitch: No discrete VGA device found"

  • various variations on sudo poweroff, sudo shutdown now, sudo shutdown -h now etc.




Also, if I reboot instead of shutdown, I get this psychedelic lightshow on my monitor and have to long-click the power button to turn it off:



reboot fun



If it's helpful, here's a journalctl --all output right after booting up and perhaps even better: journalctl -b -1 (journal from bootup to shutdown).





Also, perhaps related, I notice now that pressing the power button while logged in to XFCE turns the computer right off, even though I have XFCE power settings to "Ask when power button pressed" and "Do nothing" on any other buttons.



My /etc/systemd/logind.conf has no uncommented lines apart from the [Login] header.



There is a /usr/sbin/acpid process running as root.





EDIT: More revelations: Ctrl+Alt+Delete actually reboot fine from GRUB.



EDIT2: I've filed a bug report since this doesn't seem fixable with the regular tricks.



EDIT3: Solved with acpi=noirq and kernel 4.4 and newer.










share|improve this question
























  • I have similar issues on Ubuntu 15.04 Desktop/Server where the system hangs during shutdown/startup. My theory is that both may be related. I narrowed down the startup issue by checking dmesg and found that it was attempting to mount a filesystem that didn't exist and waited for a minute it before would continue booting, Also the shutdown issues were related a mount because if I shutdown my desktop with an open NFS connection to my server without forcefully un-mounting it will hang. I am not sure if these issues are related to your problem but I thought I'd bring them up just encase.
    – Michael Lindman
    Jun 5 '15 at 11:41








  • 1




    M. Lindman's comment makes a good point obliquely. There's a log that shows you in detail what's going on. Read it with journalctl --all. edit your answer and show it to people if you want help understanding it.
    – JdeBP
    Jun 5 '15 at 11:55










  • JdeBP: added, but from what I can tell, journalctl only gives info from this bootup – is there a way to make it keep previous ones?
    – unhammer
    Jun 5 '15 at 12:36






  • 1




    unix.stackexchange.com/questions/159221
    – JdeBP
    Jun 5 '15 at 17:37










  • Thanks JdeBP, wondered why those logs weren't stored :) I added a new link to the bottom of the question, though I can't find anything suspicious myself.
    – unhammer
    Jun 6 '15 at 10:40














11












11








11


2





I've installed Xubuntu 15.04 on a Lenovo IdeaCentre A740 QHD with a Haswell CPU (BIOS revision 00KT19AUS) and NVIDIA GeForce GTX 850A 2GB. It's mostly working, except when I do a shutdown or reboot, it doesn't actually turn off the power after quitting everything:



IMG:



So I have to click the power button to actually turn it off.





I've kept the Windows 8.1 installation in case there's any future firmware. Before installing Xubuntu, I turned off Fastboot from Windows, then installed Xubuntu. Unfortunately, the UEFI BIOS didn't let me change boot order so that Ubuntu actually started as default. I tried bcdedit /set {bootmgr} path EFIubuntushimx64.efi, tried turning off "quickboot" (whatever that is) in BIOS, tried the Boot-Repair program from a Live Session, and tried turning off SecureBoot, but still it would just boot Windows. I ended up, with the help of EricC^^ of #ubuntu on freenode, just switching around the .efi files to trick the boot manager into thinking Ubuntu was Windows:



cp /boot/efi/efi/boot/bootx64.efi{,.backup}
cp /boot/efi/efi/microsoft/boot/bootmgfw.efi{,.backup}
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/bootmgfw.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/grubx64.efi
sudo vim /usr/lib/os-probes/mounted/efi/20microsoft
# and changed bootmgfw.efi to bootmgfw.efi.backup
update-grub


I don't know if any of this has a bearing on the shutdown trouble.



EDIT: Come to think of it, the reboot from the Xubuntu installation (when I was booted through a USB drive) didn't work either.





What I've tried so far to get it to shut down:




  • acpi=off → no difference

  • acpi=force → no difference

  • install proprietary Nvidia drivers → that just made X not start with the message "bbswitch: No discrete VGA device found"

  • various variations on sudo poweroff, sudo shutdown now, sudo shutdown -h now etc.




Also, if I reboot instead of shutdown, I get this psychedelic lightshow on my monitor and have to long-click the power button to turn it off:



reboot fun



If it's helpful, here's a journalctl --all output right after booting up and perhaps even better: journalctl -b -1 (journal from bootup to shutdown).





Also, perhaps related, I notice now that pressing the power button while logged in to XFCE turns the computer right off, even though I have XFCE power settings to "Ask when power button pressed" and "Do nothing" on any other buttons.



My /etc/systemd/logind.conf has no uncommented lines apart from the [Login] header.



There is a /usr/sbin/acpid process running as root.





EDIT: More revelations: Ctrl+Alt+Delete actually reboot fine from GRUB.



EDIT2: I've filed a bug report since this doesn't seem fixable with the regular tricks.



EDIT3: Solved with acpi=noirq and kernel 4.4 and newer.










share|improve this question















I've installed Xubuntu 15.04 on a Lenovo IdeaCentre A740 QHD with a Haswell CPU (BIOS revision 00KT19AUS) and NVIDIA GeForce GTX 850A 2GB. It's mostly working, except when I do a shutdown or reboot, it doesn't actually turn off the power after quitting everything:



IMG:



So I have to click the power button to actually turn it off.





I've kept the Windows 8.1 installation in case there's any future firmware. Before installing Xubuntu, I turned off Fastboot from Windows, then installed Xubuntu. Unfortunately, the UEFI BIOS didn't let me change boot order so that Ubuntu actually started as default. I tried bcdedit /set {bootmgr} path EFIubuntushimx64.efi, tried turning off "quickboot" (whatever that is) in BIOS, tried the Boot-Repair program from a Live Session, and tried turning off SecureBoot, but still it would just boot Windows. I ended up, with the help of EricC^^ of #ubuntu on freenode, just switching around the .efi files to trick the boot manager into thinking Ubuntu was Windows:



cp /boot/efi/efi/boot/bootx64.efi{,.backup}
cp /boot/efi/efi/microsoft/boot/bootmgfw.efi{,.backup}
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/boot/bootx64.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/bootmgfw.efi
cp /boot/efi/efi/ubuntu/grubx64.efi /boot/efi/efi/microsoft/boot/grubx64.efi
sudo vim /usr/lib/os-probes/mounted/efi/20microsoft
# and changed bootmgfw.efi to bootmgfw.efi.backup
update-grub


I don't know if any of this has a bearing on the shutdown trouble.



EDIT: Come to think of it, the reboot from the Xubuntu installation (when I was booted through a USB drive) didn't work either.





What I've tried so far to get it to shut down:




  • acpi=off → no difference

  • acpi=force → no difference

  • install proprietary Nvidia drivers → that just made X not start with the message "bbswitch: No discrete VGA device found"

  • various variations on sudo poweroff, sudo shutdown now, sudo shutdown -h now etc.




Also, if I reboot instead of shutdown, I get this psychedelic lightshow on my monitor and have to long-click the power button to turn it off:



reboot fun



If it's helpful, here's a journalctl --all output right after booting up and perhaps even better: journalctl -b -1 (journal from bootup to shutdown).





Also, perhaps related, I notice now that pressing the power button while logged in to XFCE turns the computer right off, even though I have XFCE power settings to "Ask when power button pressed" and "Do nothing" on any other buttons.



My /etc/systemd/logind.conf has no uncommented lines apart from the [Login] header.



There is a /usr/sbin/acpid process running as root.





EDIT: More revelations: Ctrl+Alt+Delete actually reboot fine from GRUB.



EDIT2: I've filed a bug report since this doesn't seem fixable with the regular tricks.



EDIT3: Solved with acpi=noirq and kernel 4.4 and newer.







shutdown






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Feb 9 '17 at 7:09









karel

56.6k11125145




56.6k11125145










asked Jun 5 '15 at 11:25









unhammer

1,39711732




1,39711732












  • I have similar issues on Ubuntu 15.04 Desktop/Server where the system hangs during shutdown/startup. My theory is that both may be related. I narrowed down the startup issue by checking dmesg and found that it was attempting to mount a filesystem that didn't exist and waited for a minute it before would continue booting, Also the shutdown issues were related a mount because if I shutdown my desktop with an open NFS connection to my server without forcefully un-mounting it will hang. I am not sure if these issues are related to your problem but I thought I'd bring them up just encase.
    – Michael Lindman
    Jun 5 '15 at 11:41








  • 1




    M. Lindman's comment makes a good point obliquely. There's a log that shows you in detail what's going on. Read it with journalctl --all. edit your answer and show it to people if you want help understanding it.
    – JdeBP
    Jun 5 '15 at 11:55










  • JdeBP: added, but from what I can tell, journalctl only gives info from this bootup – is there a way to make it keep previous ones?
    – unhammer
    Jun 5 '15 at 12:36






  • 1




    unix.stackexchange.com/questions/159221
    – JdeBP
    Jun 5 '15 at 17:37










  • Thanks JdeBP, wondered why those logs weren't stored :) I added a new link to the bottom of the question, though I can't find anything suspicious myself.
    – unhammer
    Jun 6 '15 at 10:40


















  • I have similar issues on Ubuntu 15.04 Desktop/Server where the system hangs during shutdown/startup. My theory is that both may be related. I narrowed down the startup issue by checking dmesg and found that it was attempting to mount a filesystem that didn't exist and waited for a minute it before would continue booting, Also the shutdown issues were related a mount because if I shutdown my desktop with an open NFS connection to my server without forcefully un-mounting it will hang. I am not sure if these issues are related to your problem but I thought I'd bring them up just encase.
    – Michael Lindman
    Jun 5 '15 at 11:41








  • 1




    M. Lindman's comment makes a good point obliquely. There's a log that shows you in detail what's going on. Read it with journalctl --all. edit your answer and show it to people if you want help understanding it.
    – JdeBP
    Jun 5 '15 at 11:55










  • JdeBP: added, but from what I can tell, journalctl only gives info from this bootup – is there a way to make it keep previous ones?
    – unhammer
    Jun 5 '15 at 12:36






  • 1




    unix.stackexchange.com/questions/159221
    – JdeBP
    Jun 5 '15 at 17:37










  • Thanks JdeBP, wondered why those logs weren't stored :) I added a new link to the bottom of the question, though I can't find anything suspicious myself.
    – unhammer
    Jun 6 '15 at 10:40
















I have similar issues on Ubuntu 15.04 Desktop/Server where the system hangs during shutdown/startup. My theory is that both may be related. I narrowed down the startup issue by checking dmesg and found that it was attempting to mount a filesystem that didn't exist and waited for a minute it before would continue booting, Also the shutdown issues were related a mount because if I shutdown my desktop with an open NFS connection to my server without forcefully un-mounting it will hang. I am not sure if these issues are related to your problem but I thought I'd bring them up just encase.
– Michael Lindman
Jun 5 '15 at 11:41






I have similar issues on Ubuntu 15.04 Desktop/Server where the system hangs during shutdown/startup. My theory is that both may be related. I narrowed down the startup issue by checking dmesg and found that it was attempting to mount a filesystem that didn't exist and waited for a minute it before would continue booting, Also the shutdown issues were related a mount because if I shutdown my desktop with an open NFS connection to my server without forcefully un-mounting it will hang. I am not sure if these issues are related to your problem but I thought I'd bring them up just encase.
– Michael Lindman
Jun 5 '15 at 11:41






1




1




M. Lindman's comment makes a good point obliquely. There's a log that shows you in detail what's going on. Read it with journalctl --all. edit your answer and show it to people if you want help understanding it.
– JdeBP
Jun 5 '15 at 11:55




M. Lindman's comment makes a good point obliquely. There's a log that shows you in detail what's going on. Read it with journalctl --all. edit your answer and show it to people if you want help understanding it.
– JdeBP
Jun 5 '15 at 11:55












JdeBP: added, but from what I can tell, journalctl only gives info from this bootup – is there a way to make it keep previous ones?
– unhammer
Jun 5 '15 at 12:36




JdeBP: added, but from what I can tell, journalctl only gives info from this bootup – is there a way to make it keep previous ones?
– unhammer
Jun 5 '15 at 12:36




1




1




unix.stackexchange.com/questions/159221
– JdeBP
Jun 5 '15 at 17:37




unix.stackexchange.com/questions/159221
– JdeBP
Jun 5 '15 at 17:37












Thanks JdeBP, wondered why those logs weren't stored :) I added a new link to the bottom of the question, though I can't find anything suspicious myself.
– unhammer
Jun 6 '15 at 10:40




Thanks JdeBP, wondered why those logs weren't stored :) I added a new link to the bottom of the question, though I can't find anything suspicious myself.
– unhammer
Jun 6 '15 at 10:40










9 Answers
9






active

oldest

votes


















4





+75









My best guess based on the info provided is a buggy UEFI BIOS. digging through the kernel bugs for Haswell I found a possible workaround. Try using xhci_hcd.quirks=262144 as a boot option or Disabling xhci in the UEFI.



The only other options I can think of are as follows:



A) Wait and hope that either the kernel development team or Lenovo comes up with an update that resolves the problem.



B) Contact Lenovo Support and push for a BIOS update that resolves the problem or encourage others with the same problem to subscribe to your bug report. This may or may not be any more effective than A.



C) Modify the BIOS or the kernel yourself until you reach the desired result (Not for the faint of heart). I'm not recommending this course of action, only including it for completeness. Modifying the BIOS can easily leave you with an unbootable system with a voided warranty. You should also read carefully the reasons for and against compiling your own kernel in the aforementioned linked document.



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






share|improve this answer























  • That's for Broadwell systems ( support.lenovo.com/us/en/products/desktops-and-all-in-ones/… ), mine's a Haswell (BIOS revision 00KT19AUS)
    – unhammer
    Jun 13 '15 at 7:01












  • Edited new information into question for you.
    – Elder Geek
    Jun 13 '15 at 13:22










  • I edited my answer
    – Elder Geek
    Jun 13 '15 at 13:48










  • Note: It appears that Christopher M. Penalver came to the same false conclusion I did regarding the BIOS. You may wish to bring them up to speed on your reported bug.
    – Elder Geek
    Jun 13 '15 at 13:57








  • 1




    XHCI settings are USB related - I hope that helps you find them in your BIOS. If not, contact Lenovo customer service at 1 (855) 253-6686 and ask about where to find them or if they have a BIOS update in the works. All the best!
    – Elder Geek
    Jun 29 '15 at 23:51



















3














Try adding



acpi=noirq


to the kernel boot parameters. This lets it poweroff on shutdown/restart (tested with kernels 4.4 and 4.7rc5).



It seems to suspend too, but unfortunately does not resume from suspend on pressing the power button.



This has worked fine for over three months now on the A740, so I'm calling this solved.






share|improve this answer























  • I'm glad my option A) worked for you! :-)
    – Elder Geek
    Jul 5 '17 at 20:57












  • As in "wait and hope"? What I actually did was report it as bug in the Ubuntu linux package, trying some newer mainline releases, then when that didn't solve anything I reported it upstream, first to the wrong component bugzilla.kernel.org/show_bug.cgi?id=118401 , then got sent to ide/ahci, and after some e-mail exchanges and trying to get useful debug output marc.info/?t=146296312800002&r=1&w=2 and trying different options suggested there, found the one that worked. Simply waiting and upgrading doesn't solve it, the grub settings need to be edited.
    – unhammer
    Jul 6 '17 at 7:22










  • Regardless, I'm glad you got it sorted. Whether it was A or B :-)
    – Elder Geek
    Jul 6 '17 at 14:15





















2














After ferreting through the system files I saw a few warning about the BIOS. I checked Intel's website and there was an upgrade available that seemed to solve an issue of overlapping memory addresses. Not obviously the same but my logs indicated that various sectors of my BIOS were returning unexpected values, which did not prevent the kernel from starting but obviously was not good. The issue was not apparent until the kernel stopped using upstart and started using systemd.



I downloaded the updated BIOS and applied it and now my system turns off as expected.






share|improve this answer























  • What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
    – unhammer
    Feb 25 '16 at 14:06



















0














What cat /etc/default/halt says? Try halt -p.



You can also edit /etc/init.d/halt and remove this lines:



if [ "$INIT_HALT" = "HALT" ]
then
poweroff=""
fi


below



poweroff="-p"





share|improve this answer





















  • halt -p is no different, it still doesn't shut down completely.
    – unhammer
    Jun 5 '15 at 11:45










  • oh, and /etc/default/halt says HALT=poweroff. But shouldn't halt -p or poweroff or shutdown now still work regardless of what's in there?
    – unhammer
    Jun 5 '15 at 12:37





















0














From your Kernel Logs (Screenshot) I have a hunch that unattended-upgrades might be the cause of your issue. There have been several bug reports on this years ago, but they have not been resolved. A temporary fix to this would be to disable automatic updates by updates, but we will keep it as a last resort. But first of all, we will try a manual upgrade:



sudo apt-get autoremove
sudo apt-get dist-upgrade


If this did not solve your issue, and the upgrade went without any errors or warnings, wee will try digging a bit more deep to see if we can find out what is causing the issue. You could get a lead by inspecting the contents of /var/log/unattended-upgrades. If you could figure out which update is causing the issue, you could blacklist the update by modifying /etc/apt/apt.conf.d/50unattended-upgrades.



If it still does not solve the issue, you can temporarily remove the package, to confirm if it is the cause:



sudo apt-get remove unattended-upgrades 


I recommend that you reinstall it even if it solved your issue. If this is the case bring back the the bug report with more information so that the developers can solve your issue.



Warning: If you choose to disable automatic update and then don't manually update your system, you may be at risk from security and stability view point.






share|improve this answer























  • This is a fresh install – autoremove and dist-upgrade have "0 to upgrade, 0 to remove" etc, and /var/log/unattended-upgrades is empty: $ wc -c < /var/log/unattended-upgrades/unattended-upgrades-shutdown.log gives 0
    – unhammer
    Jun 9 '15 at 6:52












  • Also, there are no programs in /lib/systemd/system-shutdown, so there are no services that should be called when I type poweroff. And removing unattended-upgrades completely had no effect.
    – unhammer
    Jun 9 '15 at 6:57





















0














I tried everything and after days a lowly rated fanswer from this forum did the trick: Ubuntu 14.04 stuck on shutdown




For me, the solution was to upgrade the kernel. I used 4.5.3 on Ubuntu
15.10 (anything greater than this will crash the OS after login) And 4.7 RC3 works on Ubuntu 16.04.




Now works perfectly :-)






share|improve this answer





















  • That didn't work for my system. As the bug reports show, I already tried quite a lot of 4.7 kernels – these just made it impossible to boot! After reporting upstream and debugging help from kernel list, the workaround to both my issues (booting at all, and powering off on shutdown) was acpi=noirq askubuntu.com/a/794739/25639
    – unhammer
    Nov 4 '16 at 8:25



















0














I can confirm it definitely has something to do with ACPI. My system exhibits this exact behaviour if and only if I pass acpi=off in Linux 4.20-rc3 for kernel development purposes. If your ACPI was enabled at first, then there is a fair chance that the ACPI implementation in the BIOS was buggy. I see you said a kernel upgrade helped. But a BIOS upgrade may have done the trick, also.






share|improve this answer





















  • This does not actually answer the question. Your suggestion relating to the BIOS merely indicates a possible solution, one which it would appear you haven't actually tried. In fact, the OP indicated that he had solved his issue by "adding acpi=noirq to the kernel boot parameters".
    – CentaurusA
    Dec 19 at 18:00



















-1














Your hardware might not support software shutdown. I've had that happen before, and the way to test is this:



sudo poweroff


If that does not shutdown the hardware, it's a hardware issue and not software.






share|improve this answer

















  • 3




    As the question states, I've tried that to no avail. But GRUB manages the software reboot just fine (not sure how to test poweroff there) while Windows 8.1 does the software poweroff and reboot just fine on this hardware. It seems like a kernel issue, so I've filed a bug report.
    – unhammer
    Jun 11 '15 at 6:22






  • 1




    upvote for filing a bug report.
    – Daniel
    Jun 11 '15 at 16:44










  • -1 Because I find otherwise. It ends with systemd-shutdown[1]: Powering off. The machine turned off just fine with 12.04 and 14.04, but not a fresh install of 16.04.
    – Nateowami
    Jun 26 '16 at 12:52



















-1















  1. Restart then F2

  2. Go to configuration and disable xHCI

  3. Save and exit


Don't think about it just trust me and do it :)






share|improve this answer





















  • I can't find any XHCI settings in BIOS anywhere. I can turn off all of USB, but that's not an option for me.
    – unhammer
    Jun 14 '15 at 19:39










  • this will not turn all usb it will only turn usb3
    – Talal
    Jun 15 '15 at 11:36











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f632591%2fsystem-does-not-power-off-on-poweroff-just-halts%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























9 Answers
9






active

oldest

votes








9 Answers
9






active

oldest

votes









active

oldest

votes






active

oldest

votes









4





+75









My best guess based on the info provided is a buggy UEFI BIOS. digging through the kernel bugs for Haswell I found a possible workaround. Try using xhci_hcd.quirks=262144 as a boot option or Disabling xhci in the UEFI.



The only other options I can think of are as follows:



A) Wait and hope that either the kernel development team or Lenovo comes up with an update that resolves the problem.



B) Contact Lenovo Support and push for a BIOS update that resolves the problem or encourage others with the same problem to subscribe to your bug report. This may or may not be any more effective than A.



C) Modify the BIOS or the kernel yourself until you reach the desired result (Not for the faint of heart). I'm not recommending this course of action, only including it for completeness. Modifying the BIOS can easily leave you with an unbootable system with a voided warranty. You should also read carefully the reasons for and against compiling your own kernel in the aforementioned linked document.



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






share|improve this answer























  • That's for Broadwell systems ( support.lenovo.com/us/en/products/desktops-and-all-in-ones/… ), mine's a Haswell (BIOS revision 00KT19AUS)
    – unhammer
    Jun 13 '15 at 7:01












  • Edited new information into question for you.
    – Elder Geek
    Jun 13 '15 at 13:22










  • I edited my answer
    – Elder Geek
    Jun 13 '15 at 13:48










  • Note: It appears that Christopher M. Penalver came to the same false conclusion I did regarding the BIOS. You may wish to bring them up to speed on your reported bug.
    – Elder Geek
    Jun 13 '15 at 13:57








  • 1




    XHCI settings are USB related - I hope that helps you find them in your BIOS. If not, contact Lenovo customer service at 1 (855) 253-6686 and ask about where to find them or if they have a BIOS update in the works. All the best!
    – Elder Geek
    Jun 29 '15 at 23:51
















4





+75









My best guess based on the info provided is a buggy UEFI BIOS. digging through the kernel bugs for Haswell I found a possible workaround. Try using xhci_hcd.quirks=262144 as a boot option or Disabling xhci in the UEFI.



The only other options I can think of are as follows:



A) Wait and hope that either the kernel development team or Lenovo comes up with an update that resolves the problem.



B) Contact Lenovo Support and push for a BIOS update that resolves the problem or encourage others with the same problem to subscribe to your bug report. This may or may not be any more effective than A.



C) Modify the BIOS or the kernel yourself until you reach the desired result (Not for the faint of heart). I'm not recommending this course of action, only including it for completeness. Modifying the BIOS can easily leave you with an unbootable system with a voided warranty. You should also read carefully the reasons for and against compiling your own kernel in the aforementioned linked document.



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






share|improve this answer























  • That's for Broadwell systems ( support.lenovo.com/us/en/products/desktops-and-all-in-ones/… ), mine's a Haswell (BIOS revision 00KT19AUS)
    – unhammer
    Jun 13 '15 at 7:01












  • Edited new information into question for you.
    – Elder Geek
    Jun 13 '15 at 13:22










  • I edited my answer
    – Elder Geek
    Jun 13 '15 at 13:48










  • Note: It appears that Christopher M. Penalver came to the same false conclusion I did regarding the BIOS. You may wish to bring them up to speed on your reported bug.
    – Elder Geek
    Jun 13 '15 at 13:57








  • 1




    XHCI settings are USB related - I hope that helps you find them in your BIOS. If not, contact Lenovo customer service at 1 (855) 253-6686 and ask about where to find them or if they have a BIOS update in the works. All the best!
    – Elder Geek
    Jun 29 '15 at 23:51














4





+75







4





+75



4




+75




My best guess based on the info provided is a buggy UEFI BIOS. digging through the kernel bugs for Haswell I found a possible workaround. Try using xhci_hcd.quirks=262144 as a boot option or Disabling xhci in the UEFI.



The only other options I can think of are as follows:



A) Wait and hope that either the kernel development team or Lenovo comes up with an update that resolves the problem.



B) Contact Lenovo Support and push for a BIOS update that resolves the problem or encourage others with the same problem to subscribe to your bug report. This may or may not be any more effective than A.



C) Modify the BIOS or the kernel yourself until you reach the desired result (Not for the faint of heart). I'm not recommending this course of action, only including it for completeness. Modifying the BIOS can easily leave you with an unbootable system with a voided warranty. You should also read carefully the reasons for and against compiling your own kernel in the aforementioned linked document.



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






share|improve this answer














My best guess based on the info provided is a buggy UEFI BIOS. digging through the kernel bugs for Haswell I found a possible workaround. Try using xhci_hcd.quirks=262144 as a boot option or Disabling xhci in the UEFI.



The only other options I can think of are as follows:



A) Wait and hope that either the kernel development team or Lenovo comes up with an update that resolves the problem.



B) Contact Lenovo Support and push for a BIOS update that resolves the problem or encourage others with the same problem to subscribe to your bug report. This may or may not be any more effective than A.



C) Modify the BIOS or the kernel yourself until you reach the desired result (Not for the faint of heart). I'm not recommending this course of action, only including it for completeness. Modifying the BIOS can easily leave you with an unbootable system with a voided warranty. You should also read carefully the reasons for and against compiling your own kernel in the aforementioned linked document.



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







share|improve this answer














share|improve this answer



share|improve this answer








edited Jun 15 '15 at 11:36

























answered Jun 12 '15 at 13:45









Elder Geek

26.4k952124




26.4k952124












  • That's for Broadwell systems ( support.lenovo.com/us/en/products/desktops-and-all-in-ones/… ), mine's a Haswell (BIOS revision 00KT19AUS)
    – unhammer
    Jun 13 '15 at 7:01












  • Edited new information into question for you.
    – Elder Geek
    Jun 13 '15 at 13:22










  • I edited my answer
    – Elder Geek
    Jun 13 '15 at 13:48










  • Note: It appears that Christopher M. Penalver came to the same false conclusion I did regarding the BIOS. You may wish to bring them up to speed on your reported bug.
    – Elder Geek
    Jun 13 '15 at 13:57








  • 1




    XHCI settings are USB related - I hope that helps you find them in your BIOS. If not, contact Lenovo customer service at 1 (855) 253-6686 and ask about where to find them or if they have a BIOS update in the works. All the best!
    – Elder Geek
    Jun 29 '15 at 23:51


















  • That's for Broadwell systems ( support.lenovo.com/us/en/products/desktops-and-all-in-ones/… ), mine's a Haswell (BIOS revision 00KT19AUS)
    – unhammer
    Jun 13 '15 at 7:01












  • Edited new information into question for you.
    – Elder Geek
    Jun 13 '15 at 13:22










  • I edited my answer
    – Elder Geek
    Jun 13 '15 at 13:48










  • Note: It appears that Christopher M. Penalver came to the same false conclusion I did regarding the BIOS. You may wish to bring them up to speed on your reported bug.
    – Elder Geek
    Jun 13 '15 at 13:57








  • 1




    XHCI settings are USB related - I hope that helps you find them in your BIOS. If not, contact Lenovo customer service at 1 (855) 253-6686 and ask about where to find them or if they have a BIOS update in the works. All the best!
    – Elder Geek
    Jun 29 '15 at 23:51
















That's for Broadwell systems ( support.lenovo.com/us/en/products/desktops-and-all-in-ones/… ), mine's a Haswell (BIOS revision 00KT19AUS)
– unhammer
Jun 13 '15 at 7:01






That's for Broadwell systems ( support.lenovo.com/us/en/products/desktops-and-all-in-ones/… ), mine's a Haswell (BIOS revision 00KT19AUS)
– unhammer
Jun 13 '15 at 7:01














Edited new information into question for you.
– Elder Geek
Jun 13 '15 at 13:22




Edited new information into question for you.
– Elder Geek
Jun 13 '15 at 13:22












I edited my answer
– Elder Geek
Jun 13 '15 at 13:48




I edited my answer
– Elder Geek
Jun 13 '15 at 13:48












Note: It appears that Christopher M. Penalver came to the same false conclusion I did regarding the BIOS. You may wish to bring them up to speed on your reported bug.
– Elder Geek
Jun 13 '15 at 13:57






Note: It appears that Christopher M. Penalver came to the same false conclusion I did regarding the BIOS. You may wish to bring them up to speed on your reported bug.
– Elder Geek
Jun 13 '15 at 13:57






1




1




XHCI settings are USB related - I hope that helps you find them in your BIOS. If not, contact Lenovo customer service at 1 (855) 253-6686 and ask about where to find them or if they have a BIOS update in the works. All the best!
– Elder Geek
Jun 29 '15 at 23:51




XHCI settings are USB related - I hope that helps you find them in your BIOS. If not, contact Lenovo customer service at 1 (855) 253-6686 and ask about where to find them or if they have a BIOS update in the works. All the best!
– Elder Geek
Jun 29 '15 at 23:51













3














Try adding



acpi=noirq


to the kernel boot parameters. This lets it poweroff on shutdown/restart (tested with kernels 4.4 and 4.7rc5).



It seems to suspend too, but unfortunately does not resume from suspend on pressing the power button.



This has worked fine for over three months now on the A740, so I'm calling this solved.






share|improve this answer























  • I'm glad my option A) worked for you! :-)
    – Elder Geek
    Jul 5 '17 at 20:57












  • As in "wait and hope"? What I actually did was report it as bug in the Ubuntu linux package, trying some newer mainline releases, then when that didn't solve anything I reported it upstream, first to the wrong component bugzilla.kernel.org/show_bug.cgi?id=118401 , then got sent to ide/ahci, and after some e-mail exchanges and trying to get useful debug output marc.info/?t=146296312800002&r=1&w=2 and trying different options suggested there, found the one that worked. Simply waiting and upgrading doesn't solve it, the grub settings need to be edited.
    – unhammer
    Jul 6 '17 at 7:22










  • Regardless, I'm glad you got it sorted. Whether it was A or B :-)
    – Elder Geek
    Jul 6 '17 at 14:15


















3














Try adding



acpi=noirq


to the kernel boot parameters. This lets it poweroff on shutdown/restart (tested with kernels 4.4 and 4.7rc5).



It seems to suspend too, but unfortunately does not resume from suspend on pressing the power button.



This has worked fine for over three months now on the A740, so I'm calling this solved.






share|improve this answer























  • I'm glad my option A) worked for you! :-)
    – Elder Geek
    Jul 5 '17 at 20:57












  • As in "wait and hope"? What I actually did was report it as bug in the Ubuntu linux package, trying some newer mainline releases, then when that didn't solve anything I reported it upstream, first to the wrong component bugzilla.kernel.org/show_bug.cgi?id=118401 , then got sent to ide/ahci, and after some e-mail exchanges and trying to get useful debug output marc.info/?t=146296312800002&r=1&w=2 and trying different options suggested there, found the one that worked. Simply waiting and upgrading doesn't solve it, the grub settings need to be edited.
    – unhammer
    Jul 6 '17 at 7:22










  • Regardless, I'm glad you got it sorted. Whether it was A or B :-)
    – Elder Geek
    Jul 6 '17 at 14:15
















3












3








3






Try adding



acpi=noirq


to the kernel boot parameters. This lets it poweroff on shutdown/restart (tested with kernels 4.4 and 4.7rc5).



It seems to suspend too, but unfortunately does not resume from suspend on pressing the power button.



This has worked fine for over three months now on the A740, so I'm calling this solved.






share|improve this answer














Try adding



acpi=noirq


to the kernel boot parameters. This lets it poweroff on shutdown/restart (tested with kernels 4.4 and 4.7rc5).



It seems to suspend too, but unfortunately does not resume from suspend on pressing the power button.



This has worked fine for over three months now on the A740, so I'm calling this solved.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 4 '16 at 8:27

























answered Jul 4 '16 at 15:32









unhammer

1,39711732




1,39711732












  • I'm glad my option A) worked for you! :-)
    – Elder Geek
    Jul 5 '17 at 20:57












  • As in "wait and hope"? What I actually did was report it as bug in the Ubuntu linux package, trying some newer mainline releases, then when that didn't solve anything I reported it upstream, first to the wrong component bugzilla.kernel.org/show_bug.cgi?id=118401 , then got sent to ide/ahci, and after some e-mail exchanges and trying to get useful debug output marc.info/?t=146296312800002&r=1&w=2 and trying different options suggested there, found the one that worked. Simply waiting and upgrading doesn't solve it, the grub settings need to be edited.
    – unhammer
    Jul 6 '17 at 7:22










  • Regardless, I'm glad you got it sorted. Whether it was A or B :-)
    – Elder Geek
    Jul 6 '17 at 14:15




















  • I'm glad my option A) worked for you! :-)
    – Elder Geek
    Jul 5 '17 at 20:57












  • As in "wait and hope"? What I actually did was report it as bug in the Ubuntu linux package, trying some newer mainline releases, then when that didn't solve anything I reported it upstream, first to the wrong component bugzilla.kernel.org/show_bug.cgi?id=118401 , then got sent to ide/ahci, and after some e-mail exchanges and trying to get useful debug output marc.info/?t=146296312800002&r=1&w=2 and trying different options suggested there, found the one that worked. Simply waiting and upgrading doesn't solve it, the grub settings need to be edited.
    – unhammer
    Jul 6 '17 at 7:22










  • Regardless, I'm glad you got it sorted. Whether it was A or B :-)
    – Elder Geek
    Jul 6 '17 at 14:15


















I'm glad my option A) worked for you! :-)
– Elder Geek
Jul 5 '17 at 20:57






I'm glad my option A) worked for you! :-)
– Elder Geek
Jul 5 '17 at 20:57














As in "wait and hope"? What I actually did was report it as bug in the Ubuntu linux package, trying some newer mainline releases, then when that didn't solve anything I reported it upstream, first to the wrong component bugzilla.kernel.org/show_bug.cgi?id=118401 , then got sent to ide/ahci, and after some e-mail exchanges and trying to get useful debug output marc.info/?t=146296312800002&r=1&w=2 and trying different options suggested there, found the one that worked. Simply waiting and upgrading doesn't solve it, the grub settings need to be edited.
– unhammer
Jul 6 '17 at 7:22




As in "wait and hope"? What I actually did was report it as bug in the Ubuntu linux package, trying some newer mainline releases, then when that didn't solve anything I reported it upstream, first to the wrong component bugzilla.kernel.org/show_bug.cgi?id=118401 , then got sent to ide/ahci, and after some e-mail exchanges and trying to get useful debug output marc.info/?t=146296312800002&r=1&w=2 and trying different options suggested there, found the one that worked. Simply waiting and upgrading doesn't solve it, the grub settings need to be edited.
– unhammer
Jul 6 '17 at 7:22












Regardless, I'm glad you got it sorted. Whether it was A or B :-)
– Elder Geek
Jul 6 '17 at 14:15






Regardless, I'm glad you got it sorted. Whether it was A or B :-)
– Elder Geek
Jul 6 '17 at 14:15













2














After ferreting through the system files I saw a few warning about the BIOS. I checked Intel's website and there was an upgrade available that seemed to solve an issue of overlapping memory addresses. Not obviously the same but my logs indicated that various sectors of my BIOS were returning unexpected values, which did not prevent the kernel from starting but obviously was not good. The issue was not apparent until the kernel stopped using upstart and started using systemd.



I downloaded the updated BIOS and applied it and now my system turns off as expected.






share|improve this answer























  • What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
    – unhammer
    Feb 25 '16 at 14:06
















2














After ferreting through the system files I saw a few warning about the BIOS. I checked Intel's website and there was an upgrade available that seemed to solve an issue of overlapping memory addresses. Not obviously the same but my logs indicated that various sectors of my BIOS were returning unexpected values, which did not prevent the kernel from starting but obviously was not good. The issue was not apparent until the kernel stopped using upstart and started using systemd.



I downloaded the updated BIOS and applied it and now my system turns off as expected.






share|improve this answer























  • What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
    – unhammer
    Feb 25 '16 at 14:06














2












2








2






After ferreting through the system files I saw a few warning about the BIOS. I checked Intel's website and there was an upgrade available that seemed to solve an issue of overlapping memory addresses. Not obviously the same but my logs indicated that various sectors of my BIOS were returning unexpected values, which did not prevent the kernel from starting but obviously was not good. The issue was not apparent until the kernel stopped using upstart and started using systemd.



I downloaded the updated BIOS and applied it and now my system turns off as expected.






share|improve this answer














After ferreting through the system files I saw a few warning about the BIOS. I checked Intel's website and there was an upgrade available that seemed to solve an issue of overlapping memory addresses. Not obviously the same but my logs indicated that various sectors of my BIOS were returning unexpected values, which did not prevent the kernel from starting but obviously was not good. The issue was not apparent until the kernel stopped using upstart and started using systemd.



I downloaded the updated BIOS and applied it and now my system turns off as expected.







share|improve this answer














share|improve this answer



share|improve this answer








edited Feb 25 '16 at 7:47









Byte Commander

62.8k26169286




62.8k26169286










answered Feb 25 '16 at 4:08









Simon

991




991












  • What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
    – unhammer
    Feb 25 '16 at 14:06


















  • What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
    – unhammer
    Feb 25 '16 at 14:06
















What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
– unhammer
Feb 25 '16 at 14:06




What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
– unhammer
Feb 25 '16 at 14:06











0














What cat /etc/default/halt says? Try halt -p.



You can also edit /etc/init.d/halt and remove this lines:



if [ "$INIT_HALT" = "HALT" ]
then
poweroff=""
fi


below



poweroff="-p"





share|improve this answer





















  • halt -p is no different, it still doesn't shut down completely.
    – unhammer
    Jun 5 '15 at 11:45










  • oh, and /etc/default/halt says HALT=poweroff. But shouldn't halt -p or poweroff or shutdown now still work regardless of what's in there?
    – unhammer
    Jun 5 '15 at 12:37


















0














What cat /etc/default/halt says? Try halt -p.



You can also edit /etc/init.d/halt and remove this lines:



if [ "$INIT_HALT" = "HALT" ]
then
poweroff=""
fi


below



poweroff="-p"





share|improve this answer





















  • halt -p is no different, it still doesn't shut down completely.
    – unhammer
    Jun 5 '15 at 11:45










  • oh, and /etc/default/halt says HALT=poweroff. But shouldn't halt -p or poweroff or shutdown now still work regardless of what's in there?
    – unhammer
    Jun 5 '15 at 12:37
















0












0








0






What cat /etc/default/halt says? Try halt -p.



You can also edit /etc/init.d/halt and remove this lines:



if [ "$INIT_HALT" = "HALT" ]
then
poweroff=""
fi


below



poweroff="-p"





share|improve this answer












What cat /etc/default/halt says? Try halt -p.



You can also edit /etc/init.d/halt and remove this lines:



if [ "$INIT_HALT" = "HALT" ]
then
poweroff=""
fi


below



poweroff="-p"






share|improve this answer












share|improve this answer



share|improve this answer










answered Jun 5 '15 at 11:44









Uncle Leo

73




73












  • halt -p is no different, it still doesn't shut down completely.
    – unhammer
    Jun 5 '15 at 11:45










  • oh, and /etc/default/halt says HALT=poweroff. But shouldn't halt -p or poweroff or shutdown now still work regardless of what's in there?
    – unhammer
    Jun 5 '15 at 12:37




















  • halt -p is no different, it still doesn't shut down completely.
    – unhammer
    Jun 5 '15 at 11:45










  • oh, and /etc/default/halt says HALT=poweroff. But shouldn't halt -p or poweroff or shutdown now still work regardless of what's in there?
    – unhammer
    Jun 5 '15 at 12:37


















halt -p is no different, it still doesn't shut down completely.
– unhammer
Jun 5 '15 at 11:45




halt -p is no different, it still doesn't shut down completely.
– unhammer
Jun 5 '15 at 11:45












oh, and /etc/default/halt says HALT=poweroff. But shouldn't halt -p or poweroff or shutdown now still work regardless of what's in there?
– unhammer
Jun 5 '15 at 12:37






oh, and /etc/default/halt says HALT=poweroff. But shouldn't halt -p or poweroff or shutdown now still work regardless of what's in there?
– unhammer
Jun 5 '15 at 12:37













0














From your Kernel Logs (Screenshot) I have a hunch that unattended-upgrades might be the cause of your issue. There have been several bug reports on this years ago, but they have not been resolved. A temporary fix to this would be to disable automatic updates by updates, but we will keep it as a last resort. But first of all, we will try a manual upgrade:



sudo apt-get autoremove
sudo apt-get dist-upgrade


If this did not solve your issue, and the upgrade went without any errors or warnings, wee will try digging a bit more deep to see if we can find out what is causing the issue. You could get a lead by inspecting the contents of /var/log/unattended-upgrades. If you could figure out which update is causing the issue, you could blacklist the update by modifying /etc/apt/apt.conf.d/50unattended-upgrades.



If it still does not solve the issue, you can temporarily remove the package, to confirm if it is the cause:



sudo apt-get remove unattended-upgrades 


I recommend that you reinstall it even if it solved your issue. If this is the case bring back the the bug report with more information so that the developers can solve your issue.



Warning: If you choose to disable automatic update and then don't manually update your system, you may be at risk from security and stability view point.






share|improve this answer























  • This is a fresh install – autoremove and dist-upgrade have "0 to upgrade, 0 to remove" etc, and /var/log/unattended-upgrades is empty: $ wc -c < /var/log/unattended-upgrades/unattended-upgrades-shutdown.log gives 0
    – unhammer
    Jun 9 '15 at 6:52












  • Also, there are no programs in /lib/systemd/system-shutdown, so there are no services that should be called when I type poweroff. And removing unattended-upgrades completely had no effect.
    – unhammer
    Jun 9 '15 at 6:57


















0














From your Kernel Logs (Screenshot) I have a hunch that unattended-upgrades might be the cause of your issue. There have been several bug reports on this years ago, but they have not been resolved. A temporary fix to this would be to disable automatic updates by updates, but we will keep it as a last resort. But first of all, we will try a manual upgrade:



sudo apt-get autoremove
sudo apt-get dist-upgrade


If this did not solve your issue, and the upgrade went without any errors or warnings, wee will try digging a bit more deep to see if we can find out what is causing the issue. You could get a lead by inspecting the contents of /var/log/unattended-upgrades. If you could figure out which update is causing the issue, you could blacklist the update by modifying /etc/apt/apt.conf.d/50unattended-upgrades.



If it still does not solve the issue, you can temporarily remove the package, to confirm if it is the cause:



sudo apt-get remove unattended-upgrades 


I recommend that you reinstall it even if it solved your issue. If this is the case bring back the the bug report with more information so that the developers can solve your issue.



Warning: If you choose to disable automatic update and then don't manually update your system, you may be at risk from security and stability view point.






share|improve this answer























  • This is a fresh install – autoremove and dist-upgrade have "0 to upgrade, 0 to remove" etc, and /var/log/unattended-upgrades is empty: $ wc -c < /var/log/unattended-upgrades/unattended-upgrades-shutdown.log gives 0
    – unhammer
    Jun 9 '15 at 6:52












  • Also, there are no programs in /lib/systemd/system-shutdown, so there are no services that should be called when I type poweroff. And removing unattended-upgrades completely had no effect.
    – unhammer
    Jun 9 '15 at 6:57
















0












0








0






From your Kernel Logs (Screenshot) I have a hunch that unattended-upgrades might be the cause of your issue. There have been several bug reports on this years ago, but they have not been resolved. A temporary fix to this would be to disable automatic updates by updates, but we will keep it as a last resort. But first of all, we will try a manual upgrade:



sudo apt-get autoremove
sudo apt-get dist-upgrade


If this did not solve your issue, and the upgrade went without any errors or warnings, wee will try digging a bit more deep to see if we can find out what is causing the issue. You could get a lead by inspecting the contents of /var/log/unattended-upgrades. If you could figure out which update is causing the issue, you could blacklist the update by modifying /etc/apt/apt.conf.d/50unattended-upgrades.



If it still does not solve the issue, you can temporarily remove the package, to confirm if it is the cause:



sudo apt-get remove unattended-upgrades 


I recommend that you reinstall it even if it solved your issue. If this is the case bring back the the bug report with more information so that the developers can solve your issue.



Warning: If you choose to disable automatic update and then don't manually update your system, you may be at risk from security and stability view point.






share|improve this answer














From your Kernel Logs (Screenshot) I have a hunch that unattended-upgrades might be the cause of your issue. There have been several bug reports on this years ago, but they have not been resolved. A temporary fix to this would be to disable automatic updates by updates, but we will keep it as a last resort. But first of all, we will try a manual upgrade:



sudo apt-get autoremove
sudo apt-get dist-upgrade


If this did not solve your issue, and the upgrade went without any errors or warnings, wee will try digging a bit more deep to see if we can find out what is causing the issue. You could get a lead by inspecting the contents of /var/log/unattended-upgrades. If you could figure out which update is causing the issue, you could blacklist the update by modifying /etc/apt/apt.conf.d/50unattended-upgrades.



If it still does not solve the issue, you can temporarily remove the package, to confirm if it is the cause:



sudo apt-get remove unattended-upgrades 


I recommend that you reinstall it even if it solved your issue. If this is the case bring back the the bug report with more information so that the developers can solve your issue.



Warning: If you choose to disable automatic update and then don't manually update your system, you may be at risk from security and stability view point.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jun 8 '15 at 22:47

























answered Jun 8 '15 at 18:44









daltonfury42

3,32222052




3,32222052












  • This is a fresh install – autoremove and dist-upgrade have "0 to upgrade, 0 to remove" etc, and /var/log/unattended-upgrades is empty: $ wc -c < /var/log/unattended-upgrades/unattended-upgrades-shutdown.log gives 0
    – unhammer
    Jun 9 '15 at 6:52












  • Also, there are no programs in /lib/systemd/system-shutdown, so there are no services that should be called when I type poweroff. And removing unattended-upgrades completely had no effect.
    – unhammer
    Jun 9 '15 at 6:57




















  • This is a fresh install – autoremove and dist-upgrade have "0 to upgrade, 0 to remove" etc, and /var/log/unattended-upgrades is empty: $ wc -c < /var/log/unattended-upgrades/unattended-upgrades-shutdown.log gives 0
    – unhammer
    Jun 9 '15 at 6:52












  • Also, there are no programs in /lib/systemd/system-shutdown, so there are no services that should be called when I type poweroff. And removing unattended-upgrades completely had no effect.
    – unhammer
    Jun 9 '15 at 6:57


















This is a fresh install – autoremove and dist-upgrade have "0 to upgrade, 0 to remove" etc, and /var/log/unattended-upgrades is empty: $ wc -c < /var/log/unattended-upgrades/unattended-upgrades-shutdown.log gives 0
– unhammer
Jun 9 '15 at 6:52






This is a fresh install – autoremove and dist-upgrade have "0 to upgrade, 0 to remove" etc, and /var/log/unattended-upgrades is empty: $ wc -c < /var/log/unattended-upgrades/unattended-upgrades-shutdown.log gives 0
– unhammer
Jun 9 '15 at 6:52














Also, there are no programs in /lib/systemd/system-shutdown, so there are no services that should be called when I type poweroff. And removing unattended-upgrades completely had no effect.
– unhammer
Jun 9 '15 at 6:57






Also, there are no programs in /lib/systemd/system-shutdown, so there are no services that should be called when I type poweroff. And removing unattended-upgrades completely had no effect.
– unhammer
Jun 9 '15 at 6:57













0














I tried everything and after days a lowly rated fanswer from this forum did the trick: Ubuntu 14.04 stuck on shutdown




For me, the solution was to upgrade the kernel. I used 4.5.3 on Ubuntu
15.10 (anything greater than this will crash the OS after login) And 4.7 RC3 works on Ubuntu 16.04.




Now works perfectly :-)






share|improve this answer





















  • That didn't work for my system. As the bug reports show, I already tried quite a lot of 4.7 kernels – these just made it impossible to boot! After reporting upstream and debugging help from kernel list, the workaround to both my issues (booting at all, and powering off on shutdown) was acpi=noirq askubuntu.com/a/794739/25639
    – unhammer
    Nov 4 '16 at 8:25
















0














I tried everything and after days a lowly rated fanswer from this forum did the trick: Ubuntu 14.04 stuck on shutdown




For me, the solution was to upgrade the kernel. I used 4.5.3 on Ubuntu
15.10 (anything greater than this will crash the OS after login) And 4.7 RC3 works on Ubuntu 16.04.




Now works perfectly :-)






share|improve this answer





















  • That didn't work for my system. As the bug reports show, I already tried quite a lot of 4.7 kernels – these just made it impossible to boot! After reporting upstream and debugging help from kernel list, the workaround to both my issues (booting at all, and powering off on shutdown) was acpi=noirq askubuntu.com/a/794739/25639
    – unhammer
    Nov 4 '16 at 8:25














0












0








0






I tried everything and after days a lowly rated fanswer from this forum did the trick: Ubuntu 14.04 stuck on shutdown




For me, the solution was to upgrade the kernel. I used 4.5.3 on Ubuntu
15.10 (anything greater than this will crash the OS after login) And 4.7 RC3 works on Ubuntu 16.04.




Now works perfectly :-)






share|improve this answer












I tried everything and after days a lowly rated fanswer from this forum did the trick: Ubuntu 14.04 stuck on shutdown




For me, the solution was to upgrade the kernel. I used 4.5.3 on Ubuntu
15.10 (anything greater than this will crash the OS after login) And 4.7 RC3 works on Ubuntu 16.04.




Now works perfectly :-)







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 3 '16 at 20:49









COOLBEANS

101




101












  • That didn't work for my system. As the bug reports show, I already tried quite a lot of 4.7 kernels – these just made it impossible to boot! After reporting upstream and debugging help from kernel list, the workaround to both my issues (booting at all, and powering off on shutdown) was acpi=noirq askubuntu.com/a/794739/25639
    – unhammer
    Nov 4 '16 at 8:25


















  • That didn't work for my system. As the bug reports show, I already tried quite a lot of 4.7 kernels – these just made it impossible to boot! After reporting upstream and debugging help from kernel list, the workaround to both my issues (booting at all, and powering off on shutdown) was acpi=noirq askubuntu.com/a/794739/25639
    – unhammer
    Nov 4 '16 at 8:25
















That didn't work for my system. As the bug reports show, I already tried quite a lot of 4.7 kernels – these just made it impossible to boot! After reporting upstream and debugging help from kernel list, the workaround to both my issues (booting at all, and powering off on shutdown) was acpi=noirq askubuntu.com/a/794739/25639
– unhammer
Nov 4 '16 at 8:25




That didn't work for my system. As the bug reports show, I already tried quite a lot of 4.7 kernels – these just made it impossible to boot! After reporting upstream and debugging help from kernel list, the workaround to both my issues (booting at all, and powering off on shutdown) was acpi=noirq askubuntu.com/a/794739/25639
– unhammer
Nov 4 '16 at 8:25











0














I can confirm it definitely has something to do with ACPI. My system exhibits this exact behaviour if and only if I pass acpi=off in Linux 4.20-rc3 for kernel development purposes. If your ACPI was enabled at first, then there is a fair chance that the ACPI implementation in the BIOS was buggy. I see you said a kernel upgrade helped. But a BIOS upgrade may have done the trick, also.






share|improve this answer





















  • This does not actually answer the question. Your suggestion relating to the BIOS merely indicates a possible solution, one which it would appear you haven't actually tried. In fact, the OP indicated that he had solved his issue by "adding acpi=noirq to the kernel boot parameters".
    – CentaurusA
    Dec 19 at 18:00
















0














I can confirm it definitely has something to do with ACPI. My system exhibits this exact behaviour if and only if I pass acpi=off in Linux 4.20-rc3 for kernel development purposes. If your ACPI was enabled at first, then there is a fair chance that the ACPI implementation in the BIOS was buggy. I see you said a kernel upgrade helped. But a BIOS upgrade may have done the trick, also.






share|improve this answer





















  • This does not actually answer the question. Your suggestion relating to the BIOS merely indicates a possible solution, one which it would appear you haven't actually tried. In fact, the OP indicated that he had solved his issue by "adding acpi=noirq to the kernel boot parameters".
    – CentaurusA
    Dec 19 at 18:00














0












0








0






I can confirm it definitely has something to do with ACPI. My system exhibits this exact behaviour if and only if I pass acpi=off in Linux 4.20-rc3 for kernel development purposes. If your ACPI was enabled at first, then there is a fair chance that the ACPI implementation in the BIOS was buggy. I see you said a kernel upgrade helped. But a BIOS upgrade may have done the trick, also.






share|improve this answer












I can confirm it definitely has something to do with ACPI. My system exhibits this exact behaviour if and only if I pass acpi=off in Linux 4.20-rc3 for kernel development purposes. If your ACPI was enabled at first, then there is a fair chance that the ACPI implementation in the BIOS was buggy. I see you said a kernel upgrade helped. But a BIOS upgrade may have done the trick, also.







share|improve this answer












share|improve this answer



share|improve this answer










answered Dec 19 at 3:50









Karatekid430

61




61












  • This does not actually answer the question. Your suggestion relating to the BIOS merely indicates a possible solution, one which it would appear you haven't actually tried. In fact, the OP indicated that he had solved his issue by "adding acpi=noirq to the kernel boot parameters".
    – CentaurusA
    Dec 19 at 18:00


















  • This does not actually answer the question. Your suggestion relating to the BIOS merely indicates a possible solution, one which it would appear you haven't actually tried. In fact, the OP indicated that he had solved his issue by "adding acpi=noirq to the kernel boot parameters".
    – CentaurusA
    Dec 19 at 18:00
















This does not actually answer the question. Your suggestion relating to the BIOS merely indicates a possible solution, one which it would appear you haven't actually tried. In fact, the OP indicated that he had solved his issue by "adding acpi=noirq to the kernel boot parameters".
– CentaurusA
Dec 19 at 18:00




This does not actually answer the question. Your suggestion relating to the BIOS merely indicates a possible solution, one which it would appear you haven't actually tried. In fact, the OP indicated that he had solved his issue by "adding acpi=noirq to the kernel boot parameters".
– CentaurusA
Dec 19 at 18:00











-1














Your hardware might not support software shutdown. I've had that happen before, and the way to test is this:



sudo poweroff


If that does not shutdown the hardware, it's a hardware issue and not software.






share|improve this answer

















  • 3




    As the question states, I've tried that to no avail. But GRUB manages the software reboot just fine (not sure how to test poweroff there) while Windows 8.1 does the software poweroff and reboot just fine on this hardware. It seems like a kernel issue, so I've filed a bug report.
    – unhammer
    Jun 11 '15 at 6:22






  • 1




    upvote for filing a bug report.
    – Daniel
    Jun 11 '15 at 16:44










  • -1 Because I find otherwise. It ends with systemd-shutdown[1]: Powering off. The machine turned off just fine with 12.04 and 14.04, but not a fresh install of 16.04.
    – Nateowami
    Jun 26 '16 at 12:52
















-1














Your hardware might not support software shutdown. I've had that happen before, and the way to test is this:



sudo poweroff


If that does not shutdown the hardware, it's a hardware issue and not software.






share|improve this answer

















  • 3




    As the question states, I've tried that to no avail. But GRUB manages the software reboot just fine (not sure how to test poweroff there) while Windows 8.1 does the software poweroff and reboot just fine on this hardware. It seems like a kernel issue, so I've filed a bug report.
    – unhammer
    Jun 11 '15 at 6:22






  • 1




    upvote for filing a bug report.
    – Daniel
    Jun 11 '15 at 16:44










  • -1 Because I find otherwise. It ends with systemd-shutdown[1]: Powering off. The machine turned off just fine with 12.04 and 14.04, but not a fresh install of 16.04.
    – Nateowami
    Jun 26 '16 at 12:52














-1












-1








-1






Your hardware might not support software shutdown. I've had that happen before, and the way to test is this:



sudo poweroff


If that does not shutdown the hardware, it's a hardware issue and not software.






share|improve this answer












Your hardware might not support software shutdown. I've had that happen before, and the way to test is this:



sudo poweroff


If that does not shutdown the hardware, it's a hardware issue and not software.







share|improve this answer












share|improve this answer



share|improve this answer










answered Jun 10 '15 at 19:22









Daniel

2,58811540




2,58811540








  • 3




    As the question states, I've tried that to no avail. But GRUB manages the software reboot just fine (not sure how to test poweroff there) while Windows 8.1 does the software poweroff and reboot just fine on this hardware. It seems like a kernel issue, so I've filed a bug report.
    – unhammer
    Jun 11 '15 at 6:22






  • 1




    upvote for filing a bug report.
    – Daniel
    Jun 11 '15 at 16:44










  • -1 Because I find otherwise. It ends with systemd-shutdown[1]: Powering off. The machine turned off just fine with 12.04 and 14.04, but not a fresh install of 16.04.
    – Nateowami
    Jun 26 '16 at 12:52














  • 3




    As the question states, I've tried that to no avail. But GRUB manages the software reboot just fine (not sure how to test poweroff there) while Windows 8.1 does the software poweroff and reboot just fine on this hardware. It seems like a kernel issue, so I've filed a bug report.
    – unhammer
    Jun 11 '15 at 6:22






  • 1




    upvote for filing a bug report.
    – Daniel
    Jun 11 '15 at 16:44










  • -1 Because I find otherwise. It ends with systemd-shutdown[1]: Powering off. The machine turned off just fine with 12.04 and 14.04, but not a fresh install of 16.04.
    – Nateowami
    Jun 26 '16 at 12:52








3




3




As the question states, I've tried that to no avail. But GRUB manages the software reboot just fine (not sure how to test poweroff there) while Windows 8.1 does the software poweroff and reboot just fine on this hardware. It seems like a kernel issue, so I've filed a bug report.
– unhammer
Jun 11 '15 at 6:22




As the question states, I've tried that to no avail. But GRUB manages the software reboot just fine (not sure how to test poweroff there) while Windows 8.1 does the software poweroff and reboot just fine on this hardware. It seems like a kernel issue, so I've filed a bug report.
– unhammer
Jun 11 '15 at 6:22




1




1




upvote for filing a bug report.
– Daniel
Jun 11 '15 at 16:44




upvote for filing a bug report.
– Daniel
Jun 11 '15 at 16:44












-1 Because I find otherwise. It ends with systemd-shutdown[1]: Powering off. The machine turned off just fine with 12.04 and 14.04, but not a fresh install of 16.04.
– Nateowami
Jun 26 '16 at 12:52




-1 Because I find otherwise. It ends with systemd-shutdown[1]: Powering off. The machine turned off just fine with 12.04 and 14.04, but not a fresh install of 16.04.
– Nateowami
Jun 26 '16 at 12:52











-1















  1. Restart then F2

  2. Go to configuration and disable xHCI

  3. Save and exit


Don't think about it just trust me and do it :)






share|improve this answer





















  • I can't find any XHCI settings in BIOS anywhere. I can turn off all of USB, but that's not an option for me.
    – unhammer
    Jun 14 '15 at 19:39










  • this will not turn all usb it will only turn usb3
    – Talal
    Jun 15 '15 at 11:36
















-1















  1. Restart then F2

  2. Go to configuration and disable xHCI

  3. Save and exit


Don't think about it just trust me and do it :)






share|improve this answer





















  • I can't find any XHCI settings in BIOS anywhere. I can turn off all of USB, but that's not an option for me.
    – unhammer
    Jun 14 '15 at 19:39










  • this will not turn all usb it will only turn usb3
    – Talal
    Jun 15 '15 at 11:36














-1












-1








-1







  1. Restart then F2

  2. Go to configuration and disable xHCI

  3. Save and exit


Don't think about it just trust me and do it :)






share|improve this answer













  1. Restart then F2

  2. Go to configuration and disable xHCI

  3. Save and exit


Don't think about it just trust me and do it :)







share|improve this answer












share|improve this answer



share|improve this answer










answered Jun 13 '15 at 18:43









Talal

56958




56958












  • I can't find any XHCI settings in BIOS anywhere. I can turn off all of USB, but that's not an option for me.
    – unhammer
    Jun 14 '15 at 19:39










  • this will not turn all usb it will only turn usb3
    – Talal
    Jun 15 '15 at 11:36


















  • I can't find any XHCI settings in BIOS anywhere. I can turn off all of USB, but that's not an option for me.
    – unhammer
    Jun 14 '15 at 19:39










  • this will not turn all usb it will only turn usb3
    – Talal
    Jun 15 '15 at 11:36
















I can't find any XHCI settings in BIOS anywhere. I can turn off all of USB, but that's not an option for me.
– unhammer
Jun 14 '15 at 19:39




I can't find any XHCI settings in BIOS anywhere. I can turn off all of USB, but that's not an option for me.
– unhammer
Jun 14 '15 at 19:39












this will not turn all usb it will only turn usb3
– Talal
Jun 15 '15 at 11:36




this will not turn all usb it will only turn usb3
– Talal
Jun 15 '15 at 11:36


















draft saved

draft discarded




















































Thanks for contributing an answer to Ask Ubuntu!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f632591%2fsystem-does-not-power-off-on-poweroff-just-halts%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

How did Captain America manage to do this?

迪纳利

南乌拉尔铁路局