#3480 Issue open: Do we actually need dbus in the rescue environment?

Labels: enhancement

lzaoral opened issue at 2025-06-16 13:18:

Currently, ReaR only supports the reference implementation of dbus since commit https://github.com/rear/rear/commit/d82a9553cda33ad89053a00e801d157e0de080d9. Note that the commit message does not mention "why" is was actually added because the "Fedora dbus service required for better debugging systemd" rationale makes no sense to me.

Fedora 29+, RHEL 9+ and possibly other distributions have switched to dbus-broker instead (a more-performant replacement for the reference implementation) which ReaR does not support.

So far, I have not seen any issues with the restore on such systems, with the exception of the following harmless (but rather annoying!) log messages during the installation of GRUB2 on x64 BIOS and ppc64le PowerVM machines:

Installing GRUB2 boot loader...
         Starting dbus.service - D-Bus System Message Bus...
[FAILED] Failed to start dbus.service - D-Bus System Message Bus.
See 'systemctl status dbus.service' for details.
         Starting dbus.service - D-Bus System Message Bus...
[FAILED] Failed to start dbus.service - D-Bus System Message Bus.
See 'systemctl status dbus.service' for details.
         Starting dbus.service - D-Bus System Message Bus...
[FAILED] Failed to start dbus.service - D-Bus System Message Bus.
See 'systemctl status dbus.service' for details.
         Starting dbus.service - D-Bus System Message Bus...
[FAILED] Failed to start dbus.service - D-Bus System Message Bus.
See 'systemctl status dbus.service' for details.
         Starting dbus.service - D-Bus System Message Bus...
[FAILED] Failed to start dbus.service - D-Bus System Message Bus.
See 'systemctl status dbus.service' for details.
[FAILED] Failed to start dbus.service - D-Bus System Message Bus.
See 'systemctl status dbus.service' for details.

# systemctl status dbus.service
× dbus.service - D-Bus System Message Bus
     Loaded: loaded (/usr/lib/systemd/system/dbus.service; static)
     Active: failed (Result: exit-code) since Wed 2024-04-03 14:02:23 EDT; 1min>TriggeredBy: × dbus.socket
    Process: 10983 ExecStartPre=/bin/dbus-uuidgen --ensure (code=exited, status>        CPU: 6ms

Describe the solution you'd like

I'd like to discuss whether we actually need dbus support in the ReaR rescue environment. If not, I suggest to just remove everything dbus-related from the repository. Otherwise, the support for dbus-broker should be implemented.

jsmeix commented at 2025-06-16 14:19:

@lzaoral
a totally offhanded and untested question:
Installing GRUB2 boot loader... happens in
usr/share/rear/finalize/Linux-i386/660_install_grub2.sh
where 'grub[2]-install' is run within chroot $TARGET_FS_ROOT
so I am wondering if Starting dbus.service and the
subsequent Failed to start dbus.service happens
within the ReaR recovery system or
within the restored target system?

lzaoral commented at 2025-06-16 14:44:

I am wondering if Starting dbus.service and the subsequent Failed to start dbus.service happens within the ReaR recovery system or within the restored target system?

@jsmeix Both, to be honest. grub2-install is executed in the restored system using chroot. GRUB2 installer executes os-prober at some point, which executes some other commands which subsequently trigger the dbus.socket because /run is bind-mounted in that chroot. Therefore, systemd in the recovery system will try to start the dbus.service (which then fails on Fedora because dbus-broker is an incompatible implementation).

I have experimented a bit with dbus-monitor and os-prober on a regular Fedora 42 machine and it seems that the triggering messages are just harmless signals from systemd about added/removed and (un)mounted block devices. Mounting of various block devices is in implementation detail of os-prober.

(@pcahyna, please, correct me if I'm wrong.)

jsmeix commented at 2025-06-16 14:58:

@lzaoral
thank you for your explanation.
Now I understand that "it is complicated".

[Export of Github issue for rear/rear.]