You are not logged in.
Apologies in that I'm a bit off topic since I was trying to set up fixed IP WiFI not an Ethernet connection at the time I hit the same issue.
My fresh install of Beowulf-Beta (with Cinnamon) looked like this (now suiitably anonymised):
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug wlan0
iface wlan0 inet static
address 192.168.1.21/24
gateway 192.168.1.254
# wireless-* options are implemented by the wireless-tools package
wireless-mode managed
wireless-essid *******
wireless-key1 *************
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.1.254
dns-search mydomain.mytld
I started with a WiFi connection and no Ethernet, I had to configure the WiFi iinterface during the install.
As I recall something then broke (probably the issue we are discussing) and I lost my connections. I had to run off-network until I'd found that i needed to comment out all but the loopback network interface, when it started working again. And I could then only run it with DHCP, not fixed IP as I was attempting to do.
It's now running nicely over Ethernet.
Network Manager might be overkill for some users and use cases, however I do rather like to have the applet on my panel to show me the status of my WiFi and to allow me easily to re-configure it if I need too. For someone using a laptop away from base perhaps even more so.
Even when I'm ssh-ing into another machine nm-connection-editor gives me a straightforward graphical interface to change my remote machine's network settings without having to know the syntax and edit the config files directly
To me the problem is the way the Cinnamon Desktop installation packages suite, which includes Network Manager, doesn't play nicely with other setups of interfaces, which might be the way they are configured by default or they may be your personalisations.
What (I think) Network Manager should do when installed is replace the existing /etc/network/interfaces with the simplified version that hands off management to network-manager and back up the original. If Network Manager is then de-installed then it ideally it should return the /etc/network/interfaces file to its previous, hopefullly working, state.
I installed Beowulf on a new Intel NUC with the desktop iso and expert install and choosing Cinnamon as my Desktop.
In the installer I specified the time zone and told the hardware clock to use UTP and the system to use NTP.
As reported elsewhere I initially had problems getting onto the network/internet.
However once this was sorted I ended up with the correct timezone but an inaccessible clock (controls greyed out in the Cinnamon settings) and the wrong time shown.
Installing chrony fixed the issue but I remain puzzled what the problem was: presumably it was in the default NTP setup.
hello to you users of the freedom linux!
[snip]
And finally restart the service:
systemctl restart network-manager
Not on Devuan! systemctl is a systemd abomination invention.
Try:
sudo service network-manager restart
I've also found this problem with Cinnamon on a fresh install of Beowulf using the Desktop iso on an Intel NUC.
Cinnamon installs Network-Manager, which attempts to takeover network management, rewrites /etc/resolve.conf but doesn't get rid of the conflicting code in /etc/network/interfaces.
The result was that I couldn't access my network either over ethernet or wifi
Currently I still can't get it to work with a fixed IP over wifi, which is what I was trying to use, however DHCP works.
Marjorie wrote:NVIDIA (nvidia-persistenced) issue in Beowulf Beta
Seems either Devuan or Debian should remove the recommend and/or correct /etc/init.d/nvidia-persistenced to make it work properly.Like I said, the warning message itself is harmless.
I want to repeat also that whenever I try to install nvidia proprietary drivers (and I've tried to do so on several distros), I almost always get some kind of warning or a rough edge that needs fixing. I believe even Linux Torvalds once commented something about nvidia regarding their attitude.Try searching the internet for something like "linus nvidia f**k you"
I don't have a problem, I have a fix for this particular issue, well actually two fixes.
Just trying to give feedback so that others can avoid it happening to them and maybe needlessly worrying.
NVidia do invite those who package distributions to fix things, so maybe we should. I agree it would be better if they did it themselves.
Thanks GoLinux and OneFang, Excellent.
I just need to RTFM in future.
Onefang, thanks for the excellent clarification.
Sometime I just get a bit paranoid and maybe I should switch to a https mirror.
I used to use the more specific, if still http, gb.deb.devuan.org until that was deprecated and we were recommended to use deb.devuan.org.
Maybe a disclaimer in the documentation about its load-sharing round-robin nature would help.
Head_on_a_stick wrote:
Anyway, as the title says the installer fails to configure the locales package correctly:
As you mention OpenRC I assume you're using the 'expert' option on one of the full isos. Which iso though?
I installed using the devuan_beowulf_3.0.0_beta_amd64_desktop.iso and installed to disk and locales seems OK:
marjorie@grendel:~$ locale
LANG=en_GB.UTF-8
LANGUAGE=en_GB:en
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=
NVIDIA (nvidia-persistenced) issue in Beowulf Beta
Having got Beowulf up and running using an expert install (uses nouveau drivers) I added the non-free depositories, added the appropriate kernel headers and installed the nvidia-driver package, which compiles the nvidia kernel module and gets nvidia graphics up and running. The nvidia-persistenced package will have got pulled in as it's a recommend.
Having checked on this (see https://docs.nvidia.com/deploy/driver-p … index.html) I found:
Persistence mode (and the persistenced daemon) is not required if NVIDIA is operating under X. However it could be useful if you want CUDA. So you may not need it at all.
In older nvidia drivers persistence mode was provided inside the kernel ('legacy persistence mode'), and was turned on and off with nvidia-smi.. Persistenced is a user-space replacement for kernel mode persistence. Later kernel modules (319 or above) would do either but use nvidia-persistenced by preference, if it was loaded.
Initially the nvidia.persistenced binary was provided but was not installed using a boot (etc/init.d) service as implementations differed (e.g. sysv, upstart, systemd). Distributions were encouraged to come up with init solutions that work for them.
In Beowulf the nvidia-persistenced module is set up by default (loading as a recommend) if you install nvidia-driver and tries to initialise the persistenced daemon, which is when it didn't on my computer.
I note that there is also a /lib/systemd/system/nvidia-persistenced.service, which is for systemd Debian. Would this be invoked on systend installation or is it just an example?
Seems either Devuan or Debian should remove the recommend and/or correct /etc/init.d/nvidia-persistenced to make it work properly.
NVIDIA (nvidia-persistenced) issue in Beowulf Beta
Not sure if I should post this here or on a separate thread.
I updated to Beowulf from ASCII a few days ago.
My system has a reasonably current, if not very high powered, NVidia graphic card.
I had installed the nvidia driver and this ran OK in ASCII. In ASCII the nvidia-persistenced binary was installed but not the init.d script.
Having got Beowulf up and running using an expert install (uses nouveau drivers) I added the non-free depositories, added the apprropriate kernel headers and installed the nvidia-driver package, which compiles the nvidia kernel module and gets nvidia graphics up and running. The nvidia-persistenced package will have got pulled in as it's a recommend.
NVidia graphics itself is up and running OK
However nvidia-persistenced failed to install properly. And subsequent attempt to run it as a service failed. It also started producing error messages when I subsequently installed other packages. This is from my synaptic detail when I installled lnav:
Selecting previously unselected package lnav.
Preparing to unpack .../lnav_0.8.4-5_amd64.deb ...
Unpacking lnav (0.8.4-5) ...
Setting up libpcrecpp0v5:amd64 (2:8.39-12) ...
Setting up nvidia-persistenced (418.56-1) ...
Starting NVIDIA Persistence Daemon
nvidia-persistenced failed to initialize. Check syslog for more details.
invoke-rc.d: initscript nvidia-persistenced, action "start" failed.
dpkg: error processing package nvidia-persistenced (--configure):
installed nvidia-persistenced package post-installation script subprocess returned error exit status 1
Setting up lnav (0.8.4-5) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for libc-bin (2.28-10) ...
Errors were encountered while processing:
nvidia-persistenced
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install. Trying to recover:
Setting up nvidia-persistenced (418.56-1) ...
Starting NVIDIA Persistence Daemon
nvidia-persistenced failed to initialize. Check syslog for more details.
invoke-rc.d: initscript nvidia-persistenced, action "start" failed.
dpkg: error processing package nvidia-persistenced (--configure):
installed nvidia-persistenced package post-installation script subprocess returned error exit status 1
Errors were encountered while processing:
nvidia-persistenced
NVidia provide a sample script for /etc/init.d/nvidia-persistenced for sysv. This was written in 2013 and has been around since and is what is installed from the Beowulf non-free depositories.
#!/bin/sh -e
#
# NVIDIA Persistence Daemon Init Script
#
# Copyright (c) 2013 NVIDIA Corporation
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# This is a sample System V init script, designed to show how the NVIDIA
# Persistence Daemon can be started.
#
# This sample does not rely on any init system functions, to ensure the
# widest portability possible.
#
# chkconfig: 2345 99 01
# description: Starts and stops the NVIDIA Persistence Daemon
# processname: nvidia-persistenced
#
### BEGIN INIT INFO
# Provides: nvidia-persistenced
# Required-Start: $ALL
# Required-Stop: $ALL
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: Starts and stops the NVIDIA Persistence Daemon
### END INIT INFO
NVPD=nvidia-persistenced
NVPD_BIN=/usr/bin/${NVPD}
NVPD_RUNTIME=/var/run/${NVPD}
NVPD_PIDFILE=${NVPD_RUNTIME}/${NVPD}.pid
NVPD_USER=nvpd
if [ -f ${NVPD_PIDFILE} ]; then
read -r NVPD_PID < "${NVPD_PIDFILE}"
# Remove stale runtime files
if [ "${NVPD_PID}" ] && [ ! -d /proc/${NVPD_PID} ]; then
unset NVPD_PID
rm -rf "${NVPD_RUNTIME}"
fi
fi
case "${1}" in
start)
echo "Starting NVIDIA Persistence Daemon"
# Execute the daemon as the intended user
${NVPD_BIN} --user ${NVPD_USER}
;;
stop)
echo "Stopping NVIDIA Persistence Daemon"
# Stop the daemon - its PID should have been read in
[ ! -z "${NVPD_PID}" ] && kill ${NVPD_PID} &> /dev/null
;;
restart)
$0 stop
sleep 2
$0 start
;;
*) echo "usage: $0 {start|stop|restart}"
;;
esac
exit 0
I think I've identified the problem, though I'm unclear why it got triggered during an install. The problem occurs when there is an existing nvidia-persistence running on the system. When this is the case starting nvidia-persistenced fails with the above error message (as it can't get a lock on the PID file).
I've therefore added/modified a few line of code to correct this: if a running nvidia-persistenced exist it stops it and then starts a new instance. This ensures that nvidia-persistenced starts in its enabled state as that is the default.
#!/bin/sh -e
#
# NVIDIA Persistence Daemon Init Script
#
# Copyright (c) 2013 NVIDIA Corporation
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# This is a sample System V init script, designed to show how the NVIDIA
# Persistence Daemon can be started.
#
# This sample does not rely on any init system functions, to ensure the
# widest portability possible.
#
# chkconfig: 2345 99 01
# description: Starts and stops the NVIDIA Persistence Daemon
# processname: nvidia-persistenced
#
### BEGIN INIT INFO
# Provides: nvidia-persistenced
# Required-Start: $local_fs
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Starts and stops the NVIDIA Persistence Daemon
# Description: Starts and stops the NVIDIA Persistence Daemon
### END INIT INFO
NVPD=nvidia-persistenced
NVPD_BIN=/usr/bin/${NVPD}
NVPD_RUNTIME=/var/run/${NVPD}
NVPD_PIDFILE=${NVPD_RUNTIME}/${NVPD}.pid
NVPD_USER=nvpd
NVPD_ACTION=${1}
# Gracefully exit if the package has been removed.
test -x $NVPD_BIN || exit 0
# Get the value of the PID
if [ -f ${NVPD_PIDFILE} ]; then
read -r NVPD_PID < "${NVPD_PIDFILE}"
# Is the daemon already running?
if [ "${NVPD_PID}" ] ;then
if [ -d /proc/${NVPD_PID} ]
# Daemon is running, so stop it then start anew instance
then
case "${1}" in
start)
echo "NVIDIA Persistence Daemon already running"
NVPD_ACTION=restart
;;
*)
;;
esac
# Daemon not running, but there is a stale PID
else
echo "NVIDIA Persistence Daemon, stale PID removed"
unset NVPD_PID
rm -rf "${NVPD_RUNTIME}"
fi
fi
fi
case "${NVPD_ACTION}" in
start)
echo "Starting NVIDIA Persistence Daemon"
# Execute the daemon as the intended user
${NVPD_BIN} --user ${NVPD_USER}
;;
stop)
echo "Stopping NVIDIA Persistence Daemon"
# Stop the daemon - its PID should have been read in
[ ! -z "${NVPD_PID}" ] && kill ${NVPD_PID} &> /dev/null
;;
restart)
$0 stop
sleep 2
$0 start
;;
*) echo "usage: $0 {start|stop|restart}"
;;
esac
exit 0
Has anyone else encountered this problem?
As I assume that it's a problem with other sysv distributions, not just Beowulf, how can I go about correcting this?
When I switch Https Everywhere off I can see the Index page on http:/deb.devuan.org.
Still odd about the SSL Server Certificate being wrong though (of course http doesn't have a certificate).
i assume my original problem was because there was a short outage, which is now fixed.
OK, it's working again now, using synaptic.
However still getting the SSL server certificate error however (it's a free Lets Encrypt Cert).
Is it just one of the sysops setting it up wrong, and reusing another certificate?
Hi,
No I'm not using https://.
The repository list is unchanged from when it was working yesterday.
I realise that I can switch to another mirror, and may do that now, but I thought I ought to flag up the issue, since this is the recommended mirror.
And that doesn't explain the web certificate issue.
At present I can't seem to access deb.devuan.org to refresh my synaptic cache.
And trying to access the site using Firefox-esr I get a certificate error, saying that the certificate is only good for sledjhamr.org.
Acessing devuan.org and beta.devuan.org on Firefox-esr is fine.
Is the problem at my end or wiith deb.devuan.org?
Just to report how I've (finally) managed to upgrade to Beowulf (Cinnamon edition).
System
My system: AMD Phenom II X4 910e, NVidia GeForce GT 710B. 8 GB RAM. 24" Dell U2415 (1920 x 1200 x 60 Hz).
ASCII installed (4.09-12 kernel) on 2 x 500GB SSD as RAID1 with root (/dev/md0), home (/dev/md1) and swap (/dev/md2) partitions. Collection of other SSD and spinning rust drives. I've using the NVidia default drivers.
I first mounted the Beowulf 3.0.0 ISO on one of my other hard drives and added it to grub (via 40_custom in /etc/grub.d).
Live ISO
Booted this up without difficulty. Network connect fine.
Then, having backed up the root (dev/md0) partition (using fsarchiver), I attempted to do do an upgrade in place.
Upgrade in place
I followed the beta.devian "Upgrade to Beowulf' guide.
This mostly seemed to work, however at the end of the process I ended up with a completely locked screen: a full hi-res graphic login screen, but mouse and keyboard frozen, so I couldn't even get a console. I chrooted into the system and managed to unlock root, however despite playing around in the console ('m much happier working with multiple xterms and graphical tools such as synnaptic and GParted to hand). I couldn't work out a solution. I'm a sudo user so I wouldn't normally have a root password.Also I think having the Nvidia drivers may have contributed since the following the instructions only main and not contrib and non-free are enabled in the repository and the nvidia pacvckages are in non-free.
Expert Install of root and link to /home
Had a number of goes at this, but eventually decided to use the devuan_beowulf_3.0.0_beta_amd64_desktop.iso and do an 'expert install' of the root partition: the expert option is required so as to get the cinnamon desktop and in my case control over where to install the new root file system.
Having done this before (when I installed ASCII on RAID) it wasn't particularly difficult. The main problem I had was knowing what sequence of choices I need to do in the partitioning step as I didn't want to destroy the other partitions on the various disks on my system. I also decided to not make the partition bootable, which came back to bite me later. I choose a user name and password and set myself up to sudo rather than enable a root password.
Anyway I completed the install. The desktop came up fine (nouveau vido driver) and network connection worked. I then backed this up and restored it to my original root partition (/dev/md0). I modified fstab to mount my asciil home partition (/dev/md1) at /home and removed the (short list of) existing files in /home.
Rebooted to get most of my ascii desktop. and used synaptic to install Evolution (my preferred mail client/Calendar/Contacts), this then reloaded my mail archive and account settings.I did have to install an /etc/aliases for access my mail spool (for root messages).
Rythmbox automatically found my Music.I did have to enable autospawn (etc/pulse/client.conf.d/00-disable-autospawn.conf) to get pulseaudio working.
Firefox kept nearly all of my settings, although it did disable DoH - naughty - should be my choice.
Network Manager (the default in Cinnamon) also worked, 'out of the box'.
I then had to install the grub packages and fix grub.
Having done another backup, and having enabled contrib and nonfree I ran sudo apt-get install nvidia-driver to make full us of my graphics card. Although it complained (as it had when I tried to do it via an upgrade), failing with Nvidia persistentd, it did work and I now have accelerated video again.
Final thoughts
For the moment I would suggest not upgrading in place if you are running the proprietary NVidia drivers or if you use sudo.
Installing a new Beowulf system in the root partition and then linking it with your /home partition seems more robust (but do back them up first). I suspect I could have linked them directly in the installer but out of an abundance of caution I didn't.
Not sure whether this is related.
I'm running ASCII and contemplating upgrading to Beowulf.
To that end I've been trying to upgrade the kernel first, as reverting that, in the event of any issues, should be much more straightforward.
Using Synaptic I upgraded from 4.9.06 to 4.9.12 without issue several days ago. My processor is quite old - AMD Phenom II X4 910e, so unlikely to be be having side-channel mitigation issues. No freezing (as per this other recent thread https://dev1galaxy.org/viewtopic.php?id=3376 ).
I next tried to upgrade to the backported Beowulf kernel 4.19. I note that this pulled in a couple of Apparmor packages. This seems to be booting OK until it attempted to load Cinnamon at which point I find this in /log/syslog :
Mar 17 16:35:54 erewhon cinnamon-session[2745]: WARNING: t+0.00800s: Could not get session id for session. Check that logind is properly installed and pam_systemd is getting used at login.
and Cinnamon fails to load and I get fallback and a low-res screen with no menus. Firefox and Rythmbox load at startup into this OK. Evolution segments.
Opening a terminal session and rebooting I can restart with the 4.9.12 kernel from the Advanced menu in Grub and Cinnamon opens fine.
Just reading the guide on for how to update from ASCII to Beowulf (https://beta.devuan.org/os/documentatio … owulf.html) I note that the text seems to imply that this would work to upgrade from Jessie too.
'Devuan Jessie users should now upgrade the Devuan repository keyring, and update the package lists again so packages can be authenticated.'
and
'Users who upgraded from ASCII and are using upower will need to downgrade their upower packages to avoid problems like [bug #394].'
If it does include updating form Jessie to Beowulf shouldn't the title and reference make this clearer?
--
Marjorie
Firefox-esr 60.8.0esr-1~deb9u1 hit the gb.deb.devuan.org/merged archive sometime before 2019-07-14 13:12:27 +0100 as that was when my unattended upgrades program downloaded it.
Both the previous Firefox-esr secuirty 60.7.1 and 60.7.2 security updates also downloaded shortly after Debian put them in their stable archive (though they hit Debian experimental and then testing sooner). I see no problem here.
Any idea when we might expect to see Firefox-esr 68 on ascii? I understand there will be another 2 months of security updates still to come on 60 before it becomes unsupported which implies it might be best to have a backpost before Beowulf becomes our new stable.
I'm assuming you've already tried using CUPs with the available drivers provided there?
In my case I use the driver for a slightly different Brother model: I have a DCP 9015CDW and use the DCP 9010CDW dirver which works fine, including duplex.
A cursory search finds there's a discussion of drivers to use for your model here: http://openprinting.org/printer/Brother … -HL-2270DW.
When I look for lines including nvidia when I boot I see this:
marjorie@erewhon:~$ sudo cat /var/log/dmesg | grep -i nvidia
[ 1.251024] udevd[87]: Error running install command for nvidia
[ 3.685958] nvidia: loading out-of-tree module taints kernel.
[ 3.685972] nvidia: module license 'NVIDIA' taints kernel.
[ 3.710764] nvidia-nvlink: Nvlink Core is being initialized, major device number 248
[ 3.711615] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 390.116 Sun Jan 27 07:21:36 PST 2019 (using threaded interrupts)
[ 4.350801] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card2/input13
[ 4.351196] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card2/input14
[ 5.661013] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 390.116 Sun Jan 27 06:30:32 PST 2019
[ 5.703206] [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
The failure to load the module is by udev. Somewhat later, in userspace the module is loaded, the mode is set and finally the driver is loaded.
If we look at the man page for nvidia-modprobe it says:
DESCRIPTION
The nvidia-modprobe utility is used by user-space NVIDIA driver components to make sure the NVIDIA kernel module is loaded and that the NVIDIA
character device files are present. These facilities are normally provided by Linux distribution configuration systems such as udev. When possi‐
ble, it is recommended to use your Linux distribution's native mechanisms for managing kernel module loading and device file creation. This util‐
ity is provided as a fallback to work out-of-the-box in a distribution-independent way.
My take on this is that devuan's udev (-eudev) is failing to load the module and that it's then being loaded as a fallback by nvidia-modprobe.
The issue is then why udev fails to load the module and I've no information on why this fails.
I didn't see the warning message on my old Mint Rosa distribution, The nvidia lines there were:
/media/marjorie/dc44c8b4-9d77-4ca3-9b39-1b0b352d7a80/var/log$ sudo cat ./dmesg | grep nvidia
[ 16.201881] nvidia: loading out-of-tree module taints kernel.
[ 16.201889] nvidia: module license 'NVIDIA' taints kernel.
[ 16.239873] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[ 16.253093] nvidia-nvlink: Nvlink Core is being initialized, major device number 245
[ 16.253816] NVRM: loading NVIDIA UNIX x86_64 Kernel Module 384.130 Wed Mar 21 03:37:26 PDT 2018 (using threaded interrupts)
[ 16.260391] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 384.130 Wed Mar 21 02:59:49 PDT 2018
[ 16.262006] [drm] [nvidia-drm] [GPU ID 0x00000100] Loading driver
[ 16.529536] nvidia-uvm: Loaded the UVM driver in 8 mode, major device number 244
[ 16.544189] systemd-udevd[979]: failed to execute '/bin/systemctl' '/bin/systemctl start --no-block nvidia-persistenced.service': No such file or directory
[ 16.685718] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input13
[ 16.685806] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input14
[ 17.390018] systemd-udevd[1038]: failed to execute '/bin/systemctl' '/bin/systemctl stop --no-block nvidia-persistenced': No such file or directory
From what I remember, XFCE likes network-manager-gnome package. Install that, it installs ontop of NM, so leave him alone. This *gnome package should provide an app called nm-applet. It will be a panel/sys tray app.
You may need to add the nm-applet to the panel/sys tray. Someone else with XFCE installed should take over from here as I am running on faded memories.
As Micronaut says they prefer XFCE + selective gnome then, as you suggest, adding the relevant Gnome packages,until it works bits seems sensible. However interestingly the Devuan live CD chooses to uses XFCE with wicd for network management. I had the live CD .iso working and then installed on my setup to prove wireless (and other services) worked OK under Devuan on my system but I then went back and used the installation DVD .iso + advanced install to configure with RAID1 (mirrored drives) and Cinnamon. Cinnamon gives me the same toolkit (such as Rhythmbox for sound, Evolution for mail, Network Manager for WiFi) and interface as I had when I was using Mint (and before that Gnome 2 Ubuntu).
As you were coming from Mint (as I did - I was previously using ROSA which EOLed in April) I would have expected you to have gone with Cinammon as your DM - I'm not clear from your post what you've chosen), in which case you should have got a full Network Manager install as part of the package, including a panel notification icon (network@cinnamon.org). Clicking on the icon gets me into the configuration and it correctly shows my single ethernet port as unplugged. With the wireless there are 2 SSID shown and they are configurable there and there's also a toggle to switch the WiFi off completely.
Of course, that may not fix your boot problem as you say it may be an specific issue with your motherboard or its twin ethernet ports: mine's a Gigabyte board of 2011 vintage.