Beowulf Beta is here!

aus9 · 2020-03-29 02:03:19

To anyone interested

Today I boot up and the issue I had with removing systemd has automagically resolved, logout offers all options again included power management. I am on a tower so do not care about hibernate/ sleep for PC

cheers

aus9 · 2020-03-29 02:57:50

@kapqa

on post 24 you asked for a package to be included as you have an Epson printer.
Did you know Gutenprint has a lot of Epsons already?
http://gimp-print.sourceforge.net/p_Sup … inters.php

Hope that helps

aus9 · 2020-03-29 03:06:06

@fsmithred

on post 61 you suggested using keys Alt + F2 to get to tty 2.

On my internal hard drive install......Crtl + Alt + F2 works, but only after slim login screen appears.
ie I am unable to action those keys in the rough 15 seconds of SSD boot up with messages scrolling past. But I installed iso dated mar 11

Attempting to use these keys on the USB still ffails for me mar 11

As a little knowledge is dangerous
I did reboot after enabling file /etc/logins.def for line
CONSOLE console:tty01:tty02:tty03:tty04
full reboot.....no change to getting access to tty during boot.

I realize this may be useless info....but I submit it to show I am trying to help
and maybe eliminate others from trying similar things.

EDIT

so booting mar 25 usb.....
booting up using CAF2......does not change tty to tty2 for me but,
bootup was fast and /var/log/boot shows no udev error while the same usb gave me udev slowness before.

Thanks

(Nothing has been logged yet. If you're still seeing this message your current init system might not write bootup messages to the system console at all.)
Sun Mar 29 03:24:21 2020: [....] Activating swap...??7[ ok 8??done.
Sun Mar 29 03:24:21 2020: [....] Creating compatibility symlink from /etc/mtab to /proc/mounts. ...??7[warn8?? (warning).
Sun Mar 29 03:24:21 2020: [....] Cleaning up temporary files... /tmp??7[ ok 8??.
Sun Mar 29 03:24:21 2020: [....] Starting early crypto disks...??7[ ok 8??done.
Sun Mar 29 03:24:21 2020: [info] Loading kernel module lp.
Sun Mar 29 03:24:21 2020: [info] Loading kernel module ppdev.
Sun Mar 29 03:24:21 2020: [info] Loading kernel module parport_pc.
Sun Mar 29 03:24:21 2020: [....] Setting up LVM Volume Groups...??7[ ok 8??done.
Sun Mar 29 03:24:22 2020: [....] Starting remaining crypto disks...??7[ ok 8??done.
Sun Mar 29 03:24:22 2020: [....] Checking file systems...fsck from util-linux 2.33.1
Sun Mar 29 03:24:22 2020: ??7[ ok 8??done.
Sun Mar 29 03:24:22 2020: [....] Mounting local filesystems...??7[ ok 8??done.
Sun Mar 29 03:24:22 2020: [....] Activating swapfile swap...??7[ ok 8??done.
Sun Mar 29 03:24:22 2020: [....] Cleaning up temporary files...??7[ ok 8??.
Sun Mar 29 03:24:22 2020: [....] Starting: AppArmor[....] $Mounting securityfs on /sys/kernel/security??7[ ok 8??.
Sun Mar 29 03:24:22 2020: [....] Loading AppArmor profiles...??7[ ok 8??done.
Sun Mar 29 03:24:25 2020: ??7[ ok 8??.
Sun Mar 29 03:24:25 2020: [....] Starting Setting kernel variables: sysctl??7[ ok 8??.
Sun Mar 29 03:24:25 2020: [....] Configuring network interfaces...??7[ ok 8??done.
Sun Mar 29 03:24:25 2020: [....] Starting RPC port mapper daemon: rpcbind??7[ ok 8??.
Sun Mar 29 03:24:25 2020: [....] Starting NFS common utilities: statd idmapd??7[ ok 8??.
Sun Mar 29 03:24:25 2020: [....] Cleaning up temporary files...??7[ ok 8??.
Sun Mar 29 03:24:25 2020: [....] Setting up ALSA...??7[ ok 8??done.
Sun Mar 29 03:24:26 2020: [....] Setting sensors limits...??7[ ok 8??done.
Sun Mar 29 03:24:26 2020: [....] Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix??7[ ok 8??.
Sun Mar 29 03:24:26 2020: INIT: Entering runlevel: 2
Sun Mar 29 03:24:26 2020: [info] Using makefile-style concurrent boot in runlevel 2.
Sun Mar 29 03:24:26 2020: [....] Setting up console font and keymap...??7[ ok 8??done.
Sun Mar 29 03:24:26 2020: [....] Starting LVM2 poll daemon: lvmpolld??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting enhanced syslogd: rsyslogd??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting ACPI services: acpid??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting anac(h)ronistic cron: anacron??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting periodic command scheduler: cron??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting system message bus: dbus??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting bluetooth: bluetoothd??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting Common Unix Printing System: cupsd??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting CUPS Bonjour daemon: cups-browsed??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting session management daemon: elogind??7[ ok 8??.
Sun Mar 29 03:24:26 2020: [....] Starting MTA: exim4??7[ ok 8??.
Sun Mar 29 03:24:27 2020: [....] Starting MD monitoring service: mdadm --monitor??7[ ok 8??.
Sun Mar 29 03:24:27 2020: [....] Starting NTP server: ntpd??7[ ok 8??.
Sun Mar 29 03:24:27 2020: [....] Starting SANE network scanner server: saned??7[ ok 8??.
Sun Mar 29 03:24:27 2020: [....] Starting slim: slim??7[ ok 8??.

Last edited by aus9 (2020-03-29 03:34:18)

rolfie · 2020-03-29 18:43:15

IdeaFix wrote:

Is Devuan 3 ready to update prod servers from 2.1? I have no heavy load servers, but I need a native php7.3 and a stable system without X, DE and other... actually, only LAMP (in ESXi).

Depends on what you expect. My private little fileserver (samba and nfs) runs on Beowulf since last summer, can't complain, rockstable.

rolfie

aus9 · 2020-03-30 06:41:39

Does anyone think the following might explain my udev slowness for my SSD drive.
eg

Fri Mar 27 00:35:43 2020: WARNING: Device /dev/sda not initialized in udev database even after waiting 10000000 microseconds.

SSD would appear to use sata controller

lspci -vvv
snip
27:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode]
snip
Kernel driver in use: ahci

We have an initrd and I have finally worked out how to unpack it, if interested a separate post
https://dev1galaxy.org/viewtopic.php?pid=20812#p20812

unpacking it and searching for the kernel module gives me

root@box:/tmp/unpack# find . -name ahci.ko
./usr/lib/modules/4.19.0-8-amd64/kernel/drivers/ata/ahci.ko

My question....does the init process .....have a certain order....if so is it possible the loading of kernel modules is occurring late in the init process?

Last edited by aus9 (2020-03-30 06:42:10)

chris2be8 · 2020-03-30 15:56:11

You can use lsinitramfs to list the contents of an initrd.img. Also check the man page for unmkinitramfs (that's a script to extract content from an initramfs image). And other related commands.

An old trap is to update something in initramfs and reboot without rebuilding your initramfs (the update gets ignored). I found this the hard way getting CUDA working.

Chris

golinux · 2020-03-30 15:57:52

aus9 wrote:

Hi
I finally spotted but needed prompting this post
https://dev1galaxy.org/viewtopic.php?id=1925
as my removal of systemd stuff is on the beta iso I thought I would share the little I know here
And I am glad that link is a sticky too.

Happy to hear everything worked out for you.

Roger · 2020-03-30 22:16:05

A question on the upgrade notes. As I recall from previous upgrades on Debian, instructions are to do an upgrade before the dist-upgrade; presumably to upgrade packages that do not require reorganization and changes in dependencies. Is that not a good idea?

I did comment elsewhere on the fact that essentially all packages were upgraded when I made the changeover, and my recollection was that previously something like half of them were unchanged if regular checking had been done on upgrades with aptitude. I am normally upgrading packages weekly, and I had assumed this takes many of them to the level of the next release. In that case I thought the dist-upgrade dealt only with reorganized packages and changes in versions.

golinux · 2020-03-30 23:15:08

Roger . . . https://beta.devuan.org/os/install includes specific instructions for upgrade

Roger · 2020-03-30 23:40:36

Those are the notes that I used. But I just checked the release notes for Debian buster and they recommend doing apt-get upgrade before the full upgrade. My comment was that Devuan do not make q similar suggestion.

I am simply curious about how the upgrade process works. I assumed packages are upgraded continuously, I certainly do enough in between major releases. I suppose changes are held back until a major release change if they involve new versions and repackaging.

I did not have to upgrade from Devuan 2.0 to 2.1 because routine maintenance got me there seamlessly. Clearly the step to 3.0 involves just about everything.

golinux · 2020-03-31 00:08:42

dev1fanboy aka chillfan is meticulous in his documentation so I'm sure there is a reason. You could open an issue at https://git.devuan.org/devuan-doc/docum … dev1fanboy to ask him or send him an email via this forum. He hasn't been here since early March. Of course, someone else may know the answer. Just not me.

aus9 · 2020-03-31 02:04:30

@chris2be8

Thanks for the ls command. I did a slight mod to keep a list for later comparisons.

lsinitramfs /boot/initrd.img-4.19.0-8-amd64  > /tmp/init-list.txt

Do you know much about the order of processing initrd?

@golinux
I am fairly happy otherwise I would not be here. Need to improve some things tho.

aus9 · 2020-03-31 02:38:50

to anyone interested in sddm display manager read on.
spoiler alert...I am no longer using sddm see EDIT

I first attempted to install this and choose sddm over slim but unable to login via GUI over reboot.
manual login at tty worked and then startx worked ok.

I then read the notes (I always read and understand notes
http://files.devuan.org/devuan_beowulf/ … _notes.txt

Two session management systems are available in Devuan Beowulf:
- consolekit
- logind (elogind and libpam-elogind)
These session managers are mutually exclusive

so I used root powers to install consolekit first and full reboot and GUI slim login OK
then installed sddm and full reboot and GUI sddm login OK
also without loggng in...but sddm appears....I was able to login with tty2 with localname login and then startx.
#######################################################################
EDIT
above post was made 31 Mar.

I have restored an earlier image (I use fsarchiver images) that uses slim DM because I failed to test usb data stick.

Firstly on my restored image XFCE settings -> File manager -> Advanced I have enabled volume manager. No need to click image but it claims that gvfs (allegedly gvfs-vbackends) is not installed
but.....usb data sticks mount ok as read write storage.
https://imgur.com/sLNx2st

I have no time to trouble shoot why sddm caused my loss of this feature and
installing gvfs-backends with a full reboot made no difference.

Being impatient to do other things....I am not pursuing this any further but submitting the info in case someone has a similar issue if they migrate off slim DM

Thanks for reading

Last edited by aus9 (2020-04-01 06:18:49)

chris2be8 · 2020-03-31 16:39:32

aus9 wrote:

@chris2be8
Thanks for the ls command. I did a slight mod to keep a list for later comparisons.
lsinitramfs /boot/initrd.img-4.19.0-8-amd64  > /tmp/init-list.txt
Do you know much about the order of processing initrd?

I don't know anything about the order of processing initrd. Sorry.

I'd run lsinitramfs -l to get a long list of the contents. File sizes etc could be useful.

Chris

Ogis1975 · 2020-04-01 15:08:39

Forgive me for the stupid question. I would like to know when the release date of Devuan Beowulf is expected?

Last edited by Ogis1975 (2020-04-01 15:09:08)

Camtaf · 2020-04-01 18:12:08

It will depend on how many bugs need fixing, that is what the beta release is for.

Marjorie · 2020-04-01 21:57:17

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?

Last edited by Marjorie (2020-04-02 07:27:16)

Roger · 2020-04-01 23:13:49

Just did a test run on a virtual machine, and it repeated what happened previously adding the 4.19.0 kernel to an ascii system, namely installing apparmor. That gave me trouble with the previous 4.9.0 kernel, specifically handling locales. My quick check on what apparmor is leads me to conclude that I don't want it, and that furthermore it might get in the way of running one's system without any unnecessary impediments.

It seems to recommended for the 4.19.0 kernel, not a dependency, so I don't think dist-upgrade should be insisting on it. I moved to Devuan because I did not want to be told how I ought to do things.

dev-1-dash-1 · 2020-04-02 09:19:43

Marjorie wrote:

NVIDIA (nvidia-persistenced) issue in Beowulf Beta
However nvidia-persistenced failed to install properly.
...
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?

I think I remember having the exact same problem on an ASCII system and I've been able to solve it.
Nvidia almost always gives you at least SOME trouble when you install the drivers on linux.

Try stopping this service, purging it, reinstalling

service stop nvidia-persistenced
apt purge nvidia-persistenced
[maybe reboot here, if you do it after uninstalling service won't be running when you try to install again]
apt install nvidia-persistenced

fsmithred · 2020-04-02 10:21:43

Roger wrote:

It seems to recommended for the 4.19.0 kernel, not a dependency, so I don't think dist-upgrade should be insisting on it. I moved to Devuan because I did not want to be told how I ought to do things.

Recommends are installed by default, same as in Debian. To disable that:

apt-get --no-install-recommends install <package>

Or add the following to /etc/apt/apt.conf.d/00norecommends

APT::Install-Recommends "no";

Marjorie · 2020-04-02 11:35:15

Marjorie wrote:

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.

Last edited by Marjorie (2020-04-02 14:30:06)

danista · 2020-04-02 12:04:43

dmesg displays an error when loading relatively group "kvm".
Wouldn't it be a mistake to do so or not?

/lib/udev/rules.d/50-udev-default.rules
# KERNEL=="kvm", GROUP="kvm", MODE="0666" , OPTIONS+="static_node=kvm"

dev-1-dash-1 · 2020-04-02 12:17:44

Marjorie wrote:

NVIDIA (nvidia-persistenced) issue in Beowulf Beta
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.

It's just a harmless warning, you can ignore it.
As I've said try reinstalling the service.
If you are sure you don't need it, disable the service by running

update-rc.d nvidia-persistenced disable 2

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?

This file is just a few lines of text which are included in the package by nvidia. They are meant to be read by systemd (when it's present). This file does not, and can not, do anything on it's own when systemd is not there (as is the case in Devuan).
The reason these files are left on Devuan is probably because Devuan devs try to make as little changes to packages as possible so as not to break anything else in the process. Since these files are harmless and don't take much space they are left there. You can delete them on your own if you hate them so much or if a few kb of disk space matter.

Seems either Devuan or Debian should remove the recommend and/or correct /etc/init.d/nvidia-persistenced to make it work prperly.

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"

dev-1-dash-1 · 2020-04-02 12:24:09

danista wrote:

dmesg displays an error when loading relatively group "kvm".

I also had these warnings when on an beowulf test install.
I was running on bare metal.
Don't know why they appear or how to get rid of them.

Marjorie · 2020-04-02 14:39:57

dev-1-dash-1 wrote:

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.

The officially official Devuan Forum!

#76 2020-03-29 02:03:19

Re: Beowulf Beta is here!

#77 2020-03-29 02:57:50

Re: Beowulf Beta is here!

#78 2020-03-29 03:06:06

Re: Beowulf Beta is here!

#79 2020-03-29 18:43:15

Re: Beowulf Beta is here!

#80 2020-03-30 06:41:39

Re: Beowulf Beta is here!

#81 2020-03-30 15:56:11

Re: Beowulf Beta is here!

#82 2020-03-30 15:57:52

Re: Beowulf Beta is here!

#83 2020-03-30 22:16:05

Re: Beowulf Beta is here!

#84 2020-03-30 23:15:08

Re: Beowulf Beta is here!

#85 2020-03-30 23:40:36

Re: Beowulf Beta is here!

#86 2020-03-31 00:08:42

Re: Beowulf Beta is here!

#87 2020-03-31 02:04:30

Re: Beowulf Beta is here!

#88 2020-03-31 02:38:50

Re: Beowulf Beta is here!

#89 2020-03-31 16:39:32

Re: Beowulf Beta is here!

#90 2020-04-01 15:08:39

Re: Beowulf Beta is here!

#91 2020-04-01 18:12:08

Re: Beowulf Beta is here!

#92 2020-04-01 21:57:17

Re: Beowulf Beta is here!

#93 2020-04-01 23:13:49

Re: Beowulf Beta is here!

#94 2020-04-02 09:19:43

Re: Beowulf Beta is here!

#95 2020-04-02 10:21:43

Re: Beowulf Beta is here!

#96 2020-04-02 11:35:15

Re: Beowulf Beta is here!

#97 2020-04-02 12:04:43

Re: Beowulf Beta is here!

#98 2020-04-02 12:17:44

Re: Beowulf Beta is here!

#99 2020-04-02 12:24:09

Re: Beowulf Beta is here!

#100 2020-04-02 14:39:57

Re: Beowulf Beta is here!

Board footer