system does not power off on “poweroff”, just halts
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:
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:
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
|
show 5 more comments
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:
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:
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
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 checkingdmesg
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 withjournalctl --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
|
show 5 more comments
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:
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:
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
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:
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:
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
shutdown
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 checkingdmesg
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 withjournalctl --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
|
show 5 more comments
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 checkingdmesg
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 withjournalctl --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
|
show 5 more comments
9 Answers
9
active
oldest
votes
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
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
|
show 5 more comments
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.
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
add a comment |
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.
What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
– unhammer
Feb 25 '16 at 14:06
add a comment |
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"
halt -p
is no different, it still doesn't shut down completely.
– unhammer
Jun 5 '15 at 11:45
oh, and /etc/default/halt saysHALT=poweroff
. But shouldn'thalt -p
orpoweroff
orshutdown now
still work regardless of what's in there?
– unhammer
Jun 5 '15 at 12:37
add a comment |
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.
This is a fresh install –autoremove
anddist-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
gives0
– 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 removingunattended-upgrades
completely had no effect.
– unhammer
Jun 9 '15 at 6:57
add a comment |
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 :-)
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) wasacpi=noirq
askubuntu.com/a/794739/25639
– unhammer
Nov 4 '16 at 8:25
add a comment |
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.
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
add a comment |
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.
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 withsystemd-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
add a comment |
- Restart then F2
- Go to configuration and disable xHCI
- Save and exit
Don't think about it just trust me and do it :)
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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
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
|
show 5 more comments
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
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
|
show 5 more comments
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
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
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
|
show 5 more comments
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
|
show 5 more comments
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
– unhammer
Feb 25 '16 at 14:06
add a comment |
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.
What system/BIOS was this? (Lenovo hasn't yet released an updated BIOS for my processor architecture.)
– unhammer
Feb 25 '16 at 14:06
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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"
halt -p
is no different, it still doesn't shut down completely.
– unhammer
Jun 5 '15 at 11:45
oh, and /etc/default/halt saysHALT=poweroff
. But shouldn'thalt -p
orpoweroff
orshutdown now
still work regardless of what's in there?
– unhammer
Jun 5 '15 at 12:37
add a comment |
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"
halt -p
is no different, it still doesn't shut down completely.
– unhammer
Jun 5 '15 at 11:45
oh, and /etc/default/halt saysHALT=poweroff
. But shouldn'thalt -p
orpoweroff
orshutdown now
still work regardless of what's in there?
– unhammer
Jun 5 '15 at 12:37
add a comment |
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"
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"
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 saysHALT=poweroff
. But shouldn'thalt -p
orpoweroff
orshutdown now
still work regardless of what's in there?
– unhammer
Jun 5 '15 at 12:37
add a comment |
halt -p
is no different, it still doesn't shut down completely.
– unhammer
Jun 5 '15 at 11:45
oh, and /etc/default/halt saysHALT=poweroff
. But shouldn'thalt -p
orpoweroff
orshutdown 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
add a comment |
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.
This is a fresh install –autoremove
anddist-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
gives0
– 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 removingunattended-upgrades
completely had no effect.
– unhammer
Jun 9 '15 at 6:57
add a comment |
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.
This is a fresh install –autoremove
anddist-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
gives0
– 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 removingunattended-upgrades
completely had no effect.
– unhammer
Jun 9 '15 at 6:57
add a comment |
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.
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.
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
anddist-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
gives0
– 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 removingunattended-upgrades
completely had no effect.
– unhammer
Jun 9 '15 at 6:57
add a comment |
This is a fresh install –autoremove
anddist-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
gives0
– 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 removingunattended-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
add a comment |
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 :-)
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) wasacpi=noirq
askubuntu.com/a/794739/25639
– unhammer
Nov 4 '16 at 8:25
add a comment |
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 :-)
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) wasacpi=noirq
askubuntu.com/a/794739/25639
– unhammer
Nov 4 '16 at 8:25
add a comment |
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 :-)
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 :-)
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) wasacpi=noirq
askubuntu.com/a/794739/25639
– unhammer
Nov 4 '16 at 8:25
add a comment |
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) wasacpi=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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
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 withsystemd-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
add a comment |
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.
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 withsystemd-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
add a comment |
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.
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.
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 withsystemd-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
add a comment |
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 withsystemd-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
add a comment |
- Restart then F2
- Go to configuration and disable xHCI
- Save and exit
Don't think about it just trust me and do it :)
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
add a comment |
- Restart then F2
- Go to configuration and disable xHCI
- Save and exit
Don't think about it just trust me and do it :)
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
add a comment |
- Restart then F2
- Go to configuration and disable xHCI
- Save and exit
Don't think about it just trust me and do it :)
- Restart then F2
- Go to configuration and disable xHCI
- Save and exit
Don't think about it just trust me and do it :)
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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