dbus hostnamectl requires it … script for issues? Missing aplay in Dietpi-bugreport

Well this issue report is a threefer (not the rude kind)

main issue dbus, secondary issue submitting bug reports

Required Information

====DietPi version: VM version

G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=14 G_DIETPI_VERSION_RC=2 G_GITBRANCH='master' G_GITOWNER='MichaIng' G_LIVE_PATCH_STATUS[0]='not applicable' G_LIVE_PATCH_STATUS[1]='applied' G_LIVE_PATCH_STATUS[2]='applied'

====Distro version: 11.6 ====Kernel version: Linux DietPi 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux ====SBC model: VM

====CPU:

───────────────────────────────────────────────────── DietPi CPU Info Use dietpi-config to change CPU / performance options ─────────────────────────────────────────────────────

[WARNING] Most CPU information is not available on VM.

Architecture | x86_64 Temperature | N/A Governor | N/A

[ INFO ] DietPi-CPU_info | CPU current frequency, may be affected by this script, due to the processing required to run it.

G_HW_MODEL=20 G_HW_MODEL_NAME='Virtual Machine (x86_64)' G_HW_ARCH=10 G_HW_ARCH_NAME='x86_64' G_HW_CPUID=0 G_HW_CPU_CORES=1 G_DISTRO=6 G_DISTRO_NAME='bullseye' G_ROOTFS_DEV='/dev/sda1' G_HW_UUID='c0bc3e13-5367-47f5-b707-d881614cbcb2'

====Power supply used: N/A VM ====SD card used: NA

Additional Information (if applicable)

Can this issue be replicated on a fresh installation of DietPi? Yes

Bug report ID: Reference code: c0bc3e13-5367-47f5-b707-d881614cbcb2

Steps to reproduce

run command

hostnamectl

Failed to connect to bus: No such file or directory

Expected behaviour

The command to work with dbus or remove command?

There are several other commands that are shipping with dietpi that depend on dbus...

Here's more info on dbus: https://www.cardinalpeak.com/blog/using-dbus-in-embedded-linux

I'm not advocating for or against using dbus.

Recommendation is to use it or remove the components that are shipping with dietpi. Based on your dieting of the os I susoect removing the commands might be better?

Workaround

apt install dbus reboot

command works as expected:

Static hostname: DietPi Icon name: computer-vm Chassis: vm Machine ID: 10xxxxxxxxxxxxxxxxxxxxxxxxxxd4ed Boot ID: d6xxxxxxxxxxxxxxxxxxxxxxxxxx2daa Virtualization: microsoft Operating System: Debian GNU/Linux 11 (bullseye) Kernel: Linux 5.10.0-21-amd64 Architecture: x86-64

Additional notes

Attached is bash script to autofill the git issue reports.

The code seems to be buried install of globals (but I haven't grokked it enough yet)

It seems dietpi-bugreport has a "bug" lol its expecting aplay which isnt in the vm version im running

issues related:

Diet Scheduled Reboot. #5895

/sbin/shutdown: Failed to connect to bus: No such file or directory #5912

VirtualBox image dbus problem #1973

maybe related:

Dropbear does not set DBUS_SESSION_BUS_ADDRESS in SSH sessions #4579

GitHub didn’t allow with a bash extension.

dietpi-issue.txt

hostnamectl is a CLI tool for the systemd-hostnamed service, which isn't used on DietPi, neither is it on official Debian images by default. Not sure what you want to use it for, but use hostname and/or /etc/hostname instead to see/change the the system's hostname. Otherwise, yes dbus is required.
dietpi-bugreport does this intentionally. If someone reports an audio related issue, we want to see aplay output, as well if it is not installed. We could also check for the command and print an info to the log, if it is not present, but falling aplay regardless has just the same effect with fewer code 😉.
Yes, for scheduled shutdown, dbus is required, but especially for SBCs, this is very rarely used. Often people use the shutdown command only, because they don't know about the poweroff and reboot commands 😄. So we don't see this as sufficient reason to install and enable dbus for everyone (which can be trivially done by users themselves).
The Dropbear limitation is more a reason why dbus isn't installed on DietPi OOTB, since Dropbear, other than OpenSSH, doesn't make use of it, respectively most PAM features.

So not sure what you aim for, but dbus isn't pre-installed intentionally, since it is very rarely used by software/users we use/have. If you need it, just install it:

apt install dbus

Often, dbus is required in combination with systemd-logind, in which case:

systemctl unmask systemd-logind
apt install libpam-systemd

This enables systemd PAM integration, usually used to elevate non-root user privileges in desktop sessions. This is done automatically when installing a desktop via dietpi-software. Also in dietpi.txt there is a switch to have systemd-logind unmasked automatically on first boot (or after next software install).

EDIT:

Recommendation is to use it or remove the components that are shipping with dietpi. Based on your dieting of the os I susoect removing the commands might be better?

Ah you mean that it is bad to have a command on the system which requires dbus, without having dbus installed? Well, since DietPi is based on Debian, and the Debian systemd package has systemd-hostnamed (and also systemd-logind) included, this is out of our control. I'd also like to have the multiple systemd features split into dedicated packages. For some, they are, but systemd is getting faster new features than Debian splits them off. Debian also does ship with dbus pre-installed and enabled, so their motivation to split related systemd features off is probably low. So while this is not so "Diet", it is an implied necessity based on the fact that DietPi uses the official Debian APT repository for the underlying base system.

Thank you for your response! Both issues (hostnamectlctl and shutdown) are upstream… the same as the wssd discussion…

My goal in this issue is to avoid users using stuff that isn’t going to work. Dbus support isn’t obvious from the error message but it is gogglable lmgtfm.

I would have thought the deb packaging system would have caught that when trying to install a package with a dependency? But I just checked and it is not there: https://packages.debian.org/bullseye/systemd-sysv where shutdown lives dbus is NOT listed as a dependency…

so, I could go upstream and ask them to add it as a dependency… but then I need to do that for as well with hostnamectl…

So, this more of documentation issue please close. If non functionality of base packages used by Dietpi is a big problem then a blacklist of problem commands could be added… but probably not worth the effort..

Please keep up the great work on your distro!!… how about an issue creator script (enhancement)

My bad, the hostnamectl was not installed in the base Dietpi build, the evil script below installed it also without the dbus dependency…

To answer your question why I needed hostnamectl.. this sd card disk speed script and database use it:

https://pibenchmarks.com/search/Fk/

systemd is very feature-rich. If you want to be able to fully use all its features, it would be a ton of dependencies. Luckily this is not how Debian dependency policy works. If the essential feature of a package requires another package, that is of course added as dependency. For features which are probably often used, but not always, packages are added as recommendation, which are by default installed on Debian, but not on DietPi. dbus is a recommendation of systemd. For features which are rarely used, packages are added as suggestion. And then there is another role where one package can declare that it "enhances" another package.

hostnamectl AFAIK is a very rarely used feature, at least on Debian. It is probably more common on Ubuntu, which usually uses the whole systemd network stack: systemd-networkd, systemd-resolved and if I am not mistaken also systemd-hostnamed. Debian however uses ifupdown by default, just like DietPi, and no hostname daemon.

Best approach is to not use high level tools, if not required for a specific reason. The hostname can be shown on every Linux distro via cat /etc/hostname and hostname commands, regardless what other tools and daemons are used. Especially scripts intended to run on any Linux distro should follow this approach. But, actually I do not see any use of hostnamectl in it, nor anywhere in the commit history: https://github.com/TheRemote/PiBenchmarks/blob/master/Storage.sh Also not sure why the hostname would be relevant for a disk benchmark. Are you sure it was really this script calling it?

MichaIng / DietPi