Opened 5 years ago
Closed 2 years ago
#19033 closed defect (fixed)
Guest Additions Build test for Systemd is not robust => Fixed in SVN
| Reported by: | Harry M | Owned by: | |
|---|---|---|---|
| Component: | installer | Version: | VirtualBox 6.0.14 |
| Keywords: | systemd | Cc: | |
| Guest type: | Linux | Host type: | Linux |
Description
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.
Change History (19)
comment:3 by , 5 years ago
| Owner: | set to |
|---|---|
| Status: | new → accepted |
comment:4 by , 5 years ago
| Component: | guest additions → installer |
|---|
comment:5 by , 5 years ago
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.
comment:8 by , 5 years ago
| Keywords: | systemd added |
|---|---|
| Status: | accepted → awaitsfeedback |
comment:10 by , 5 years ago
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.
comment:11 by , 5 years ago
| Owner: | removed |
|---|---|
| Status: | awaitsfeedback → assigned |
comment:12 by , 5 years ago
| Status: | assigned → awaitsfeedback |
|---|
comment:14 by , 5 years ago
| Status: | awaitsfeedback → new |
|---|
comment:15 by , 5 years ago
| Owner: | set to |
|---|---|
| Status: | new → accepted |
comment:17 by , 4 years ago
| Owner: | removed |
|---|---|
| Status: | accepted → assigned |
comment:18 by , 3 years ago
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.
comment:19 by , 2 years ago
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?
comment:20 by , 2 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
| Summary: | Guest Additions Build test for Systemd is not robust → Guest Additions Build test for Systemd is not robust => Fixed in SVN |
The issue should be fixed in VirtualBox 6.1.38. Please refer to https://www.virtualbox.org/wiki/Downloads.


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)
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.
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 unitsalso 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.