[SOLVED] no poweroff on reboot or shutdown

jyoung · Guru Joined: 20 Mar 2007 Posts: 467

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?

jyoung · Guru Joined: 20 Mar 2007 Posts: 467

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.

entity · Posted: Sun Feb 04, 2024 6:27 pm Post subject:

I recently faced similar issue after system update. For me, it was

jyoung · Guru Joined: 20 Mar 2007 Posts: 467

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

amair · n00b Joined: 12 Aug 2003 Posts: 63

When I upgraded to sys-apps/sysvinit-3.08 I received this elog message:

entity · Posted: Tue Apr 23, 2024 1:16 pm Post subject:

jyoung · Guru Joined: 20 Mar 2007 Posts: 467

Interesting... I just tried

wjb · Posted: Thu Apr 25, 2024 11:50 am Post subject:

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

Hu · Administrator Joined: 06 Mar 2007 Posts: 22650

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?

jyoung · Guru Joined: 20 Mar 2007 Posts: 467

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

Hu · Administrator Joined: 06 Mar 2007 Posts: 22650

jyoung · Guru Joined: 20 Mar 2007 Posts: 467

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

Hu · Administrator Joined: 06 Mar 2007 Posts: 22650

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.

jyoung · Guru Joined: 20 Mar 2007 Posts: 467

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.

Hu · Administrator Joined: 06 Mar 2007 Posts: 22650

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.

jyoung · Guru Joined: 20 Mar 2007 Posts: 467

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.

mrpingo · n00b Joined: 14 Jun 2014 Posts: 3

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.

bitnick · 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).

eccerr0r · 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?