Debian 13 lockup on reboot

Feb 20, 2025
14
8
3
Has anyone noticed lockups with Debian 13 guests when rebooting from CLI? I am on PVE 8.4.12 with a licensed 3-node cluster. I have three Debian Linux VMs (no GUI) and they are pretty modest 1 socket / 4 core setups with no NUMA. When I issue a "sudo reboot" I get a "TASK ERROR: VM quit/powerdown failed". The VM is still running but you can't ssh into it, and the CLI console is frozen on the login screen. My only option is to stop it with Proxmox.

It never happened to me with Debian 12 guests. I ran that for several months and it was always perfect, so thinking it's something to do with Debian 13. Now on 13.1. I had one server that is an upgrade from Debian Bookworm (12). The other two servers are fresh recent installs of Debian Trixie (13). The lockups have happened on all 3 of my nodes, and for all of the Debian 13 guests. All the guests run Docker, but they were running Docker on Debian 12 when there was no issues.

If someone knows a fix to this and can clue me in - that would be fantastic (without having to upgrade to PVE 9..... which I will do but not just yet).
 
The exact same thing is happening to me. I have been experiencing this on PVE 8.4.1 as well as on PVE 9.0.10 (both community).
I have been experiencing this on HP DL360g9 with Xeon E5-2680 v4 and on DELL PowerEdge with EPYC 7313P.
This is happening exclusively with Debian 13 (all VMs running Debian 13). I am running also Debian 12 / Ubuntu / CentOS / RHEL / Oracle Linux / SUSE / MacOS / Win11 / WinServer 2025 VMs on these servers and all of them run just fine.

I can confirm that the issue is just the console. Even when it freezes, the VM still works just fine, I can log into it and access applications running on it. However the console is not working and the VMs cannot be shut down / restarted gracefully because at one moment the shutdown just hangs (and all of the above suggests that it hangs at a moment when it tries to shutdown the console).

I did not find solution yet, but what I was trying was to fiddle with powersaving options, especially disabling console blank timeout etc. No luck so far.

Edit: I use SPICE displays in VM HW settings, no idea whether this is relevant or not. I think I tried other options but not completely sure about that now.
 
Last edited:
The exact same thing is happening to me.

Thanks so much for the feedback. I re-read my post and it is a bit misleading. I said "from the CLI" and I meant from the Debian guest VM CLI (with "sudo reboot" or "sudo shutdown") but actually it doesn't matter if it's that way, or by using the Proxmox web UI "shutdown" or "reboot" buttons (which fires off a QEMU Guest Agent action).

I have not had any of these issues with pfSense (FreeBSD 15), Windows Server 2019 Standard, Windows Server 2022 Standard, Ubuntu Linux, SuSE Linux or Debian 12 - only Debian 13.

I can confirm that the issue is just the console. Even when it freezes, the VM still works just fine, I can log into it and access applications running on it. However the console is not working and the VMs cannot be shut down / restarted gracefully because at one moment the shutdown just hangs (and all of the above suggests that it hangs at a moment when it tries to shutdown the console).

Ah! I thought it was just when I was shutting down, as I never use the console - I always SSH into the Debian guests (they don't run a GUI). I checked just now and the Debian 13 that was a fresh install when Debian 13 came out - the console is completely locked, but the rest of the VM is seemingly working fine. So it seems like it can happen at any time.

Edit: I use SPICE displays in VM HW settings, no idea whether this is relevant or not. I think I tried other options but not completely sure about that now.
I think it is relevant, because I had SPICE set for all my Linux hosts (actually I set SPICE with 16 MiB memory for every single Proxmox guest VM). I changed my most problematic Debian 13 guest over to "Standard VGA" (and didn't change the 16 MiB memory, or "Default" clipboard), and guess what - I am no longer getting the console lock up issues!

I only had SPICE as I read somewhere that it is more efficient to do so, over the standard VGA. But seeing as though I don't want the Debian 13 SPICE lockups - Standard VGA it is. My new rule is if it has a GUI - use SPICE. If it doesn't (i.e. it's just a CLI box), then use Standard VGA.

I'll keep an eye on things, but I feel somewhat confident this will resolve the issue. Thanks again.
 
  • Like
Reactions: Onslow
cool! Thanks for the suggestion with Standard VGA. I think I only tried the "advanced ones" before, but it actually makes sense to choose the screen type with less capabilities possible (as I still think it has something to do with the display "power management" in the VM).

I'll give that a try and will report back in a day or two hopefully with my results. It would still be nice to have a proper fix for the issue (which I believe could be just a few little sysctl settings or adjusted kernel commandline), but even this will be great for non-GUI guests.
 
You are probably right in that it's not SPICE on its own (as SPICE runs fine on Debian 12), but something that power management is doing that SPICE doesn't like, at least on Debian 13. Hopefully you can uncover the reason for it. If we can get a fix, I'll go back to using SPICE for all my virtual consoles, rather than SPICE for the GUI ones, and Standard VGA for the CLI ones.