Posts by grunchy

grunchy · Other Issues

Hund wrote:
May I ask why you bother with OpenVPN when we have WireGuard?

laziness primarily :-)

but also customizability

wireguard is easier to set-up and is faster since most everything happens in kernel-space but openVPN offers considerably more flexibility. and my bandwidth needs are so limited there is no real benefit from a higher-speed connection.

openVPN is far more flexible: you can change port, choose from a wide range of cipher and key-exchange choices, have more knobs for authentication and policy control. and you can implement complex rules for split tunneling.

i have invested a lot of time and effort in my VPN configuration over the years - lots of scripts, lots of customizations - so it will require significant effort for me to move away. not too unlike the effort of the upcoming KDE x11-to-wayland transition, which i may avoid by dumping KDE for lxqt, also requiring lots of effort ...

and have also avoided the "apps" provided by the VPN providers, as i prefer to customize my openVPN configurations. not too certain, but recall reading that some VPN providers have a "unique" wireguard implementation that requires you to use their "app", which i will not do. (this is an old memory and may no longer be true)

as i understand it, wireguard's primary appeal is the ease of set-up, so you get what is functionally an IPSec tunnel but without the complexity.

this simplicity means you forgo lots of options, such as running over TCP (port 443) or choosing an encryption protocol.

one of the worrying aspects of wireguard (to me) is that debugging a non-working wireguard setup is difficult and means you need a good amount of networking knowledge. this is made more difficult as there are no logs to examine, so you need to look at routing tables, firewall rules, check for key mismatch, etc. also a wireguard tunnel may silently stop working and you will not know until you try to use it, as there is no error message, no notification that something went wrong.

grunchy · Other Issues

posting a follow-up for completeness.

i did not try installing from ceres as more than one package would be involved.

i was able to install the trixie-backports version, which worked! not sure why the devuan fork is needed.
note that i am using openvpn as a client NOT as a server, so maybe the result would be different when running as a server.

here are the details:

with the ceres version, apt wants to install 2 companion packages

/home/xyz> apt-get -s install openvpn=2.7.2-1devuan1                                               
NOTE: This is only a simulation!
      apt-get needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Solving dependencies... Error!
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 openvpn : Depends: libnl-3-200 (>= 3.11.0) but 3.7.0-2 is to be installed
           Depends: libnl-genl-3-200 (>= 3.11.0) but 3.7.0-2 is to be installed
E: Unable to correct problems, you have held broken packages.
E: The following information from --solver 3.0 may provide additional context:
   Unable to satisfy dependencies. Reached two conflicting decisions:
   1. libnl-3-200:amd64=3.12.0-2 is not selected for install
   2. libnl-3-200:amd64=3.12.0-2 is selected as an upgrade because:
      1. openvpn:amd64=2.7.2-1devuan1 is selected as an upgrade
      2. openvpn:amd64=2.7.2-1devuan1 Depends libnl-3-200 (>= 3.11.0)

adding those two packages would work, but i do not want to deal with more than one package

/home/xyz> apt-get -s install openvpn=2.7.2-1devuan1 libnl-3-200=3.12.0-2 libnl-genl-3-200=3.12.0-2
NOTE: This is only a simulation!
      apt-get needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  libnl-route-3-200 wpasupplicant
The following packages will be upgraded:
  libnl-3-200 libnl-genl-3-200 openvpn
3 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Remv wpasupplicant [2:2.10-24]
Remv libnl-route-3-200 [3.7.0-2]
Inst libnl-genl-3-200 [3.7.0-2] (3.12.0-2 Devuan:1.0.0/unstable [amd64]) []
Inst libnl-3-200 [3.7.0-2] (3.12.0-2 Devuan:1.0.0/unstable [amd64])
Inst openvpn [2.7.1-1~bpo13+1] (2.7.2-1devuan1 Devuan:1.0.0/unstable [amd64])
Conf libnl-genl-3-200 (3.12.0-2 Devuan:1.0.0/unstable [amd64])
Conf libnl-3-200 (3.12.0-2 Devuan:1.0.0/unstable [amd64])
Conf openvpn (2.7.2-1devuan1 Devuan:1.0.0/unstable [amd64])

for the excalibur default, openvpn 2.6.14, ldd says this

/home/xyz> ldd /usr/sbin/openvpn
        linux-vdso.so.1 (0x00007884d4b96000)
        liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x00007884d4a67000)
        liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007884d4a40000)
        libpkcs11-helper.so.1 => /lib/x86_64-linux-gnu/libpkcs11-helper.so.1 (0x00007884d4a1f000)
        libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007884d4911000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007884d42d6000)
        libnl-genl-3.so.200 => /lib/x86_64-linux-gnu/libnl-genl-3.so.200 (0x00007884d42cf000)
        libnl-3.so.200 => /lib/x86_64-linux-gnu/libnl-3.so.200 (0x00007884d42ac000)
        libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007884d42a4000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007884d40b0000)
        libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 (0x00007884d409d000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007884d407b000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007884d3fb1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007884d4b98000)

for trixie-backports, openvpn 2.7.1, ldd says this

/home/xyz> ldd /usr/sbin/openvpn
        linux-vdso.so.1 (0x00007654370a3000)
        libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (0x0000765436f82000)
        libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x0000765436f7a000)
        libnl-genl-3.so.200 => /lib/x86_64-linux-gnu/libnl-genl-3.so.200 (0x0000765436f73000)
        libnl-3.so.200 => /lib/x86_64-linux-gnu/libnl-3.so.200 (0x0000765436f50000)
        liblzo2.so.2 => /lib/x86_64-linux-gnu/liblzo2.so.2 (0x0000765436f2a000)
        liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x0000765436f03000)
        libpkcs11-helper.so.1 => /lib/x86_64-linux-gnu/libpkcs11-helper.so.1 (0x0000765436ee2000)
        libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x0000765436dd4000)
        libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x000076543679b000)
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007654366d8000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007654364e2000)
        /lib64/ld-linux-x86-64.so.2 (0x00007654370a5000)
        libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 (0x00007654364cf000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007654364af000)
        libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007654363e5000)
        libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007654363d9000)

the extra libraries in the trixie-backports version are libcap.so.2, libgtk3-nocsd.so.0 and libsystemd.so.0.
i do not think the first two libs are what requires the devuan fork, but perhaps i am mistaken.
the reference to libsystemd does seem like it would be the reason for a devuan fork. however, on the
excalibur machine i'm using libsystemd IS present

/home/xyz> ls -l /lib/x86_64-linux-gnu/libsystemd.so.0 
lrwxrwxrwx 1 root root 15 Jan 21  2025 /lib/x86_64-linux-gnu/libsystemd.so.0 -> libelogind.so.0

i am curious to know what happens to this symlink when elogind is replaced by dummy-logind.
just guessing, but that symlink looks to be taking care of whatever openvpn wants from libsystemd.

the install of openvpn 2.7.1 from trixie-backports was successful, with no error reported

/home/xyz> sudo apt install /tmp/openvpn_2.7.1-1~bpo13+1_amd64.deb 

Note, selecting 'openvpn' instead of '/tmp/openvpn_2.7.1-1~bpo13+1_amd64.deb'
Upgrading:
  openvpn

Summary:
  Upgrading: 1, Installing: 0, Removing: 0, Not Upgrading: 0
  Download size: 0 B / 684 kB
  Space needed: 77.8 kB / 26.1 GB available

Get:1 /tmp/openvpn_2.7.1-1~bpo13+1_amd64.deb openvpn amd64 2.7.1-1~bpo13+1 [684 kB]
Reading changelogs... Done  
Preconfiguring packages ...
(Reading database ... 189146 files and directories currently installed.)
Preparing to unpack .../openvpn_2.7.1-1~bpo13+1_amd64.deb ...
Unpacking openvpn (2.7.1-1~bpo13+1) over (2.6.14-1+deb13u1devuan1) ...
Setting up openvpn (2.7.1-1~bpo13+1) ...
Installing new version of config file /etc/init.d/openvpn ...
Installing new version of config file /etc/network/if-down.d/openvpn ...
Installing new version of config file /etc/network/if-up.d/openvpn ...
Processing triggers for man-db (2.13.1-1) ...

and openvpn started-up in client mode without error

2026-04-25 23:52:12 OpenVPN 2.7.1 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
2026-04-25 23:52:12 library versions: OpenSSL 3.5.5 27 Jan 2026, LZO 2.10
2026-04-25 23:52:12 DCO version: 6.19.11+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.19.11-1~bpo13+1 (2026-04-13)
<snip>
2026-04-25 23:52:13 chroot to '/tmp/ovc' and cd to '/' succeeded
2026-04-25 23:52:13 UID set to nobody
2026-04-25 23:52:13 GID set to nogroup
2026-04-25 23:52:13 Capabilities retained: CAP_NET_ADMIN
2026-04-25 23:52:13 Initialization Sequence Completed
2026-04-25 23:52:13 Data Channel: cipher 'AES-256-GCM', peer-id: 1
2026-04-25 23:52:13 Timers: ping 10, ping-restart 60

grunchy · Other Issues

thanks for the replies! will try both recommendations. marking as solved.

grunchy · Other Issues

openvpn 2.7.1 is now available in ceres repo. i want to try out this new version on my excalibur desktop, but am unsure how to go about this.

first question: once version 2.7 makes it to freia will it ever be back-ported?

relatedly, is there a way to check which packages are in the process of being back-ported?

second question: is there a best-practice for adding a single package from testing to stable?

my initial thought is to download the .deb and install via dpkg -i, overwriting the installed openvpn files. i would prefer to keep the existing version, 2.6.14-1+deb13u1devuan, and have the version 2.7 openvpn as a second option. is that doable?

grunchy · Devuan

damn, this is bad news. i had hoped PLM would primarily be a bug-fix fiesta as SDDM has been left to rot.

theregister has a good write-up about this move:
https://www.theregister.com/2026/01/26/ … emd_login/

the article says that PLM depends on the systemd-logind service. maybe elogind can be adapted to handle whatever it is that systemd-logind is doing beyond what elogind already handles?

too bad openrc user-services management have not been adopted by devuan. that could provide a way to (semi-automatically?) transliterate systemd user-unit syntax/semantics to something else; or, at least provide insight on how to go about providing user-services management in an sysvinit-based system. but maybe this is not possible.

regardless, this move clearly signals the intent of the KDE devs to willingly abandon part of their userbase. who does that? numpties, the lot of them.

grunchy · Desktop and Multimedia

a fork to bring development into KDE proper is already underway

good to hear. may kde do better. i am ready to jump ship to anything else. even the TUI greeters @EDX-0 mentions.

grunchy · Desktop and Multimedia

oops ...

I have /etc/sddm/wayland-session and /etc/sddm/Xsession and neither one looks like a config file to me.

my bad. the sddm config file i used was of my own making. the directory used is /etc/sddm.conf.d/

the "displayserver" keyword tells sddm what you want, either "x11" or "x11-user"

this is what my file contains:

[Autologin]
Session=plasmax11
User=xyz

[General]
InputMethod=
DisplayServer=x11-user
##DisplayServer=x11

i can toggle between the two by changing the displayserver value and rebooting.

note that inputmethod=<blank> does not work, the virtual keyboard remains.
also, autologin works as expected when using "x11" mode, but does not work when using "x11-user" mode.
in "x11-user" mode, a logout takes you to console login as sddm has died.

with a root X11 session this is what i get:

> ps -u -p $(pgrep X) | less
USER       PID %CPU %MEM    VSZ   RSS TT       S  STARTED     TIME COMMAND
root      1718  1.7  3.1 650296 126456 ?       S 18:52:34 00:23:27 /usr/lib/xorg/Xorg -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_OdxMnf -noreset -displayfd 16

grunchy · Desktop and Multimedia

hi @kapqa, thanks for the offer of help, but i cannot reproduce the issue that i reported in the original post.

the non-root X11 session is a new thing in the latest sddm, prompted by wayland behavior, i gather, and i wanted to get it working. sddm X11 sessions were always owned by root. a non-root X11 session is desirable based on the principle of least privilege, but is no biggie if it did not work. mostly, i was curious to try it.

https://en.wikipedia.org/wiki/Principle … _privilege

FYI, this is what i see when the non-root X11 session is running:

> ps -u -p $(pgrep X) | less
USER       PID %CPU %MEM    VSZ   RSS TT       S  STARTED     TIME COMMAND
xyz       1533  0.7  3.9 936652 160576 ?       S 14:06:57 01:44:12 /usr/lib/xorg/Xorg -verbose 3 -nolisten tcp -background none -seat seat0 -noreset -keeptty -novtswitch -auth /run/user/1000/xauth_eMzpPV -displayfd 13 vt1

grunchy · Desktop and Multimedia

thanks @lynch9, you cleared that up. i guessed the change was baked-in but did not examine the source code to confirm.

as i have recently read, using vt7 is an old convention for graphical sessions (X11), not a requirement. and as sddm is aligning with systemd behaviors, re-using vt1 is how-things-work now. since systemd uses on-demand allocation of tty's there does not appear to be any way to "request" vt7 be used.

grunchy · Other Issues

thanks @fsmithred, your recommendation worked! providing the release name to apt-install did the trick.

i guess apt got confused by the package numbering. the old ascii package was modified by devuan, so had a different (greater?) version string than the new, un-modified daedalus package.

and, yes, apt DID consider it a downgrade.

thanks @RedGreen925 for explaining what the 'epoch' colon is for. to elaborate on my intent here, i want to upgrade this vm to excalibur and the debian release notes suggests removing obsolete packages (section 4.9). did not expect to find any obsolete packages; was surprised to see that there was one. trying to remove it led me down this rabbit hole.

just for completeness, here is the install log. it shows that apt swaps out the obsolete libupower-glib1 for the current libupower-glib3 and downgrades upower to the current (newer) version:

> sudo apt install upower/daedalus   
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Selected version '0.99.20-2' (Devuan:5.0/stable [amd64]) for 'upower'
The following packages were automatically installed and are no longer required:
  ethtool libdbus-glib-1-2 libupower-glib1 libx86-1 pm-utils vbetool
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  libupower-glib3
The following NEW packages will be installed:
  libupower-glib3
The following packages will be DOWNGRADED:
  upower
0 upgraded, 1 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 118 kB of archives.
After this operation, 82.9 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://deb.devuan.org/merged daedalus/main amd64 libupower-glib3 amd64 0.99.20-2 [36.4 kB]
Get:2 http://deb.devuan.org/merged daedalus/main amd64 upower amd64 0.99.20-2 [81.2 kB]
Fetched 118 kB in 1s (146 kB/s)
Selecting previously unselected package libupower-glib3:amd64.
(Reading database ... 193098 files and directories currently installed.)
Preparing to unpack .../libupower-glib3_0.99.20-2_amd64.deb ...
Unpacking libupower-glib3:amd64 (0.99.20-2) ...
dpkg: warning: downgrading upower from 1:0.9.23-2+devuan1.3 to 0.99.20-2
Preparing to unpack .../upower_0.99.20-2_amd64.deb ...
Unpacking upower (0.99.20-2) over (1:0.9.23-2+devuan1.3) ...
Setting up libupower-glib3:amd64 (0.99.20-2) ...
Setting up upower (0.99.20-2) ...
Installing new version of config file /etc/UPower/UPower.conf ...
Processing triggers for dbus (1.14.10-1~deb12u1devuan1) ...
Processing triggers for eudev (3.2.12-4+deb12u1) ...
Processing triggers for libc-bin (2.36-9+deb12u13) ...
Processing triggers for man-db (2.11.2-2) ...

grunchy · Other Issues

thanks for the feedback @Altoid

yes, libupower-glib3 is the correct version. i can't get apt to update from the obsolete libupower-glib1 to libupower-glib3, something is borked in this vm but not sure what.

the version apt thinks is current is from ascii, at lease according to devuan package search:

upower
1:0.99.4-4+devuan3
   http://archive.devuan.org/merged ascii-proposed-updates/main amd64
1:0.9.23-2+devuan1.3                                  ** OLD **
   http://archive.devuan.org/merged ascii/main amd64  ** OLD **
1:0.9.23-2+devuan1.2
   http://archive.devuan.org/merged jessie/main amd64
1.90.10-1
   http://deb.devuan.org/merged ceres/main amd64
1.90.9-1
   http://deb.devuan.org/merged excalibur/main amd64
0.99.20-2                                             ** NEW **
   http://deb.devuan.org/merged daedalus/main amd64   ** NEW **
0.99.11-2
   http://deb.devuan.org/merged chimaera/main amd64
0.99.10-1
   http://archive.devuan.org/merged beowulf/main amd64

maybe the version "number" is confusing apt due to the presence of the colon?

Being a recommends and not a hard dependency, you probably don't need it.

for kde, upower is a 'depends' and not a 'recommends' so it cannot be removed:

> aptitude why libupower-glib1
i   task-kde-desktop   Depends kde-standard
i A kde-standard       Depends kde-plasma-desktop (>= 5:142)
i A kde-plasma-desktop Depends upower
i A upower             Depends libupower-glib1 (>= 0.9.2)

apt will remove the entire desktop when purging upower:

> apt -s purge upower
NOTE: This is only a simulation!
      apt needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  espeak-ng-data ethtool festival festival-freebsoft-utils festlex-cmu festlex-poslex festvox-kallpc16k gir1.2-atspi-2.0
  gir1.2-gstreamer-1.0 gir1.2-wnck-3.0 kdeaccessibility kmag kmousetool kmouth kontrast libatk-adaptor libbrlapi0.8
  libdbus-glib-1-2 libdotconf0 libespeak-ng1 libestools2.5 libpcaudio0 libqt5opengl5 libreoffice-help-common
  libreoffice-help-en-us libreoffice-kf5 libreoffice-plasma libreoffice-qt5 libsonic0 libspeechd2 libstartup-notification0
  libupower-glib1 libwnck-3-0 libwnck-3-common libx86-1 node-clipboard node-normalize.css node-prismjs orca perl-tk
  pm-utils print-manager python3-brlapi python3-louis python3-pyatspi python3-speechd python3-xdg qtgstreamer-plugins-qt5
  sound-icons speech-dispatcher speech-dispatcher-audio-plugins speech-dispatcher-espeak-ng speech-dispatcher-festival
  vbetool xbrlapi xkbset
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  kde-plasma-desktop* kde-standard* task-kde-desktop* upower*
0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
Purg task-kde-desktop [3.73devuan1]
Purg kde-standard [5:142]
Purg kde-plasma-desktop [5:142]
Purg upower [1:0.9.23-2+devuan1.3]

i'll keep digging. the apt-get man page has nothing about debugging it's behavior, so i guess that is not possible :-(

grunchy · Other Issues

my daedalus vm has been upgraded since ascii.

i just checked for obsolete packages with "apt list '~o'" and libupower-glib1 is the only obsolete package installed.

checking further, i see that libupower-glib1 cannot be upgraded to libupower-glib3 as it is depended on by package upower.

according to apt-cache, the version of upower currently installed is old and a newer version is available:

> apt-cache policy upower
upower:
  Installed: 1:0.9.23-2+devuan1.3
  Candidate: 1:0.9.23-2+devuan1.3
  Version table:
 *** 1:0.9.23-2+devuan1.3 100
        100 /var/lib/dpkg/status
     0.99.20-2 500
        500 http://deb.devuan.org/merged daedalus/main amd64 Packages

apt refuses to upgrade to the newer version.

what needs to be done to get apt to upgrade the upower package to the current version?

grunchy · Desktop and Multimedia

after a couple of days chasing this problem and not finding anything, i gave up and destroyed the vm.

re-creating the vm from the same iso worked as designed and sddm was able to create a non-root X11 session.

just to be sure, i went thu the install six more times, varying the steps to move from the default Xwayland session to the x11-user session. in all cases the non-root X11 session was created.

so i am at a loss to explain what happened on that first, buggy install

¯\_(ツ)_/¯

my apologies for the noise

on a side note, i did go down the sddm rabbit-hole looking for possible clues to this error, but could not find anything like what i encountered. but, there are multiple bug reports of 'black screen, blinking cursor'. this must be what happens when X11 fails at startup.

sddm is quite the mess and the maintainers are moving to wayland-only, no X11, as well as deprecating sysv init support to better align with systemd behavior. this is despite pleas from multiple people, both linux and bsd camps. as an old fart and an outsider to coding these days, i cannot fathom how a "simple" display manager has become such a bloated, tangled mess. geez

so excalibur may well be the last version of devuan to support KDE desktop

grunchy · Desktop and Multimedia

using devuan_excalibur_6.0.0-rc1_amd64_desktop.iso i just created an excalibur+kde+sddm qemu vm.

one of the nice things about this update is that X11 can be run as non-root.

with kde/sddm it is as simple as adding "DisplayServer=x11-user" to a sddm config file.

i tested this with a debian trixie qemu vm and it works as advertised, but it does not work with excalibur.
something in the hand-off from sddm to X goes badly and all i get is a black screen with a blinking cursor.

if "DisplayServer=x11" is used, then VT number 2 is used and X starts up without issue.

in contrast, the debian vm log file shows the hand-off using VT number 1 and systemd-logind taking over.

the "X11-user" log shows VT number 7 being used. here is a snippet from that Xorg.0.log:

[     8.128] (++) using VT number 7

[     8.128] (II) seatd_libseat init
[     8.128] (II) [libseat/libseat.c:73] Seat opened with backend 'seatd'
[     8.128] (II) [libseat/backend/seatd.c:212] Enabling seat
[     8.128] (II) seatd_libseat enable
[     8.128] (II) seatd_libseat handled 2 events
[     8.228] (II) seatd_libseat client activated
[     8.228] (II) xfree86: Adding drm device (/dev/dri/card0)
[     8.228] (II) Platform probe for /sys/devices/pci0000:00/0000:00:01.0/drm/card0
[     8.228] (II) seatd_libseat try open graphics /dev/dri/card0
[     8.228] (II) seatd_libseat opened graphics: /dev/dri/card0 (1:14)
[     8.230] (--) PCI:*(0@0:1:0) 1af4:1050:1af4:1100 rev 1, Mem @ 0xfa800000/8388608, 0xfcc00000/16384, 0xfea14000/4096, BIOS @ 0x????????/131072
[     8.231] (II) LoadModule: "glx"
[     8.231] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[     8.231] (II) Module glx: vendor="X.Org Foundation"
[     8.231]    compiled for 1.21.1.16, module version = 1.0.0
[     8.231]    ABI class: X.Org Server Extension, version 10.0
[     8.231] (==) Matched modesetting as autoconfigured driver 0
[     8.231] (==) Matched fbdev as autoconfigured driver 1
[     8.231] (==) Matched vesa as autoconfigured driver 2
[     8.231] (==) Assigned the driver to the xf86ConfigLayout
[     8.231] (II) LoadModule: "modesetting"
[     8.231] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[     8.231] (II) Module modesetting: vendor="X.Org Foundation"
[     8.231]    compiled for 1.21.1.16, module version = 1.21.1
[     8.231]    Module class: X.Org Video Driver
[     8.231]    ABI class: X.Org Video Driver, version 25.2
[     8.231] (II) LoadModule: "fbdev"
[     8.231] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[     8.231] (II) Module fbdev: vendor="X.Org Foundation"
[     8.231]    compiled for 1.21.1.3, module version = 0.5.0
[     8.231]    Module class: X.Org Video Driver
[     8.231]    ABI class: X.Org Video Driver, version 25.2
[     8.231] (II) LoadModule: "vesa"
[     8.231] (II) Loading /usr/lib/xorg/modules/drivers/vesa_drv.so
[     8.231] (II) Module vesa: vendor="X.Org Foundation"
[     8.231]    compiled for 1.21.1.15, module version = 2.6.0
[     8.231]    Module class: X.Org Video Driver
[     8.231]    ABI class: X.Org Video Driver, version 25.2
[     8.231] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[     8.231] (II) FBDEV: driver for framebuffer: fbdev
[     8.231] (II) VESA: driver for VESA chipsets: vesa
[     8.231] (EE)
Fatal server error:
[     8.231] (EE) xf86OpenConsole: Cannot open virtual console 7 (Permission denied)
[     8.231] (EE)
[     8.231] (EE)
Please consult the The X.Org Foundation support
         at http://wiki.x.org
 for help.
[     8.231] (EE) Please also check the log file at "/home/xyz/.local/share/xorg/Xorg.1.log" for additional information.
[     8.231] (EE)
[     8.231] (II) seatd_libseat finish
[     8.232] (EE) Server terminated with error (1). Closing log file.

as you can see there is a permission problem with VT number 7. it is not clear to me if the problem is due
to using VT7 instead of VT2 or if VT7 is the correct choice but permissions are such that non-root user cannot
access VT7.

how can i debug this further?

grunchy · Desktop and Multimedia

i have a debian trixie vm running KDE and SDDM. unlike devuan
daedalus, on login it does not switch to vt7, remaining on vt1.

i would like to make the debian vm behave like devuan and switch
to vt7.

in the debian vm, /usr/bin/Xorg is called with arguments not
present in devuan daedalus: -keeptty --novtswitch

there does not appear to be any config file that specifies these
arguments, so i cannot change/remove them.

does anyone know if these command-line arguments are hard-coded
in the sddm binary?

is it possible to change the behavior of sddm in this regard?

the debian trixie sddm is version 0.21 while the devuan daedalus
sddm version is 0.19

grunchy · Other Issues

hello, everyone. interesting thread. similar to user479 in post #44, i
wanted to add some more data for completeness.

i noticed the accumulating files last year but was not curious enough
to search for more information. just added rm's to my weekly clean-up
script.

based on another post, i commented-out IDTYPE=RANDOM, which prevents
the file accumulation and reverted the changes to my clean-up script.

based on this thread it appears that IDTYPE=RANDOM is a "good thing"
so those deletes will be getting added back.

my set-up is daedalus+KDE so sddm and pulseaudio are also installed.

on my system, the machine-id is defined in /var/lib/dbus/machine-id.
there is no /etc/machine-id file.

in addition to the ~/.dbus/session-bus and /root/.dbus/session-bus
directories mentioned in post #1, with KDE there is also the
/var/lib/sddm/.dbus/session-bus directory to clean-up.

and pulseaudio pollutes ~/.config/pulse with 6 files/directories, so
need to clean-up these as well:

<machine-id>-card-database.tdb
<machine-id>-default-sink
<machine-id>-default-source
<machine-id>-device-volumes.tdb
<machine-id>-runtime
<machine-id>-stream-volumes.tdb

no idea how this will change with excalibur.

grunchy · Other Issues

so i got curious to know more about the eudev package and came across an
interesting gentoo forum thread from july 2024

https://forums.gentoo.org/viewtopic-t-1170107.html

some background: the original eudev project was started, in part, because systemd
did not build on musl-libc systems and a fork of the udev portion of systemd was
required. see here:

https://www.linuxquestions.org/question … ost6280841

devuan ascii and devuan beowulf both sourced eudev from gentoo:

Homepage: https://wiki.gentoo.org/wiki/Project:Eudev

but, in 2021, gentoo retired the eudev package, replacing it with systemd-utils,
and since then devuan (chimaera, daedalus, excalibur) has sourced eudev from github:

Homepage: https://github.com/eudev-project/eudev

one post mentions that eudev was removed because it required a lot of maintenance,
which it didn't get, so was removed as the default as well as from the official
gentoo repository.

another poster says systemd-udev is independent of systemd and works in the absense
of systemd:

systemd devs have made few of the systemd utilities totally independent from
systemd. udev and tmpfiles are few examples.

There is a soft commitment by the systemd developers that as long as you don't
mind building the systemd repository, you can install components such as udev
without using systemd as your init system.

Will it last? I don't know. But it seems to me that they are more open to
this than they were in times past.

Much of the reason that forks of systemd such as eudev failed in the past is
because a number of people who would have otherwise worked on them, decided
it wasn't worth the time and effort when udev can be built from the systemd
repo and used on its own, without using systemd as init.

an interesting point mentioned in the thread is that the buysbox mdev project,
which is not in the devuan repos, can also be used instead of [e]udev if you
can live with its limitations (no support for lvm and crypt).

so, options are 'static /dev', busybox mdev, non-gentoo eudev (github) and
gentoo systemd-utils.

so many choices! even though devuan devs have (currently) settled on the github
eudev, if that goes titsup, there are other options. not as desirable, but still.

grunchy · Other Issues

thank you @steve_v for your very informative reply.

'apt show eudev' does mention the gentoo connection and the author, jaret jay cantu,
and says eudev is a fork of systemd-udev originally from 2015. the last github release
is 3.2.14 from october 2023.

never having checked, i just assumed eudev did all kinds of things to get /dev configured.
that it is mostly (exclusively?) used to support hot-plug of devices is surprising to me.
but then my knowledge of linux/debian is limited.

i wonder, does devuan source eudev unmodified from the github repo? or is it forked
anew?

grunchy · Other Issues

in anticipation of the excalibur release i have been investigating my current daedalus setup.

as i understand, perhaps incorrectly, two of the packages that liberate devuan from systemd are elogind and eudev.

elogind is neither an essential package nor automatically installed as it can be replaced by seatd.

similarly, eudev is neither an essential package nor automatically installed. on my system eudev
is a dependency of xserver-xorg-core.

/home/xyz> aptitude why eudev 
i   xserver-xorg-core Depends  udev (>= 149)
i   eudev             Provides udev

given that eudev is optional, is it possible to have a functioning devaun install without eudev?
what limitations would that entail? no X11, no /dev directory ...
would such a system be useable?

grunchy · Installation

corsair has sent me a replacement USB drive - via fedex from taiwan no less!

they immediately told me to do an RMA and were eager to close the ticket.
quite the experience.

i asked the two reps responding to the ticket what was wrong with the drive
and one ignored me, the other said:

"Probably a hardware failure."

the drive works perfectly fine, except for the not-bootable problem, so i am
skeptical the hardware is failing.

my guess is that corsair had a batch (or two or three) that had bad firmware
where the isbootable-bit in the code has not been set. oof!

grunchy · Installation

thanks for the (very old) corsair link. this "not bootable" problem appears to have
existed for almost 2 decades. as my canadian friends say, wtff?

i created a ticket on the corsiar website, will be interesting what kind of response i
will get, if any.

oh, and off-topic, but holy crap! about the corsair website. i was using one of my
highly restricted firefox profiles (you know, just in case) and the website pushes
you to install a firefox add-on that wants to become the default search engine.
just unbelievable. they are using a very dark dark-pattern to force this choice on
visitors. stay away from that website.

grunchy · Installation

boy do i feel dumb. i found out why netinstall would not boot.

the USB drive i use is really fast, a corsiar voyager GTX 128GB.
but, for reasons, this USB drive is not bootable. wtf?

i copied the netinstall iso to a different USB drive (sandisk) and
was able to install without issue.

i will mark this as solved (though it isn't) as the problem i am having
lies elsewhere. the devuan netinstall iso works just fine.

thanks for the advise everyone

grunchy · Installation

thank you. i'll give that method a try.

grunchy · Installation

i was not clear enough. i loop-mounted the iso file not the USB drive.

i checked the USB drive as well by mounting it on a running system.

the ventoy trick did not work. ventoy was able to start the installer and i got to the
inital screen. after i hit the enter-key a bunch of boot-time ouput scrolled past ending
in an error about not being able to mount /cdrom. an emergency shell was created
but the keyboard was unresponsive, so i could not so anything in the emergency shell.

my next idea is to disassemble the machine, extract the nvme drive, move it to an
external enclousure, plug it into my old kabylake machine, which has CSM mode,
and install there, then move the nvme drive back to the new machine and reassemble it.

grunchy · Installation

happy new year everyone!

i must be doing something really dumb but cannot figure out what.

i am trying to bring-up a ryzen 7700X system and want to use the daedalus netinstall iso.

the BIOS for this machine says it is EFI only due to the VBIOS of the 7700X CPU. not sure why that is
but that's what the BIOS says. it's MSI BIOS for B650 ITX motherboard.

the iso was copied to a USB drive via dd, as usual, but it is not recognized as a valid boot device
by the BIOS. for MSI, on reboot, F11 is used to get the boot drive selection menu and it does not
show the USB drive as a candidate.

i loop-mounted the iso and all the EFI bits appear to be there, so i must be doing something wrong.

to get around this problem, i copied the netinstall iso to a ventoy USB drive and booted netinstall
from there.

just curious if anyone knows what is going on with UEFI boot? is it a 7700X thing?

The officially official Devuan Forum!

#1 Re: Other Issues » [SOLVED] openvpn 2.7.1 and excalibur » 2026-04-27 23:26:06

Hund wrote:

#2 Re: Other Issues » [SOLVED] openvpn 2.7.1 and excalibur » 2026-04-26 20:28:47

#3 Re: Other Issues » [SOLVED] openvpn 2.7.1 and excalibur » 2026-04-19 18:29:30

#4 Other Issues » [SOLVED] openvpn 2.7.1 and excalibur » 2026-04-18 21:43:19

#5 Re: Devuan » Kde and Systemd - In the News » 2026-02-06 22:31:15

#6 Re: Desktop and Multimedia » excalibur/KDE non-root X11 session is broken » 2025-11-09 07:17:34

#7 Re: Desktop and Multimedia » excalibur/KDE non-root X11 session is broken » 2025-11-09 07:11:52

#8 Re: Desktop and Multimedia » excalibur/KDE non-root X11 session is broken » 2025-11-08 22:25:45

#9 Re: Desktop and Multimedia » KDE/SDDM issue: devuan v. debian » 2025-11-08 22:03:11

#10 Re: Other Issues » [SOLVED] apt problem - cannot update upower package to newer version » 2025-10-24 01:04:28

#11 Re: Other Issues » [SOLVED] apt problem - cannot update upower package to newer version » 2025-10-23 22:14:05

#12 Other Issues » [SOLVED] apt problem - cannot update upower package to newer version » 2025-10-22 22:06:52

#13 Re: Desktop and Multimedia » excalibur/KDE non-root X11 session is broken » 2025-10-16 21:29:09

#14 Desktop and Multimedia » excalibur/KDE non-root X11 session is broken » 2025-10-11 23:15:00

#15 Desktop and Multimedia » KDE/SDDM issue: devuan v. debian » 2025-10-09 23:38:29

#16 Re: Other Issues » [SOLVED] Growing file bloat in ~/.dbus/session-bus and /root/.dbus/session-bus » 2025-09-24 22:04:05

#17 Re: Other Issues » question: eudev package » 2025-08-06 22:51:25

#18 Re: Other Issues » question: eudev package » 2025-08-04 21:23:45

#19 Other Issues » question: eudev package » 2025-08-03 21:53:37

#20 Re: Installation » [SOLVED] cannot boot netinstall iso » 2025-01-10 19:02:29

#21 Re: Installation » [SOLVED] cannot boot netinstall iso » 2025-01-03 19:53:12

#22 Re: Installation » [SOLVED] cannot boot netinstall iso » 2025-01-02 23:13:44

#23 Re: Installation » [SOLVED] cannot boot netinstall iso » 2025-01-02 03:17:49

#24 Re: Installation » [SOLVED] cannot boot netinstall iso » 2025-01-02 01:15:59

#25 Installation » [SOLVED] cannot boot netinstall iso » 2025-01-01 23:45:26

Board footer