Been having an issue where sometimes I reboot via “reboot” or “systemctl reboot” and my pc just does not reboot, it stays on and just hangs. I have to hold the power button to force it off.
It also appears to do this via shutdown sometomes, but I think this may correlate with the reboot issue.
I have and amd cpu and Igpu.
I have tried the kernel params reboot=acpi and reboot=pci but neither work.
Upon rebooting I ran sudo journalctl -k -b -1 here is the output
It mainly does it on reboot but sometimes shutdown, which could be related. Fixing reboot issue is main aim I think.
I should mention that there is no message on the screen at all, I reboot it does this as it sorta reinitialises into the OS. My keyboard lights go off completely and the monitor source times out.
bootloader is systemd-boot btw.
I really unsure what to do at this point. I would appreciate some help troubleshooting.
Hmm you posted the Kernel log of the restarting PC. More interesting should be the log up to the hard reset. Try sudo journalctl -k -b -1 (or -2…). I am not sure, if anyone could help you then, though.
The log I have shared is via pastebin, in the original post above. It has an error relating to watchdog at the bottom so I believe that to be at least somewhat related.
I have had some success in blacklisting it but do still seem to get some reboot issues. I have all this time had shutdown issues sometimes (before any blacklisting btw).
I am trying some kernel params like reboot=pci and will maybe see if a bios update is available too.
What I mean is, share the logs without limiting the logs to the kernel output.
-k turns off logs from non-kernel services, but your logs clearly indicate that something non-kernel related takes forever. We can’t see what’s causing your issue because you’re omitting the logs that would tell you.
The watchdog is part of the kernel and in charge of checking for shutdown issues. This is why it’s appearing in your logs; kernel logs are permitted, and something is going wrong with shutdown. It’s also one of the last messages the kernel will write, so it’s very visible. It’s a red herring if you have no clue about what’s going on.
That doesn’t mean disabling it makes any sense, it just hides the problems while doing nothing about them. The correct solution is fixing the issue the watchdog complains about, which probably means adding an ExecStop somewhere or setting a shorter SIGHUP limit.
It’s unlikely random changes to your kernel config or firmware will fix anything. Flinging-shit-at-the-wall debugging sometimes works, but more often than not it’s just placebo, and it can cause other issues, especially if you don’t later narrow it down to a specific issue and just keep the superfluous shit stuck to your wall.
yeah your right. I was just trying anything tbh. I am quite new to debugging these issues with Linux so please excuse my basic errors. Got both logs here now:
Alright, nothing obvious hanging after all. In fact it looks like that was a successful shutdown; did you experience a hang this time?
I do note two things though:
It looks like you were running nixos-rebuild switch just before this reboot, and it in fact was still running when the shutdown occurred
Obviously, shutting down while the system is switching seems like a weird thing to do.
If you intend to reboot anyway, use nixos-rebuild boot rather than switch - generally, switch should only be used if you make small configuration changes. Since switch does not reboot, it will potentially replace binaries without replacing the associated services. This can cause all kinds of problems, I can imagine it causing shutdown issues.
There are like 10 swap partitions being disabled. This seems super unusual. What does your disk partitioning look like?
It is strange why nixos-rebuild switch would still be running. I did make some minor changes I think I added marktext to my packages or enabled java. I tended to find rebuilds trigger it more often so was doing that to try trigger it to get an up to date log. Could I be rebooting too soon after a rebuild?
I created most of my configuration in a vm, then transfered all of it to the actual system. The username was the same so I overrode configuration.nix and added the rest of the files, but did NOT touch hardware-configuration.nix.
lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 230.9G 0 disk └─sda1 8:1 1 230.9G 0 part /run/media/me/256gb nvme0n1 259:0 0 476.9G 0 disk ├─nvme0n1p1 259:1 0 1G 0 part /boot ├─nvme0n1p2 259:2 0 467.1G 0 part /nix/store │ / └─nvme0n1p3 259:3 0 8.8G 0 part [SWAP]
Maybe, though I don’t actually believe that to be the cause.
I don’t spot anything immediately in your configuration. There may be bugs e.g. with early-boot mullvad + the rest of your networking config.
If you remove practically all your configuration, and just leave the essentials (i.e., systemd-boot + your filesystem config), can you reproduce this behavior?
Yeah, that seems quite plausible. It’s a pretty unusual device.
In that case, firmware updates and trying to work around firmware bugs is indeed your best way forward, sorry, assumed you were on a more beaten path.
You can try to set acpi=force, since this affects both reboot and shutdown. Other values won’t change much. If that doesn’t work, the vendor’s support email or forums specific to their devices are your next best bet - folks on the NixOS discourse won’t be able to help much.
Alternatively, or if forcing acpi does work, the kernel mailing list, but you will most likely have to do the actual work yourself, which will mean learning how to do kernel development. Debugging firmware handover is probably not the most comfortable entry, you’re better off getting the OEM’s developers to look into it.