13

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 \EFI\ubuntu\shimx64.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.

  • 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
  • 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

10 Answers 10

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

| 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

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.

| 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.

| 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"
| 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.

| 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 :-)

| 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.

| 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 '18 at 18:00
0

I have had the same problem and believe that it is related to the UEFI boot. On an Acer Aspire V 11, originally Windows 8, I have done a fresh install of OpenSUSE Leap 15.0 with EFI boot and secure boot set to "disabled" in the BIOS. Now the shutdown, reboot and suspend work correctly.

Previously, I was using Ubuntu 16.04, 18.04 and most recently 18.10 under legacy boot and they all suffered the same problem. I also tried Fedora 24, OpenSUSE Tumbleweed and OpenSUSE 42.2, all with the same problem.

I also tried Ubuntu 18.10 with EFI boot and secure boot enabled but got a non-bootable device error. I did not try EFI boot with secure boot disabled.

| improve this answer | |
-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.

| 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 :)

| 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

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.