There's no justification for anger. Runit has a diligent maintainer who is extremely attentive to actual bug reports - which this isn't - as you can see from his fast resolution of the bug report I posted above. Use 'reportbug runit-init'. You should include your analysis of the problem and suggested solution.

Good news: we've worked out (on the bug) why this happens and are discussing the most appropriate patch to the elogind source which lets us benefit from the intended changes in the latest package.

The reason I asked wasn't as a workaround but to try to diagnose the underlying problem but thanks!

Have you tried killing slim and restarting it, or not letting it start and then manually starting it? Could be a startup ordering and synchronization issue. Are you using sysvinit?

@tux_99 thanks for your comments! Not the original author, no, but it was abandoned for 20 years. I fixed a bug earlier in the year and before you know it I had forked it and fixed a ton more - the changelogs are under /usr/share/doc/sysv-rc-conf. The Debian trixie freeze had already started so this was too late for excalibur.

At the risk of adding more confusion, I have to say sbuild is really where it is at in Debian today: it's the go-to tool for this and actively looked after. If you're on daedalus probably worth using the backport. https://wiki.debian.org/sbuild

It's the other way round: 'usrmerge' converts /bin and /sbin into symlinks pointing to the corresponding directories under /usr. It's not new to Excalibur but does become compulsory.

I use cryptsetup for whole disk encryption. It has good Devuan integration. Since Excalibur it can also harness OPAL hardware-based SSD encryption - I use this on low performance machines.

Hi fsmithred,

I don't know about the live ISOs - that is a different matter, I think.

For my test I used netinst (installer-iso, 23 August) so it's a question more of what packages are 'standard' priority (I think) rather than which packages were on the ISO (sorry my knowledge in this area is weak).

Now that rsyslog is not special perhaps Devuan could select its own preferred logger, that might be more init-freedom-friendly, from the options available without bias towards what used to be the Debian default? Of course it may turn out that rsyslog is still the best choice - I don't know!

Am I right in thinking that our 'DAK' can have overrides that change the priority of packages and setting that for one of the Provides of system-log-daemon would do the trick? Or maybe that doesn't work because we aren't rebuilding the packages, in which case does the installer also have a way of promoting a package into the basic task selection?

Known by us but I wonder if having no syslog logger by default is a Devuan oversight (for Debian since bookworm they have relied on systemd-journald). I think they can maybe override the 'priority' field of one preferred logger without having to fork the package itself. I suggest it's worth a Devuan bug report.

Are you thinking of the wine-development package? This was removed in May: https://bugs.debian.org/cgi-bin/bugrepo … ug=1103851

I just noticed https://web.git.kernel.org/pub/scm/linu … cd8fb1f9f8 via https://www.theregister.com/2025/05/28/ … 5_arrives/ - seems we'll be denied the option to build a vanilla kernel that can take advantage of >4GB. To be fair, as the commit log says, this is perhaps fairly niche because in the most obvious use cases (involving 64-bit CPUs) then a 64-bit kernel still works with 32-bit userspace. Still sad, though.

Thanks for the logging tips, Alverstone! I haven't had cause to use yet but useful to have in mind.

I think you are probably right about the serial port. Unexpected use of the serial port is a classic cause of unexplained problems, like debug being interleaved into operational communications and slow/blocked processing!

Perhaps some other test should be used as a proxy to determine whether the serial port is suitable, e.g. a kernel command line value or the enablement of serial logging from some other component.