Unusual startup logs after removing X11 on Devuan SysVInit

wolfchar · Today 06:42:50

Context

You might have seen this post series from my organization related setting up Pipewire and Hyprland on Devuan. Another potentially important piece of the puzzle is my earlier post related to asking about the possibility of switching to the Devuan OpenRC Setup Post-Desktop Live Install.

Essentially, at the time I created the guide, I was memed into using the default OpenRC configuration offered on some of the .iso installation options for Devuan. I'm new to init freedom altogether, so I'm playing around with what init system would be optimal and friction-least for a computer user. For an unrelated reason, my installation borked after an attempt at cleaning up unnecessary packages on my system (the exact cause to me is a mystery). This post, after reading a little bit about how Devuan approaches init ("enhanced" SysVInit being apparently more performant, and how the default OpenRC apparently uses SysVInit for certain things anyway), is about exploring as another "branch" of experimentation of how this can cleanly be done using Devuan's default init system.

What is happening?

Essentially, when I boot up into the tty on the SysVInit computer, I'm getting logs similar but not limited to:

startpar: service(s) refused failure: x11-common ... failed!
startpar: service(s) refused failure: pulseaudio-enable-autospawn cups cups-browsed ... failed!

I'm not sure how to exactly extract the logs that pop on a tty on startup, upon learning how, I'll edit/add a post to include them.

My assumption would be that this would essentially be a game of whack-a-mole of telling SysVInit scripts to not call certain applications to allow applications to function properly. For example, in the first snippet above, I'm curious if having pulseaudio-enable-autospawn fail would cause me problems later in regard to being able to use printers with cups. Conversely, I'm curious if this could not be the case and it is simply a matter of flipping off configuration files or hiding the messages in come way in the case that, generally speaking, the ... Failed! messages are inconsequential (an example being that pulseaudio-enable-autospawn failing doesn't appear to be affecting my ability to use audio devices with Pipewire).

Any pointers appreciated.

Best,

Last edited by wolfchar (Today 07:38:56)

wolfchar · Today 08:08:05

Update: on x11-common

Troubleshooting x11-common as a dependency for certain applications

So, after updating my system and attempting to install the Vesktop .deb using dkpg -i, it refused due to a dependency failure. After using sudo apt install -f to resolve broken package dependencies to allow me to install, x11-common was one of the listed dependencies.

What is x11-common?

I found that strange considering I do not have xwayland or similar compatibility layers at the time. After installing it, I looked up the x11-common package listing from upstream gives me the following description:

Debian Packages wrote:

x11-common contains the filesystem infrastructure required for further installation of the X Window System in any configuration; it does not provide a full installation of clients, servers, libraries, and utilities required to run the X Window System.

From what I can derive in layman's terms is that x11-common provides only some files and directories necessary to what a system needs to eventually run a graphical interface (like the windows, icons, and menus you see on screen), but doesn't actually provide the tools to create the windows or GUI from it -- which would make sense if the user would be installing an X11 application.

Result

The result, if not immediately obvious, is that startpar can now find x11-common, so it doesn't display this anymore:

startpar: service(s) refused failure: x11-common ... failed! # no longer displays as a result of installing x11-common

Still investigating what deal is with pulseaudio-enable-autospawn, and why it is holding cups hostage.

The officially official Devuan Forum!

#1 Today 06:42:50