View previous topic :: View next topic |
Author |
Message |
jyoung Guru
Joined: 20 Mar 2007 Posts: 467
|
Posted: Wed Dec 27, 2023 4:30 am Post subject: [SOLVED] no poweroff on reboot or shutdown |
|
|
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 |
|
|
jyoung Guru
Joined: 20 Mar 2007 Posts: 467
|
Posted: Thu Dec 28, 2023 10:29 pm Post subject: |
|
|
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 |
|
|
entity Tux's lil' helper
Joined: 16 Jun 2002 Posts: 93 Location: Joensuu, Finland
|
Posted: Sun Feb 04, 2024 6:27 pm Post subject: |
|
|
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 |
|
|
jyoung Guru
Joined: 20 Mar 2007 Posts: 467
|
Posted: Tue Apr 23, 2024 3:50 am Post subject: |
|
|
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 |
|
|
amair n00b
Joined: 12 Aug 2003 Posts: 63
|
Posted: Tue Apr 23, 2024 6:09 am Post subject: |
|
|
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 |
|
|
entity Tux's lil' helper
Joined: 16 Jun 2002 Posts: 93 Location: Joensuu, Finland
|
Posted: Tue Apr 23, 2024 1:16 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
jyoung Guru
Joined: 20 Mar 2007 Posts: 467
|
Posted: Wed Apr 24, 2024 8:55 pm Post subject: |
|
|
Interesting... I just tried
And for the sake thoroughness
And neither of these worked. |
|
Back to top |
|
|
wjb l33t
Joined: 10 Jul 2005 Posts: 629 Location: Fife, Scotland
|
Posted: Thu Apr 25, 2024 11:50 am Post subject: |
|
|
Just add one line in ~/.bashrc and carry on as normal
Code: |
alias halt="poweroff"
|
|
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22578
|
Posted: Thu Apr 25, 2024 12:27 pm Post subject: |
|
|
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 |
|
|
jyoung Guru
Joined: 20 Mar 2007 Posts: 467
|
Posted: Sun Apr 28, 2024 4:39 am Post subject: |
|
|
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 |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22578
|
Posted: Sun Apr 28, 2024 2:45 pm Post subject: |
|
|
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 |
|
|
jyoung Guru
Joined: 20 Mar 2007 Posts: 467
|
Posted: Sun Apr 28, 2024 3:21 pm Post subject: |
|
|
Sorry, yes, that was a typo. I was using
Code: | echo o > /proc/sysrq-trigger |
|
|
Back to top |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22578
|
Posted: Sun Apr 28, 2024 3:34 pm Post subject: |
|
|
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 |
|
|
jyoung Guru
Joined: 20 Mar 2007 Posts: 467
|
Posted: Wed Jun 05, 2024 5:20 am Post subject: |
|
|
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 |
|
|
Hu Administrator
Joined: 06 Mar 2007 Posts: 22578
|
Posted: Wed Jun 05, 2024 11:45 am Post subject: |
|
|
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 |
|
|
jyoung Guru
Joined: 20 Mar 2007 Posts: 467
|
Posted: Wed Jun 05, 2024 6:32 pm Post subject: |
|
|
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 |
|
|
mrpingo n00b
Joined: 14 Jun 2014 Posts: 3
|
Posted: Wed Sep 04, 2024 11:15 pm Post subject: |
|
|
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 |
|
|
bitnick n00b
Joined: 07 Jan 2007 Posts: 25 Location: Stockholm, Sweden
|
Posted: Sun Sep 22, 2024 6:04 am Post subject: |
|
|
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 |
|
|
eccerr0r Watchman
Joined: 01 Jul 2004 Posts: 9815 Location: almost Mile High in the USA
|
Posted: Sun Sep 22, 2024 7:40 am Post subject: |
|
|
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 |
|
|
|