You are not logged in.
- Topics: Active | Unanswered
#1 Re: Installation » Weird usb partitioning issues » 2026-05-01 20:05:06
It's not a "flaw" in parted, iso9660 on anything
It absolutely, objectively is a flaw when partitioning tools don't check the actual, contractual structure of a partition table including the 0x55AA signature, because they "think" they found an ISO9660 filesystem based on loosey-goosey pattern matching of non-contractual parts of the MBR. Everything in the MBR before the partition table and the two-byte signature is not and must not be used to conclusively determine disk structure. Any tool that does is doing it wrong.
Edited to add:
It's still baffling that gParted and parted behave differently, when they are supposed to be using the same underlying libparted library. As convenient as the GUI is, it's only gParted that gets it wrong, while parted (and presumably libparted) work correctly.
#2 Re: Installation » Weird usb partitioning issues » 2026-04-24 19:03:01
Unfortunately, I don't have any insight, but I have encountered instances where gparted was "confused" about the partitions on a drive but CLI tools (including parted!) correctly recognized the layout. I've been suspicious of it ever since.
#3 Re: Desktop and Multimedia » xfdashboard » 2026-03-28 17:59:59
I downloaded the three main DEB packages from the page I linked earlier, then simulated an installation:
apt --simulate install "/tmp/xfdashboard_1.0.0-0ubuntu5_amd64.deb" "/tmp/libxfdashboard0_1.0.0-0ubuntu5_amd64.deb" "/tmp/xfdashboard-plugins_1.0.0-0ubuntu5_amd64.deb"
The only dependencies required were all satisfied through the regular Devuan repositories. They are:
libclutter-1.0-0
libclutter-1.0-common
libcogl-common
libcogl-pango20
libcogl-path20
libcogl20
I.e. this is easy to install on Devuan.
#4 Re: Desktop and Multimedia » xfdashboard » 2026-03-26 03:52:14
For crying out loud. We're not talking about adding Ubuntu repositories - that is a bad idea. A controlled, manual installation of a small set of packages from DEB is not going to torch the system. I did it many times in the past. Sometimes, a package wanted a long chain of Ubuntu-specific dependencies that quickly got unwieldy. I just didn't install it in that case. Most of the time, it was a manageable handful of packages.
There's nothing "official" about my advice. Just stuff that works to achieve a goal.
#5 Re: Desktop and Multimedia » xfdashboard » 2026-03-26 00:28:55
Ubuntu packages are installable in Devuan, though dependency management can sometimes be tricky. You can download the DEBs here: https://launchpad.net/ubuntu/+source/xf … d/31059741
Download and simulate an install with apt:
apt --simulate install "./xfdashboard_1.0.0-0ubuntu5_amd64.deb" "./libxfdashboard0_1.0.0-0ubuntu5_amd64.deb"
And let apt tell you what dependencies it's missing.
#6 Re: Installation » How to pure OpenRC-based Devuan? » 2026-03-25 04:51:42
a fake init in this context, similar to runit (frankeninits).
As someone who's gone through quite a bit of keyboard-snapping frustration with runit, I think this isn't an accurate assessment. runit does use sysVinit service scripts to fill in for gaps in support, but it's a genuine init system with a solid core.
#7 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
#8 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.
#9 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?
#10 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.
#11 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?
#12 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.
#13 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.
#14 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.
#15 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.
#16 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.
#17 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.
#18 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.
#19 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.
#20 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?
#21 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]
#22 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?
#23 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.
#24 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.
#25 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.
Board footer
