Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] no poweroff on reboot or shutdown
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Wed Dec 27, 2023 4:30 am    Post subject: [SOLVED] no poweroff on reboot or shutdown Reply with quote

My system recently picked up a bug where it won't poweroff when I issue either "reboot" or "shutdown -h now". In both cases, it goes through the normal shutdown steps, but halts without an error message at the power-off stage. This sounds nearly identical to this thread:

https://unix.stackexchange.com/questions/264189/computer-doesnt-power-off-at-shutdown-reboot-arch

But their solution, adding "acpi=force" to GRUB_COMMAND_LINE_DEFAULT didn't work for me.

Unfortunately, I don't reboot that often, so I'm not sure when this first started, except that it was in the past few months, so it's hard to say when update(s) might have caused it.

Any ideas?


Last edited by jyoung on Wed Jun 05, 2024 6:33 pm; edited 1 time in total
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Thu Dec 28, 2023 10:29 pm    Post subject: Reply with quote

I also tried setting "acpi=off" in grub. To me, this seems counter intuitive, but I wanted to see what would happen. This had no effect on this issue, and the only change I can see is that the system isn't able to set the hardware clock at boot.

I also looked through the bio settings, and couldn't find anything that seemed related.

One other note: this system is dual-booted with windows, and, although I mostly just use linux, yesterday I had to boot into windows. Windows was able to poweroff without issues, so I doubt that it's a hardware problem.
Back to top
View user's profile Send private message
entity
Tux's lil' helper
Tux's lil' helper


Joined: 16 Jun 2002
Posts: 93
Location: Joensuu, Finland

PostPosted: Sun Feb 04, 2024 6:27 pm    Post subject: Reply with quote

I recently faced similar issue after system update. For me, it was
Code:
sys-apps/sysvinit-3.08
that caused it, and reverting to
Code:
sys-apps/sysvinit-3.07
got poweroff working again.

Edit: this post seems to cover the issue.
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Tue Apr 23, 2024 3:50 am    Post subject: Reply with quote

entity, thanks for chiming in, I'm still scratching my head on this one. I just tried rolling back to

Code:
sys-apps/sysvinit-3.07


but no luck.
Back to top
View user's profile Send private message
amair
n00b
n00b


Joined: 12 Aug 2003
Posts: 63

PostPosted: Tue Apr 23, 2024 6:09 am    Post subject: Reply with quote

When I upgraded to sys-apps/sysvinit-3.08 I received this elog message:
Quote:
Previously, the 'halt' command caused the system to power off even if option -p was not given. This long-standing bug has been fixed, and the command now behaves as documented.

So if I read "man shutdown" correctly, you should run "shutdown -h -P now".

"man halt" says you must run "halt -p" or "poweroff".
Back to top
View user's profile Send private message
entity
Tux's lil' helper
Tux's lil' helper


Joined: 16 Jun 2002
Posts: 93
Location: Joensuu, Finland

PostPosted: Tue Apr 23, 2024 1:16 pm    Post subject: Reply with quote

amair wrote:

"man halt" says you must run "halt -p" or "poweroff".


Indeed. But I gotta say, it took a while to override the default behavior between chair and keyboard, since I have been typing "halt" for the past 20+ years to turn off my workstation. :lol:
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Wed Apr 24, 2024 8:55 pm    Post subject: Reply with quote

Interesting... I just tried

Code:
shutdown -h -P now


And for the sake thoroughness

Code:
shutdown -h -P now


And neither of these worked.
Back to top
View user's profile Send private message
wjb
l33t
l33t


Joined: 10 Jul 2005
Posts: 629
Location: Fife, Scotland

PostPosted: Thu Apr 25, 2024 11:50 am    Post subject: Reply with quote

Just add one line in ~/.bashrc and carry on as normal
Code:

alias halt="poweroff"
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22578

PostPosted: Thu Apr 25, 2024 12:27 pm    Post subject: Reply with quote

Although the timing is unfortunate, it looks to me like OP's problem has nothing to do with the bug fix in sys-apps/sysvinit. OP specifically stated that he tried using the pre-fix version, and it did not help. Additionally, he has tried the elaborated invocation that is supposed to work in the post-fix version, and it does not help. I have used shutdown -h now successfully, and the system powered off, when using =sys-apps/sysvinit-3.08, a version which supposedly requires you to "do it right." Based on all this, I think OPs' problem is not in with the bug fix in sys-apps/sysvinit. Instead, this is some other problem. OP: if you increase the kernel's output verbosity, do the final lines left on screen provide anything useful? Does the sysrq that forces an immediate poweroff (without syncing, so you must save your data first!) turn off power in the bad case? Based on your kernel upgrade history, is there a last known good / first known bad kernel?
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Sun Apr 28, 2024 4:39 am    Post subject: Reply with quote

Hu, that's a neat trick, I didn't know about sysrq until now. If I force a shutdown with

Code:
echo t > /proc/sysrq-trigger


The power stays on. However, if I force a reboot with

Code:
echo b > /proc/sysrq-trigger


then it actually does reboot, which I don't get with the shutdown or reboot commands.

If I set the kernel argument loglevel=8 and reboot, then these messages appear in /var/log/messages the next time I attempt a shutdown

Code:
Apr 28 00:16:30 homebox shutdown[4192]: shutting down for system halt
Apr 28 00:16:30 homebox init[1]: Switching to runlevel: 0
Apr 28 00:16:30 homebox elogind-daemon[4146]: Removed session 2.
Apr 28 00:16:30 homebox su[4187]: pam_unix(su:session): session closed for user root
Apr 28 00:16:30 homebox init[1]: Trying to re-exec init
Apr 28 00:16:30 homebox start-stop-daemon[4261]: Will stop /usr/sbin/sshd
Apr 28 00:16:30 homebox start-stop-daemon[4261]: Will stop PID 4103
Apr 28 00:16:30 homebox start-stop-daemon[4261]: Sending signal 15 to PID 4103
Apr 28 00:16:30 homebox sshd[4103]: Received signal 15; terminating.
Apr 28 00:16:30 homebox start-stop-daemon[4357]: Will stop /usr/sbin/nginx
Apr 28 00:16:30 homebox start-stop-daemon[4357]: Will stop PID 4071
Apr 28 00:16:30 homebox start-stop-daemon[4357]: Sending signal 15 to PID 4071
Apr 28 00:16:31 homebox start-stop-daemon[4433]: Will stop /usr/sbin/rpc.idmapd
Apr 28 00:16:31 homebox start-stop-daemon[4433]: Sending signal 15 to PID 3974
Apr 28 00:16:31 homebox rpc.idmapd[3974]: exiting on signal 15
Apr 28 00:16:31 homebox start-stop-daemon[4479]: Will stop /sbin/rpc.statd
Apr 28 00:16:31 homebox start-stop-daemon[4479]: Will stop PID 3914
Apr 28 00:16:31 homebox start-stop-daemon[4479]: Sending signal 15 to PID 3914
Apr 28 00:16:31 homebox start-stop-daemon[4503]: Will stop /sbin/rpcbind
Apr 28 00:16:31 homebox start-stop-daemon[4503]: Sending signal 15 to PID 3884
Apr 28 00:16:31 homebox start-stop-daemon[4600]: Will stop /usr/sbin/crond
Apr 28 00:16:31 homebox start-stop-daemon[4600]: Will stop PID 3855
Apr 28 00:16:31 homebox start-stop-daemon[4600]: Sending signal 15 to PID 3855
Apr 28 00:16:31 homebox crond[3855]: (CRON) INFO (Shutting down)
Apr 28 00:16:31 homebox start-stop-daemon[4673]: Will stop /usr/bin/dbus-daemon
Apr 28 00:16:31 homebox start-stop-daemon[4673]: Will stop PID 3453
Apr 28 00:16:31 homebox start-stop-daemon[4673]: Sending signal 15 to PID 3453
Apr 28 00:16:31 homebox start-stop-daemon[4702]: Will stop /usr/sbin/syslog-ng
Apr 28 00:16:31 homebox start-stop-daemon[4702]: Will stop PID 3420
Apr 28 00:16:31 homebox syslog-ng[3420]: syslog-ng shutting down; version='4.6.0'
Apr 28 00:16:31 homebox start-stop-daemon[4702]: Sending signal 15 to PID 3420


Nothing looks weird to me here, but maybe you folks can spot something.

Looking back at kernel updates and other config history, unfortunately I can't pin down anything change that might have caused this. I actually don't reboot that often, and it took me a while to realize that this was a serious and persistent problem.
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22578

PostPosted: Sun Apr 28, 2024 2:45 pm    Post subject: Reply with quote

jyoung wrote:
Hu, that's a neat trick, I didn't know about sysrq until now. If I force a shutdown with
Code:
echo t > /proc/sysrq-trigger
The power stays on.
Is this a typo? If not, then the results are expected. Per Documentation/admin-guide/sysrq.rst, sysrq t dumps task information. It is not expected to power off the system. For power off, use sysrq o.
Documentation/admin-guide/sysrq.rst:
``o``       Will shut your system off (if configured and supported).

``t``       Will dump a list of current tasks and their information to your
            console.
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Sun Apr 28, 2024 3:21 pm    Post subject: Reply with quote

Sorry, yes, that was a typo. I was using

Code:
echo o > /proc/sysrq-trigger
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22578

PostPosted: Sun Apr 28, 2024 3:34 pm    Post subject: Reply with quote

Good. That confirms this is a kernel problem. I have never seen a kernel that allowed use of sysrq-poweroff and failed to instantly kill power when that was used. Now that we know it is a kernel problem, you can either search backward to find when it last worked, or try a newer kernel to see if it is already fixed.

If you switch to a text console, raise the kernel's verbosity to maximum, and issue a sysrq-poweroff, is there any useful output? Normally, such output would be lost almost instantly when the system loses power, but perhaps there will be something useful shown on screen in your case.
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Wed Jun 05, 2024 5:20 am    Post subject: Reply with quote

It's been a while since I posted to this thread, but it took some time to follow up on this.

Looking back at the older kernels I had lying around, none were really viable. So, I tried to go forward instead of backward, and updated from 6.5.5 to 6.8.7. My plan was to install the default 6.8.7, check to see if the issue persisted (hopefully no), do a full migration with make olddefconfig and check to see if that had an issue (probably yes), and then bisect the differences in kernel configs until I located the element of the configuration that was causing the issue.

However, I discovered that none of the installs of 6.8.7 have this problem. This is true even for a full migrating all the config features with make olddefconfig. That seemed really strange, so I went back and reinstalled 6.5.5, and the issue came back. So, it appears that the problem is specific to the kernel version.

Any ideas?

From a practical standpoint, this problem is basically fixed, although I'm not sure what caused it, and I doubt that this thread will translate into practical advice for future readers.
Back to top
View user's profile Send private message
Hu
Administrator
Administrator


Joined: 06 Mar 2007
Posts: 22578

PostPosted: Wed Jun 05, 2024 11:45 am    Post subject: Reply with quote

If it is fixed in a newer version, I would use that newer version and be satisfied with it. It was likely a bug in some kernel version that it did not use the proper invocation to trigger a power-off for your hardware, and newer kernels use the proper method.

If you want to find specifically what fixed it, you could bisect between the last known bad and first known good kernels, to find how it was fixed.
Back to top
View user's profile Send private message
jyoung
Guru
Guru


Joined: 20 Mar 2007
Posts: 467

PostPosted: Wed Jun 05, 2024 6:32 pm    Post subject: Reply with quote

Okay, let mark this as SOVLED. If for some reason I do end up going back and forth between versions, make note of this issue and report back.
Back to top
View user's profile Send private message
mrpingo
n00b
n00b


Joined: 14 Jun 2014
Posts: 3

PostPosted: Wed Sep 04, 2024 11:15 pm    Post subject: Reply with quote

Sorry to interrupt here, but I was having the same issue since kernels 6.7.X and up, this looks like the same behaviour that I have been suffering and could not get any recent information online nor forums, nor bugzilla, so I created two tickets, one in https://bugzilla.kernel.org/show_bug.cgi?id=218904 and another one in https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11244. jyoung can you tell us if this is related to your issue? Do you have an intel GPU?

Speculating, It would be helpful to write down this issue attached to a reported bug since there is no info anywhere and never asked the forums since it looks like a kernel bug since the beggining.

Best

PS: Sorry if this is not the way or place to point this out :S.
Back to top
View user's profile Send private message
bitnick
n00b
n00b


Joined: 07 Jan 2007
Posts: 25
Location: Stockholm, Sweden

PostPosted: Sun Sep 22, 2024 6:04 am    Post subject: Reply with quote

I had a similar problem with linux-6.6.47: my computer refused to power off; instead it always restarted (with a rather weird dual-reboot-hiccup at that).

This problem went away when I upgraded to linux-6.10.10. But simultaneously I also made a kernel config change: I had set CONFIG_RESET_ATTACK_MITIGATION=y (as suggested by the Kernel Self Protection Project). During the upgrade I actually read the info linked by KSPP and realised that I neither needed this nor had the necessary user space scripts in place, so I removed this setting.

A bit of a long shot, but maybe it was related at least in my case, since IIUC it basically tells the EFI to zero all RAM on unclean shutdowns/reboots (i.e. where no shutdown script has reset the EFI Memory Overwrite Request bit).
Back to top
View user's profile Send private message
eccerr0r
Watchman
Watchman


Joined: 01 Jul 2004
Posts: 9815
Location: almost Mile High in the USA

PostPosted: Sun Sep 22, 2024 7:40 am    Post subject: Reply with quote

I wonder how many newbies here wonder why poweroff isn't the default...

... and once again this is historical.

Old Un*x workstations, when you halted them, went back to ROM monitor, a command line boot and hardware diagnostic software. This would have been done for PCs too prior to ATX and soft power off, but PCs then didn't come with a ROM monitor. So they just hung there for non-ATX so you can switch off power.

Now with ATX, there's no real reason to leave it on. But with EFI/EFIshell, it would be nice to drop to this "ROM monitor", alas, I think PCs still destroyed all state making it impossible to return back to EFI, and a system reset is needed anyway...

That being said I had one motherboard with ACPI that would reboot when submitted the command to power off, so there has been known to be bugs in ACPI implementation. Disabling it defeats the purpose as without ACPI there's no way to access the hooks to power off the machine.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum