Laptop reboot instead of shutting down

Hi everyone!

This has been driving me nuts.

I am running OpenSuse Leap 15.2 on Acer Travelmate B-118M (DualBooted with Windows 10 on one drive). The OpenSuse installation is using LUKS encryption on root and home partittions.

Whenever I try to shutdown the laptop (yes, using any method–shutdown, poweroff with all sorts of parameters, etc), the laptop reboots but does not shutdown.

It looks like some sort of a bios/efi bug. Nothing I tried worked.

I tried specifying acpi=noirq kernal parameter. However, I cannot enter the decryption password on the LUKS prompt because the keyboard does not work with this.

The laptop also does not have a shutdown button (no, seriouly, it does not – the power button will not shut it down even if you hold it down for a while and a battery cut button just forcefully reboots it). I just cannot shut it down…

Thank you for your help! Any ideas?

I assume power-off on Windows is working, right?

On this page, How to shut down a Linux PC that won’t turn off I read there is also a poweroff command, does that work for you?
If it does not work what does the systemlog tell after issuing the command?

This is the first time I have heard of a case where “shutdown -h now” has not worked.

A surf on this indicated 6 years ago some users had it - probably different issue, but they did find somethings that worked (PC dependent). The thread I found was here (go to end of thread) : linux - Debian Wheezy rebooting instead of powering off - Unix & Linux Stack Exchange … and maybe try those suggestions.

Another thread is here: 12.04 - Why do I get a reboot instead of a shutdown? - Ask Ubuntu … one user’s PC’s BIOS was set to ‘wake on LAN’ and it kept rebooting. Check your BIOS there to ensure that is not set. … That thread also has many other suggestions.

Apologies I have no specific fix, but I don’t have your hardware and I have never encountered this myself.

I also remember once having a PC (desktop type) that immediatly after shutdown woke up again if WOL was enabled in the BIOS.

Thank you all for your replies!

poweroff and shutdown -h now do not work :-(.

I will try the other techniques.

I also did an experiment with shutting down Windows and the same thing happens (which seems to point to a bios issue).

I have WOL and fastboot disabled in my BIOS.

Maybe knowing how it works with systemd will help:

# which shutdown
/sbin/shutdown
# ls -Gg /sbin/shutdown
lrwxrwxrwx 1 18 Feb  1 10:53 /sbin/shutdown -> /usr/bin/systemctl
# ls -Gg /usr/bin/systemctl
-rwxr-xr-x 1 182424 Feb  1 10:53 /usr/bin/systemctl
# man systemctl
...
poweroff
           Shut down and power-off the system. This is mostly equivalent to start poweroff.target --job-mode=replace-irreversibly, but also prints a wall message to all users. If combined with --force, shutdown of all running services is skipped, however all processes are killed and all file systems are unmounted or mounted read-only, immediately followed by the powering off. If --force is specified twice, the operation is immediately executed without terminating any processes or unmounting any file systems. This may result in data loss. Note that when --force is specified twice the power-off operation is executed by systemctl itself, and the system manager is not contacted. This means the command should succeed even when the system manager hangs or crashed....

Hi KittyKatty,
Besides WOL there may be other wake-on events to be configured in BIOS like keyboard, mouse, USB, PCIe etc. Maybe try and check for such options and switch off in case there’s any enabled.

Edit: Already considered a BIOS update?

kasi

Some background information:


 > rpm --query --whatprovides /sbin/poweroff
systemd-sysvinit-234-lp152.31.22.1.x86_64
 > 
 > file /sbin/poweroff
/sbin/poweroff: symbolic link to /usr/bin/systemctl
 > 
 > stat /sbin/poweroff
  File: /sbin/poweroff -> /usr/bin/systemctl
  Size: 18              Blocks: 0          IO Block: 4096   symbolic link
Device: 802h/2050d      Inode: 6947013     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-03-23 10:24:14.000000000 +0100
Modify: 2021-03-23 10:24:14.000000000 +0100
Change: 2021-03-26 19:06:51.611498088 +0100
 Birth: -
 > 
 > rpm --query --whatprovides /sbin/shutdown
systemd-sysvinit-234-lp152.31.22.1.x86_64
 > file /sbin/shutdown
/sbin/shutdown: symbolic link to /usr/bin/systemctl
 > 
 > stat /sbin/shutdown
  File: /sbin/shutdown -> /usr/bin/systemctl
  Size: 18              Blocks: 0          IO Block: 4096   symbolic link
Device: 802h/2050d      Inode: 6946942     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2021-03-23 10:24:14.000000000 +0100
Modify: 2021-03-23 10:24:14.000000000 +0100
Change: 2021-03-26 19:06:51.611498088 +0100
 Birth: -
 > 

Look carefully at the “rpm --query --whatprovides” output – “poweroff” and “shutdown” are, at least for openSUSE Leap/Tumbleweed, LEGACY SysVinit commands – pointing to the systemd command line interface (systemctl) …

  • You could try to forcibly re-install (zypper install --force
    ) the “systemd-sysvinit” package …

[HR][/HR]You do not mention which user Desktop and Display Manager you’re using …

  • I use KDE Plasma – no idea about the “rest of the world
    ” … - In the default KDE Display Manager – SDDM – the defaults are –
    =2]Halt command. Default value is "/usr/bin/systemctl poweroff*“.
    =2]Reboot command. Default value is "/usr/bin/systemctl reboot*”.

Hi
Does the same issue occur on the WinX side as well?

I think it does. In post # 5 above, the OP reported:

It does suggest a BIOS misconfiguration (or hardware issue), but as to which? I don’t know how to diagnose the specifics, and can only suggest trial and error changes in BIOS.

Hi
I had a laptop here doing that (HP 15) just a few days ago, had been shutting down/rebooting as well as keyboard problems. I should have it back soon for a fresh install on a new SSD and replacement keyboard. I did update the BIOS, no change, but all power options were on sleep (lid/power button). An acpi change perhaps…