Is there a way to fix the shutdown on dietpi so that qemu guest agent can shut down a dietpi guest?
I’m running multiple dietpi instances as guests on a proxmox host. This worked well in buster, but after upgrading to bullseye, the dietpi guests do not seem to work with the guest agent “shutdown” command so the guest agent can’t shutdown the VM.
It is an x86_64 host and guest? Do the OS/QEMU versions in host and guest match? The qemu-guest-agent package received 2 major version bumps from Buster to Bullseye, hence some incompatibility might be included.
I had this thought as well. I’m currently running proxmox 6 (buster) host and the guests are dietpi 7 (bullseye). I’m thinking the problem will resolve itself when I get proxmox upgraded to 7 (bullseye).
So you mean Bullseye host + Buster guest works, Bullseye host + Bullseye guest does not work in your case? Indeed looks like a change in Bullseye then. But as stated, we do not apply any security policy, I don’t have any experience with the QEMU agent, and we do not create Bullseye images any different than Buster images in any of those regards. It happened here and there that on Bullseye some packages got dependencies removed or degraded to recommendations, while other apps, depending on them, still required those previously pulled in dependencies. Basically it would be an idea to compare the package lists between the Buster and Bullseye host, respectively reviewing the autoremoved packages after the upgrade.
Another test could be to upgrade the package on the Buster system to the new version via backports:
apt install -t buster-backports qemu-guest-agent
This version matches the one from Bullseye, so if the issue is related to his, it should be seen.
And finally, I’m not sure how communication is done, but often such things require dbus and/or logind, especially for shutdown actions. At least worth a try:
If you both can verify, then I’ll report this to the Debian bug tracker, also to check back whether there is another solution: … ah, it’s there already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951781
The symptoms fit, right? Looks like we can add our solution and the info that it is still present on latest v5.2. Buster is v3.1, so v4.2 was either from backports or during Bullseye testing phase.
systemctl start systemd-logind – VM shuts down immediately when stopped from host.
I wondered if the dbus package is installed by default at the newly installed Debian Bullseye
x@debian200:~$ dpkg -s dbus
Status: install ok installed
Maintainer: Utopia Maintenance Team <email@example.com>
Provides: dbus-system-bus (= 1.12.20-3), default-dbus-system-bus
Depends: dbus-bin (= 1.12.20-3), dbus-daemon (= 1.12.20-3), dbus-system-bus-common (>= 1.12.20-3), libc6 (>= 2.14), libdbus-1-3 (= 1.12.20-3), libexpat1 (>= 2.1~beta3), libsystemd0
Pre-Depends: init-system-helpers (>= 1.54~)
Suggests: default-dbus-session-bus | dbus-session-bus
Description: simple interprocess messaging system (system message bus)
D-Bus is a message bus, used for sending messages between applications.
Conceptually, it fits somewhere in between raw sockets and CORBA in
terms of complexity.
D-Bus supports broadcast messages, asynchronous messages (thus
decreasing latency), authentication, and more. It is designed to be
low-overhead; messages are sent using a binary protocol, not using
XML. D-Bus also supports a method call mapping for its messages, but
it is not required; this makes using the system quite simple.
It comes with several bindings, including GLib, Python, Qt and Java.
This package provides a fully-functional D-Bus system bus with activation
support, used for communication between system services, and depends on
most of the other components of the reference implementation of D-Bus.
To provide a complete D-Bus session bus, install one of the packages
that implement the dbus-session-bus virtual package, such as
dbus-user-session. The recommended implementation is indicated by
the default-dbus-session-bus virtual package.
Seems like the dbus package is missing in the standard install of DietPi?
I still wonder why this agent started to rely on systemd-logind while not adding any dependency package and while there are of course many systems out there without systemd but a different init system, like SysV. There must be a way to tell the agent to not use systemd-logind. The question is also how it invokes the shutdown. E.g. calling shutdown without arguments on a systemd driven system will invoke it as schedule to shutdown in X seconds, which requires systemd-logind, and fails without it running of dbus installed (systemd-logind requires dbus). The correct invocations to shutdown “now” is shutdown now or simply poweroff. So probably they changed something about that without thinking about the implicit dependency on systemd-logind .
Btw, I reported it in the meantime: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004943
I believe whether systemd-logind is used depends on whether systemd is the init system, e.g. by checking whether /run/systemd/system exists. The latter however does not imply that dbus is installed or systemd-logind hence running, so that check could be enhanced in qemu-guest-agent. As stated by the Debian package maintainer, probably the new version from Bullseye backports solves it. To test, within the guest, run: