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.
Thanks
Same problem here.
Virtual Environment 7.0-14 (patched today)
Command does arrive in the VM, but does not get executed.
Plain Debian Bullseye has no problems and shuts down immediately.
Output in Dietpi-VM:
root@DietPi-Docker-Test-109:~# systemctl status qemu-guest-agent
● qemu-guest-agent.service - QEMU Guest Agent
Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
Active: active (running) since Wed 2021-11-10 11:49:01 CET; 1h 28min ago
Main PID: 363 (qemu-ga)
Tasks: 2 (limit: 4787)
Memory: 2.5M
CPU: 3.541s
CGroup: /system.slice/qemu-guest-agent.service
└─363 /usr/sbin/qemu-ga
nov 10 11:49:01 DietPi-Docker-Test-109 systemd[1]: Started QEMU Guest Agent.
nov 10 11:50:39 DietPi-Docker-Test-109 qemu-ga[363]: info: guest-ping called
nov 10 11:50:42 DietPi-Docker-Test-109 qemu-ga[363]: info: guest-shutdown called, mode: (null)
nov 10 11:50:50 DietPi-Docker-Test-109 qemu-ga[363]: info: guest-ping called
nov 10 11:51:00 DietPi-Docker-Test-109 qemu-ga[363]: info: guest-ping called
nov 10 11:51:11 DietPi-Docker-Test-109 qemu-ga[363]: info: guest-ping called
nov 10 11:51:21 DietPi-Docker-Test-109 qemu-ga[363]: info: guest-ping called
nov 10 13:17:37 DietPi-Docker-Test-109 qemu-ga[363]: info: guest-ping called
nov 10 13:17:40 DietPi-Docker-Test-109 qemu-ga[363]: info: guest-shutdown called, mode: (null)
nov 10 13:17:48 DietPi-Docker-Test-109 qemu-ga[363]: info: guest-ping called
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).
My Proxmox server Virtual Environment 7.0-14 is bullseye based and has the issues. It runs on a X86_64 host (Ryzen 2400GE).
I run a OpenMediaVault server as guest (Buster) and it shuts down fine.
It’s just as if the Bullseye version of DietPi prohibits the shutdown because of some security policy or the shutdown signal doesn’t get picked up by the system.
qemu-ga: info: guest-ping called give the Proxmox interface a status update of the guest. This seems to be working fine.
just to avoid a misunderstanding. DietPi themselves don’t have any security policies. Could it be an issue of Debian Bullseye? Did someone tried a plain Debian install?
rpopken
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:
systemctl unmask systemd-logind
apt install dbus
systemctl start systemd-logind
Through, if this was really the issue, there should be some “bus not found” like errors 
.
This works for me. Have verified on 4 dietpi bullseye guests. I would just add to reboot the guest after those 3 commands otherwise that first shutdown command you give will take awhile.
Okay, good to know. Strange that this obviously wasn’t required on Buster, but the package didn’t add the dbus package or systemd to the dependency list: https://packages.debian.org/bullseye/qemu-guest-agent
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.
I don’t think the issue is the same. Issuing a shutdown command from the host would simply timeout and doesn’t seem to do anything on the guest.
Just installed Debian Bullseye from latest net install.
Only installed system utilities and ssh server.
Shutdown and reboot work straight out of the box.
\
apt install -t buster-backports qemu-guest-agent
Got the message the agent is already the latest version ( (1:5.2+dfsg-11+deb11u1). VM does still not shut down.
dbus missing?
I wondered if the dbus package is installed by default at the newly installed Debian Bullseye
x@debian200:~$ dpkg -s dbus
Package: dbus
Status: install ok installed
Priority: standard
Section: admin
Installed-Size: 199
Maintainer: Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org>
Architecture: amd64
Multi-Arch: foreign
Version: 1.12.20-3
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
Conffiles:
/etc/default/dbus 0d0f25a2f993509c857eb262f6e22015
/etc/init.d/dbus d78b20b35de983cf6f1475dcf8cb21a1
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.
Homepage: https://dbus.freedesktop.org/
Seems like the dbus package is missing in the standard install of DietPi?
Seems like the dbus package is missing in the standard install of DietPi?
Yes the package is not available by design/default.
On new installation, it could set as required using dietpi.txt
# Unmask (enable) systemd-logind service (including dbus), which is masked by default on DietPi
AUTO_UNMASK_LOGIND=0
On running systems, dbus would need to be installed manually.
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:
apt install -t bullseye-backports qemu-guest-agent
And to mask again systemd-logind, if it was unmasked in the meantime to get it working:
systemctl mask --now systemd-logind
Were you guys able to get this figured out?
I have two Proxmox VM installs and neither are working with the latest agent or the backport.
Interesting that the backport is newer than the normal agent.
qemu-guest-agent/bullseye-backports,now 1:7.0+dfsg-2~bpo11+2 amd64 [installed]
qemu-guest-agent/stable-security,now 1:5.2+dfsg-11+deb11u2 amd64 [installed]
backport means a backport from Bookworm. Therefore it’s logic to be on a higher version 
Check out the solution above, installing dbus and unmasking + probably starting systemd-logind.