Guest Additions Build test for Systemd is not robust => Fixed in SVN

[Harry M]

The test for the presence or not of systemd in the GA build process is not robust enough for all cases. Currently, the use_systemd() in routines.sh relies on criteria which may not be true for all cases where systemd is not in use. One such example is Artix, an archlinux variant without systemd, but there are likely to be others.

On Artix, as the example here, the routine tests if /sbin/init is a symlink, which it is. But the routine (incorrectly) assumes that such a link is indicative of a systemd environment.

The problem is that when the installer tests for systemd when it is not present but it thinks it really is present, apparently, the steps the GA build are not followed to completion.

I am not certain what a truly robust test would be, but maybe looking at files that are only created in the presence of systemd would be better (maybe something under /etc?). Keep in mind that "shim" packages on non-systemd platforms often install similarly-named files and programs to those in systemd, so relying on those may also not be completely robust.

[Frank Batschulat (Oracle)]

Jepp, that's an insufficient test for a SYSTEMD(1) running distro.

trunk/src/VBox/Installer/linux/routines.sh

178 use_systemd()
179 {
180     test ! -f /sbin/init || test -L /sbin/init
181 }

on a distro with systemd this looks like this (Ubuntu/Linux Mint)

$ ls -la /bin/systemd 
lrwxrwxrwx 1 root root 20 Sep 30 17:23 /bin/systemd -> /lib/systemd/systemd
$ ls -la /sbin/init
lrwxrwxrwx 1 root root 20 Sep 30 17:23 /sbin/init -> /lib/systemd/systemd

a much more reliable and correct test would be for the presence of a running systemd, eg. test for the existance of the corresponding /run directory indicating a running sustemd process, see the corresponding man page SYSTEMD(1) and SYSTEMD-SYSTEM.CONF(5) for config files and directories being used.

$ pwd
/run/systemd

$ ls
ask-password  fsck.progress   inaccessible  journal   notify   seats	    shutdown   unit-root
coredump      generator       inhibit	    machines  private  sessions     system     units
dynamic-uid   generator.late  initctl	    netif     resolve  show-status  transient  users

eg:

SOCKETS AND FIFOS
       /run/systemd/notify
           Daemon status notification socket. This is an AF_UNIX datagram socket and is used to implement the daemon
           notification logic as implemented by sd_notify(3).

       /run/systemd/private
           Used internally as communication channel between systemctl(1) and the systemd process. This is an AF_UNIX stream
           socket. This interface is private to systemd and should not be used in external projects.

from SYSTEMD.UNIT(5)

NAME
       systemd.unit - Unit configuration

SYNOPSIS
       service.service, socket.socket, device.device, mount.mount, automount.automount, swap.swap, target.target, path.path,
       timer.timer, slice.slice, scope.scope

       /etc/systemd/system/*
       /run/systemd/system/*
       /lib/systemd/system/*
       ...
       ~/.config/systemd/user/*
       /etc/systemd/user/*
       $XDG_RUNTIME_DIR/systemd/user/*
       /run/systemd/user/*
       ~/.local/share/systemd/user/*
       /usr/lib/systemd/user/*

and more SYSTEMD.UNIT(5)

UNIT FILE LOAD PATH

       │/run/systemd/system │ Runtime units   
       │/run/systemd/user   │ Runtime units                             

also systemd.directives(7)

So I'd suggest the best approach for testing a running systemd would be for the presence of /run/systemd directory

If any other package/software aside systemd itself is causing a /run/systemd directory to appear then I'd certainly call this package/software broken and an exception we're unlikely going to deal with.

[Frank Batschulat (Oracle)]

for the record, this Atrix distro is here:

​https://artixlinux.org/

[Harry M]

May I have a workaround so that I can build the GAs for two non-systemd platforms (Artix and Adelie) where the test indicated fails to properly make the proper distinction? I've tried several things, but the problem is mainly that the test is in a file that is not created until the VBoxLinuxAdditions script is run. I figured out how to use the keep option, but for some reason, my changes to the routines.sh file do not seem to change the behavior of the process -- I still don't get an updated set of binaries.

[Harry M]

CC'ing myself.

[Frank Batschulat (Oracle)]

please tell me what ISO I shall be using to install a VM please from:

​https://download.artixlinux.org/isos.php

[Frank Batschulat (Oracle)]

Any updates regarding a testing platform for such changes ? thx

[Frank Batschulat (Oracle)]

Reminder: There will be no work on this unless you tell me which iso images to use for installation, testing and fix verification of such a VM of your special Linux distro. This is a strong hint yhat you should probably re-work the web site a bit to provide details about those iso images.

[Frank Batschulat (Oracle)]

the submitter provided the installation information in ticket:

https://www.virtualbox.org/ticket/19130#comment:4

[Markon101]

This is still an issue. Today I tried installing Guest Additions in Artix Linux and it simply didn't work. OpenRC does not show vboxservice at all.

[galitsyn]

Hi guys,

There is an improvement in this area. Could you please give it a try to one of the "Latest 6.1.x test builds" from https://www.virtualbox.org/wiki/Testbuilds?

[galitsyn]

The issue should be fixed in VirtualBox 6.1.38. Please refer to https://www.virtualbox.org/wiki/Downloads.