You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 Re: Installation » Forgot login/sudo password » 2026-03-13 18:18:28
Do you actually need to know the original password, or do you just want to reset it so the account is usable again? The latter is definitely possible, and a websearch should have given you an answer already. Here's the top result I got:
https://serverfault.com/questions/11218 … -on-debian
When it happened to me, I removed the password altogether by directly modifying /etc/passwd, so it's a valid alternative approach:
https://unix.stackexchange.com/a/533599
#2 Re: Freedom Hacks » About installers » 2026-02-20 23:42:04
I really would like people to put just a little bit of thought into how their software may reflect on them, before publishing it.
I assume you were obliquely referring to my comment, ralph.ronnquist, so I removed what is probably the part you found most objectionable.
But I have spent a great deal of my life trying to be polite and diplomatic, and I'm now at the age where I think a lot of the world's problems are caused by stupid people not being properly told they're being stupid. To that end, I've grown very fond of Linus Torvalds' occasional rants about "brain damage" in software, because that's what it is, and it needs to be called out. Politeness implies acceptance or at least tolerance, and stupid decisions should be greeted with neither.
Stupid decisions are stupid.
#3 Re: Freedom Hacks » About installers » 2026-02-20 22:51:41
The particular thing that annoys me is that I can't enable the online repos without a working internet connection at install time. I can get the wifi working after it's all installed but during setup I have no internet, so it throws a tantrum saying it can't set up the mirrors. Then I have to complete the install and manually add them to my sources.list. It doesn't even have the decency to leave them in as commented lines, it just gives me a worthless apt setup to fix myself.
It's like a toddler without object permanence. "If I can't see it, it doesn't exist." How about you just do what I say and enable them?
#4 Documentation » [HowTo] Use slimlock with xfce » 2026-02-19 18:10:02
- Mercury
- Replies: 0
slimlock is included with the slim login manager. If you already have slim installed, there is no need to get another screenlocker utility. However, slimlock has one major difference to all other screenlockers: When called, it does not return with a success code until after the screen is unlocked. Other screenlockers return immediately and keep the screen locked.
If slimlock is set as the lock command in xfce4, it will not work correctly with sleep security. (Xfce Settings → Power Manager → System → Lock screen when system is going to sleep) Since xfce4 waits for the screenlocker to return before putting the system to sleep, the user sees the lock screen but the system will not sleep. Once the user unlocks the screen, then the system will go to sleep. Obviously this is not what the user wants.
Here's how to fix it.
Create the file /usr/local/bin/aslimlock.sh with these contents:
#!/bin/sh
/usr/bin/slimlock &
sleep 1
pgrep --parent ${$} --full --exact "/usr/bin/slimlock"This script runs slimlock asynchronously, ensures that it is still running after one second, and returns a success or error code depending on the status.
Ensure this script is given execute permissions.
Now set aslimlock.sh as xfce4's lock command.
You can use the GUI: Navigate to Xfce Settings → Settings Editor → Channel: xfce4-session → Property: LockCommand; and enter /usr/local/bin/aslimlock.sh in the Value field.
Alternatively, you can use the command line:
xfconf-query --channel 'xfce4-session' --property '/general/LockCommand' --set '/usr/local/bin/aslimlock.sh'
The system will now correctly respond to a suspend request. The screen will lock and the system will enter sleep mode. On wake, the screen will be locked and awaiting a password.
#5 Devuan » Devuan 6.0 has no 32-bit edition? » 2026-02-15 16:03:04
- Mercury
- Replies: 3
I did not find any announcement about this. Was 5.0 the last 32bit release?
#6 Re: Hardware & System Configuration » [SOLVED] ext4 write slow on small 120gb sata SSD » 2026-02-13 18:25:19
with the tool kdiskmark, do you think id would prefer ntfs?
It's very unlikely that the filesystem is the culprit, though if you want to try ntfs as an experiment there's no harm.
What is the model of the drive? We may find the manufacturer's rated read and write speeds and see how far off your results are.
#7 Re: Hardware & System Configuration » [SOLVED] ext4 write slow on small 120gb sata SSD » 2026-02-13 16:45:05
it has the expected read speed 450-500 MB/s
however, the write speed is only abou 120 MB/s with ext4 fileformat;
How are you running these tests? The method may be giving skewed results, and/or there may be a bottleneck elsewhere than at the drive.
#8 Re: Desktop and Multimedia » Linux Audio for the hard of hearing » 2026-02-13 16:41:23
Of course. One might observe, with only mild amusement, that when a Windows user encounters a spot of bother with Linux, they often struggle to explain quite what they did — let alone articulate the nature of the problem in a way that makes the faintest bit of sense to anyone trying to help. It’s not their fault, really.
Stop your insulting, condescending, drivel.
The problem was described perfectly well: Audio on Windows can easily be made louder than normal, and there is no apparent way to do the same on Devuan. The poster was asking if there is a way, with the hope of receiving helpful instruction - of which your reply contained a negative amount.
If you did not understand the problem, then it is you who has comprehension difficulties.
The Debian ALSA configuration is better by default than many custom ~/.asoundrc examples found online.
Categorically false, in my case. ALSA insisted on outputting audio over the headphone jack when my primary use was over HDMI. Even switching card defaults was not enough because the card has several outputs and (bizarrely) ALSA recognizes the output I want as number 7. And even then, it needs a volume adjustment which ALSA doesn't do by default for what it thinks is a "SPDIF" output, necessitating a softvol control to be added. And on top of all of that I want to use the headphone jack sometimes.
I absolutely need an alsa.conf to get proper sound.
Have you tried something else?
Have you suggested something else? Your "contributions" so far seem to amount to criticising others.
#9 Re: Hardware & System Configuration » Using apt to find the package I want... » 2026-02-12 21:10:48
Synaptic is exactly the right level of UI for me, and I do use it especially for searching and simple installation, but it has at least three major issues that years later are still WONTFIX'd:
1. Locking a package version in Synaptic won't lock it for CLI apt, and vice-versa. Boggles the mind; it should be using the same mechanism, but it's not. No idea why they invented that fifth wheel.
2. It doesn't display 32bit and 64bit packages together. 64bit packages shadow the 32bit ones. You have ot go to the architecture tab to see the 32bit ones.
3. It always does something every time on startup and after packages are installed that is just sloooow and the GUI is unusable during this time. Some refresh or rescan, I don't know. It's a few seconds, but it's always a frustrating few seconds that screw up the flow. Borderline intolerable on weaker systems. No progress bar, no indication of what it's doing.
#10 Re: Installation » [SOLVED] Devuan 6.1.0 desktop installer has no options for modern filesystems » 2026-02-11 17:23:36
closest thing I see is "Load installer components from installation media" and nothing in there is extra for filesystem-related.
I believe it's lvmcfg that worked for me.
#11 Re: Installation » [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled? » 2026-02-11 01:09:04
I wrote up a guide based on what I learned so far: /viewtopic.php?pid=62061
I gave up on the wiki idea after waiting hours in chat like I was in the damn backrooms.
#12 Re: Installation » [SOLVED] Devuan 6.1.0 desktop installer has no options for modern filesystems » 2026-02-11 01:02:38
I don't have the installer ready anymore but I might try sometime later. I distinctly remember the same issue as OP. ext4 was simply not an option unless one of the optional components was selected.
#13 Re: Installation » [SOLVED] Devuan 6.1.0 desktop installer has no options for modern filesystems » 2026-02-11 00:55:36
Negative. I installed 6.0 and 6.1 several times. The "installer components" screen was always part of the process, but selecting no components gave only the limited filesystem options that the OP mentions. I was confused, because I have been using ext4 as my choice for many years. Experimentation showed that one of the options (I don't recall the name exactly - Volume Manager or something like it) was necessary to enable the full selection of filesystems.
#14 Re: Off-topic » XFCE is building a new WM and compositor for Wayland » 2026-02-10 20:51:44
Aside from utterly messing up the scroll bars by default (disappearing, without up/down buttons, and warping the slider on click, each of which requires a completely different file to fix) I haven't seen much in recent Xfce that stood out as bad. It looks mostly as I remember it from years ago. What are people complaining about, exactly?
#15 Documentation » An unofficial Guide to runit on Debian-derived distros » 2026-02-10 19:27:28
- Mercury
- Replies: 2
About this guide
This guide is intended to describe the behavior, use, and configuration of the runit init system on Debian-descended Linux distributions, including Devuan and its derivatives. It exists because important parts of the official runit documentation are misleadingly incomplete or outright wrong as applied to the version of runit packaged for Debian and its descendants.
This guide is a best-effort, based on hobbyist-level analysis. It may, and probably does, contain material errors. This guide is current as of January 2026, and applies to runit version 2.2.0 and runit-services version 0.10.1 as available in the Debian package repositories. This guide comes with no warranty whatsoever. Copying of this content, in part or in whole, with or without modification, is permitted and encouraged, and no attribution is required. This guide is licensed under the WTFPL version 2 or any later version
Directories
Runit service files are stored as follows. ( 🔗︎ indicates a symbolic link)
/etc/service/ 🔗︎ /etc/runit/runsvdir/current/ 🔗︎ /etc/runit/runsvdir/default/
Contains the currently active (enabled) services. Runit will react immediately to the creation or removal of items here. In a typical installation, most items in this directory will be symbolic links to /usr/share/runit/sv.now/ or to /etc/sv/, but links to services located elsewhere are also possible and will function as long as the service is properly defined at the target
/etc/sv/
Contains installed (but not necessarily enabled) local services. Services installed and managed by the local admin and/or manually converted from other init systems (systemd, sysVinit) should exist here. Enabled services should be the targets of symbolic links in /etc/runit/runsvdir/default/ (see above)
/usr/share/runit/sv.current/ 🔗︎ /usr/share/runit/sv.now/
Contains installed (but not necessarily enabled) stock services, that is, those installed by packages and managed automatically. Services existing here are “runtime copies” pulled from /usr/share/runit/sv.src/ (see below) when certain conditions are met to make them available for use. Enabled services should be the targets of symbolic links in /etc/runit/runsvdir/default/ (see above)
/usr/share/runit/sv.src/ 🔗︎ /usr/share/runit/sv/
Contains stock service definitions provided by packages. This directory is an extensive library of items only some of which apply to the current OS configuration. In general, these will never be the targets of symbolic links in /etc/runit/runsvdir/default/. When certain conditions are met, indicating that specific services should be enabled, they will be automatically copied to /usr/share/runit/sv.now/ and the symbolic links in /etc/runit/runsvdir/default/ will be created ro enable them (see the section “Service Sync” below)
Service Sync & Service Auto-enable
This important behavior lacks official documentation. At boot time, a service sync occurs.
Services available in /usr/share/runit/sv.src/ are checked, and if they are applicable to the currently configured OS, they will be synced via a copy operation to /usr/share/runit/sv.now/ where they are known as “runtime copies” and are considered properly installed. By default, they will then be automatically enabled by creating symbolic links in /etc/runit/runsvdir/default/ targeting the runtime copies (along with local services in /etc/sv/.)
Services are considered applicable if they include a /usr/share/runit/sv.src/${servicename}/.meta/bin file containing the name of an executable program present on the current OS configuration. If the service definition does not contain this file, or if the executable program referenced by it does not exist, then the service is presumed to be inapplicable and a runtime copy will not be created.
If the service definition in /usr/share/runit/sv.src/ is removed, there will be no effect on already-installed services in ⋯/sv.now/.
If the executable program referred to by the service ⋯/.meta/bin file is removed, the service will be automatically disabled at next boot by removing its symbolic link in ⋯/default/, however the runtime copy in ⋯/sv.now/ will not be affected and will remain installed for potential future use.
This process is controlled by the helper script /usr/lib/runit/trigger_sv, which is called directly from runit level 2 (/etc/runit/2) at each boot. trigger_sv further calls cpsv to sync services (selectively copy from ⋯/sv.src/ to ⋯/sv.now/), then automatically enables installed services (in ⋯/sv.now/ and in /etc/sv/) by creating links in ⋯/default/.
To override auto-enable behavior for a specific service, create a symbolic link in ⋯/default/, matching the name of the service with the addition of a leading dot, and remove the regular service link if it exists. For example, to disable the cron service, create the symbolic link /etc/runit/runsvdir/default/.cron 🔗︎ /usr/share/runit/sv.now/cron and delete the symbolic link /etc/runit/runsvdir/default/cron 🔗︎ . These actions can be performed in one command using the update-service utility. See the section “Disabling and Enabling Services” below for more details.
There is no intended configurable way to override auto-enable behavior globally for all services, and there is no intended configurable way to prevent the runtime copies from being created. However, the following methods will work:
To disable all service sync and auto-enable behavior at boot time, edit /etc/runit/2 and comment out the call to /usr/lib/runit/trigger_sv. Note that trigger_sv may still be automatically called as a dpkg postinst trigger during apt operations.
To disable the service sync only, but keep the auto-enable behavior, create a symbolic link /etc/runit/atomic.upgrade to target /usr/bin/true. trigger_sv will call atomic.upgrade preferentially over cpsv. This method may also be used to link to a script with custom service sync/copy logic that works with a curated list of services or performs more complex operations. Note that atomic.upgrade must target an executable file to be effective.
SysVinit Emulation
This important behavior lacks official documentation.
Runit will automatically start sysVinit services enabled at runlevel 2 (those in /etc/rc2.d/), if a runit service with the same name is not installed. The purpose is to maintain a reasonably functional system by using sysVinit services for which runit variants are not available or installed. The emulation logic checks for installed runit services in /usr/share/runit/sv.current and /etc/sv/ and enabled services in /etc/service/ to determine if a runit service with a matching name exists.
If both a sysVinit and runit service with the same name exist, the sysVinit service will not be started, regardless of whether the runit service is currently enabled. This means that if the user installs a runit service and disables it, the logic presumes that the user wants the service disabled altogether, and the sysVinit alternative is not desired. If the runit service is enabled, it will be used preferentially over its sysVinit variant.
This process is controlled by the helper script /lib/runit/run_sv_scripts, which is called directly from runit level 2 (/etc/runit/2) at each boot.
The following files can be used to override the default behavior described above. The files do not require any content. Only their existence is checked by the script logic.
/etc/runit/no.emulate.sysv
This file will disable sysVinit emulation completely.
/etc/runit/override-sysv.d/${servicename}.block
This file, matching the name of the service with the addition of a .block extension, will disable the emulation of that specific sysVinit service in all cases, even if a matching runit service does not exist.
/etc/runit/override-sysv.d/${servicename}.sysv
This file, matching the name of the service with the addition of a .sysv extension, will enable the emulation of that specific sysVinit service in all cases, even if a matching runit service (whether disabled or enabled) exists.
Note: A bug in runit-services versions 0.10.0 and earlier may cause a sysVinit service to start even when the matching runit service is installed and enabled, and even when a .block file is present for that service, which may cause unpredictable or buggy behavior. This has been observed to occur with login managers such as slim, causing login loops. This is caused by faulty script logic in dbus.dep-fixer, included in the runit-services package. This bug was corrected in runit-services version 0.10.1.
Disabling and Enabling Services
Official runit documentation states that simply deleting the service's symbolic link within /etc/runit/runsvdir/default/ will disable the service. However, because of the auto-enable behavior described in the “Service Sync & Service Auto-enable” section, this change will not persist across reboots for any services located in /etc/sv/ or in /usr/share/runit/sv.now/ (which together typically comprise almost all runit services). Deleting the link in ⋯/default/ in that case will disable the service only for the current session, and the service will be automatically re-enabled at next boot.
This does not apply to services located outside those two standard directories.
The auto-enable behavior will be inhibited by the presence of a symbolic link in ⋯/default/ matching the name of the service with the addition of a leading dot. For example, /etc/runit/runsvdir/default/.cron 🔗︎ will disable the cron service, and this effect will persist across reboots. Note that this file must be a valid symbolic link, and its target must be a directory to have the proper effect. Typically, the link targets the directory of the disabled service, but this is not strictly necessary, and linking to an empty dummy directory may be used to pre-emptively disable (or “blacklist”) a service before it is installed.
Runit will not start any service only linked by a dotfile in ⋯/default/, but if (for whatever reason) both a dotfile and regular symbolic link for a particular service exist there, then that service will start. Such a situation is typically the result of an error and may be regarded as a misconfiguration.
In general, directly adding, removing, or modifying the links in /etc/runit/runsvdir/default/ is not recommended. Debian-packaged runit provides the update-service command-line utility to manage services. This utility will manage symbolic links in ⋯/default/ and make other changes to persist service status.
Quick reference:
To enable/disable a service:
update-service --add service-directory
update-service --remove service-directory
These commands will, respectively, add and remove a service from runit supervision. This is accomplished by the creation and deletion of the appropriate symbolic links in /etc/runit/runsvdir/default/, as described above.
To set default service state:
update-service --auto service-directory
update-service --noauto service-directory
These commands will set the service to, respectively, started (“up”) and stopped (“down”) at system boot. By default any installed services are automatically started at boot time unless they have been marked not to be. This is accomplished by placing a down file within the service directory. The existence of this file indicates to runit that the service should not be auto-started at boot.
In any of the above commands, service-directory may be the full path to the service or only the basename (final part of the path; typically equal to the name of the service). In the latter case, the directories /etc/sv/ and /usr/share/runit/sv.now/ are searched, in that order, for the service, and the command is applied to the first one found.
See the manual page for more information.
Tips and Tricks
• To increase runit logging verbosity, create the file /etc/runit/verbose. This file does not require any content. Only its existence is checked. Runit logs its boot-time output to /var/log/boot.
• To list all enabled runit services and their paths, use this command:
for svc in $(update-service --list); do update-service --list $svc; done
There is currently no way to get this output from a single invocation of update-service, so the for-loop is necessary.
[More content to be added]
#16 Re: Installation » [SOLVED] Devuan 6.1.0 desktop installer has no options for modern filesystems » 2026-02-10 17:46:30
skipped the topic "load extra modules"
He didn't "skip" it. He just followed the default route. That step is optional and if I recall it even stated in the instructions that this is probably not necessary to do. It took me a while to figure it out myself, much to my frustration.
Installing modern Linux on ext4 is not some "extra" step, it's bog-standard.
Known problem
So surely it's been documented with an erratum note on the download page? On the installation instructions page? No? Why the bleep not?
#17 Re: Installation » [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled? » 2026-02-07 20:05:31
Perhaps you could take a little time and write up some better docs?
I wanted to take you up on the challenge but just getting an account on the official wiki is an obstacle course.
#18 Re: Installation » [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled? » 2026-02-03 22:21:21
The docs also say that simply deleting the link in/usr/share/runit/sv.current will stop runit from starting the service, but in fact the link is automatically regenerated, by a process that is also undocumented
I just did another mini-investigation. The link is regenerated by /usr/lib/bin/trigger_sv setup which is also called straight from /etc/runit/2 The comment says "sync available services". The function seems to be something to run once at install time or upgrade to discover services and enable them by default, not every boot after a user has disabled the service. In any case, totally undocumented. In fact, misdocumented, as I explained.
By my count we're up to at least four critical ways that runit does things contrary to its own specification.
This is not a new or experimental package. runit is over 20 years old. There is no excuse good enough.
#19 Re: Installation » [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled? » 2026-02-03 21:57:59
The bug isn't the problem that makes me angry, and you're being rather obtuse by focusing on that.
The issue is missing or, worse, outright incorrect documentation.
I've already laid it out in previous comments, but to summarize, there is nothing in the docs that says runit will start sysvinit scripts, but in fact it does (and fsmithred confirms it like this is something that everyone should know, somehow). The docs also say that simply deleting the link in/usr/share/runit/sv.current will stop runit from starting the service, but in fact the link is automatically regenerated, by a process that is also undocumented (and that I still don't understand).
Bugs in software happen. Sending your users on snipe hunts because yours docs are actively hostile is simply not acceptable.
There's no justification for anger.
Incorrect. I am quite justified in being angry here. The times I've seen "RTFM" smugly posted here and elsewhere would fill a river of arrogance.
#20 Re: Installation » [SOLVED] Is deb.devuan.org down or having trouble? » 2026-02-02 21:46:14
This is a long-running issue with DNS, and has been happening for at least a year. It happened to me several times. I don't know the exact cause or if the admins have tried anything serious to fix it. You can fix it by switching your DNS server to one of google's -- 8.8.8.8 or 8.8.4.4 -- those seem to always resolve the address correctly. Alternatively, you can change your sources.list file to point to a local mirror, such as ca.deb.devuan.org.
Previous posts about it:
/viewtopic.php?id=7416
/viewtopic.php?id=7066
#21 Re: Installation » [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled? » 2026-01-30 20:40:00
^ The very first sentence of the file you linked contains misinformation:
The /etc/sv/ directory contains service directories for a collection of
services available in Debian, to have them run under runit service
supervision instead of sysvinit or through init.d scripts.
As I said, that directory does not contain regular runit services. Those are in /usr/share/runit/sv/. Someone somewhere made that change and didn't document it, and did not fix scripts that rely on it, causing breakage.
The rest of the file is not helpful; slim is already a runit service. It does not need to be migrated.
Runit will use sysvinit scripts if there's no runscript for the service.
Where is this documented?!
The reason I'm angry is because there are several layers at which proper documentation would have helped me, but it's either wrong or simply missing. I'm a developer myself, and I make it a point to properly document my code, thought I have run into plenty colleagues who don't. The lesson I've taken is that 10 minutes of docs today can save hours of work for someone else weeks, months, or years from now. In this instance, it has, in fact caused me many hours of frustration. I can't process that as anything other than disrespect for the user.
#22 Re: Installation » [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled? » 2026-01-30 17:32:15
Okay, I finally understand what's happening.
Firstly, yes, runit starts sysvinit scripts, despite docs to the contrary. This is triggered from /etc/runit/2, which calls /lib/run/run_sv_scripts. (Good name, I guess.) All the online documentation is hopelessly out-of-date/wrong. I'm still angry.
run_sv_scripts tries to be clever by checking if a symlink with the name of the service exists in /etc/service/, precisely to prevent double-starts by ignoring sysvinit scripts for services that runit starts. This check works, and prevents slim from being started at this point. (Notably, this directory is symlinked to /etc/runit/sunsvdir/current/, where individual service dirs are symlinked to /usr/share/runit/sv.current/; foreshadowing.) Then follows another check (not reached in my case), which is in fact broken, which brings me to...
There is a runit service called dbus.dep-fixer which tries to ensure certain services that depend on dbus are really started, because the earlier start (by run_sv_scripts) might have failed due to timing issues. This script also tries to prevent double-starts by runit and sysvinit by looking for services that runit "knows about" in /etc/sv/. This check also appears in run_sv_scripts. This check is broken.
While online documentation (again, wrongly) says that runit service definitions (active or not) should be in /etc/sv, they are in fact in /usr/share/runit/sv/. There is no symlink from one to the other. /etc/sv contains some getty-tty stuff I don't understand, but it doesn't have the regular services (inlcluding slim) that runit manages. Hence, this check fails to find that slim is already a runit service, so the sysvinit script is run at this point.
And of course, runit tries to run slim as its ordinary service. The race happens between the regular slim service and dbus.dep-fixer.
Diagnosis: Someone moved around the runit directories and tried to duct tape it over with symlinks, but failed.
Fix: Add the line [ -d "/usr/share/runit/sv/$name" ] && continue to the loop in /usr/share/runit/sv/dbus.dep-fixer/run This allows runit to start slim as intended and prevents the double-start through the sysvinit script.
Consider this a bug report.
I'm out, and still angry.
#23 Re: Installation » [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled? » 2026-01-30 16:22:52
So runit is starting sysvinit scripts... somehow. slim isn't the only sysvinit service that's being started, but it was just the only one causing problems due to the double-start.
I don't know what logic in runit is doing this. This page describes the behavior I'm seeing:
All those executable files ( marked with *) are sysvinit scripts).
They wer all present at install time, except vsftpd which I installed as a test.
All these services are running. It is not clear to me whether runit automatically executes
all scripts in /etc/init.d, or whether it is triggered in some way.
...
At some point during startup, the runit process #1 must launch these sysVinit scripts
This is talking about Peppermint Dev1, but it's exactly what's happening on base. I'm definitely using runit. /sbin/init is symlinked to runit-init.
Everything else I've read says this should not be the case. Even google's AI says:
No, the runit process does not launch traditional sysvinit scripts in the way the user is implying. Runit and sysvinit are fundamentally different init systems with incompatible service management models.
...
Due to these differing models, a standard sysvinit script cannot be run unmodified as a runit service.
And while I'm not naive enough to trust AI, this at least shows that the preponderance of information available online says that sysvinit scripts are not directly launched by runit... except they are.
This is honestly very annoying, frustrating, and demoralizing. Why is this behavior not documented anywhere even semi-official? Why is the default configuration of runit/slim broken? I've spent hours of my own time just on investigating something that would've taken the developers, who clearly must've coded it to work this way, all of ten minutes to properly document it. This is unacceptable. I'm angry.
#24 Installation » [SOLVED] Weirdness with runit and slim/xfce; slim starts even when disabled? » 2026-01-29 23:48:39
- Mercury
- Replies: 14
(Skip to next paragraph to get to the meat of my problem.) I've been trying to understand some strange behavior on a fresh install of Devuan 6.1 on an older laptop. I installed the minimal system with runit then added xorg, xfce4, and slim. This laptop has a lot of odd quirks related to video and hardware, but that is (seemingly) beside the point. The problem that stumped me for a while is that sometimes, slim would display the login screen but fail to login; after inputting username and pass, it would blank the screen, then present the login again. This would cycle forever. This would happen even with autologin enabled, but this was also inconsistent. Examining processes revealed that slim was hanging onto a defunct instance of Xorg. Meanwhile, a new, live instance of Xorg had been started directly by runit (parent process 1). The solution was to manually kill Xorg and sv restart slim. I even wrote a script to do this that I could invoke more easily. Another weird, inconsistent behavior was that sometimes autologin would work and I'd get to my xfce desktop, but slim would appear in a window, which I could just minimize and ignore. Closing this window would just cause it to come back after a few seconds.
After a lot of frustration, it seems that slim was actually being started twice, causing some kind of race condition. One of the instances of slim would be started with the -d argument, the other without. The runit service definition did not have the -d arg. Troubleshooting, I just disabled the slim service (deleted the symlink from /etc/runit/runsvdir/default and... slim still starts!
The parent process is still 1, meaning runit is starting slim, with the -d arg, but I have no clue where this is coming from. The link in /etc/runit/runsvdir/default gets recreated on boot, again I don't know by what process, but I assume by slim or runit. For whatever reason, runit reports that the slim service is down.
So then I deleted the slim service file from /usr/share/runit/sv.current (where the symlink pointed to). And that gets recreated on boot. Finally, in desperation, I deleted the service definition from /usr/share/runit/sv -- that finally got the service to permanently not start.
But slim is still starting, with the -d arg, and I have no idea from where. Parent process is 1, so it seems runit is starting slim, but why does it do that without a service defined to do that? Everything I read online says that the login manager should be started as a service by runit (that's how one would switch from one LM to another if multiple are installed) and the default installed config was set up for that as well. Yet that broke things because slim got started twice -- once as the defined service, and secondly by... magic?
Oddly this has actually fixed my problem, at least so far through a dozen or so boots. I'm really just confused by what is happening. What logic is starting slim without a service defined?
#25 Devuan Derivatives » What happened to Star 4.0 (Uhura)? » 2024-11-14 16:54:13
- Mercury
- Replies: 2
There was a version 4.0 released sometime in 2023(?) but checking now, the latest available for download is 3.1 (Spock) from 2021.
I'm talking about this distro.
Why was Star 4.0 removed? Was there some issue with that release? It's still in use on one of my PCs and seems to be fine (at least after a couple of tweaks).
Pages: 1
Board footer
