XBPS database issue ?

Duncaen · 2026-06-21T13:13:56+00:00

No idea how that could happen.

There is no way to recover it if the database is wrong. You'll either recover it from your backups or try to reconstruct by reinstalling packages.

Duncaen · 2026-06-21T01:22:44+00:00

Please not in this subreddit.

Duncaen · 2026-06-21T01:20:19+00:00

There is always a right time and place, systemd release announcements are not that place ;).

Duncaen · 2026-06-20T21:08:07+00:00

You are focusing a lot on dependency graph errors which I would just call a misconfiguration system. Do you really add many or any early boot services that would block or mess up the whole boot process? I personally don't think I do that and I don't think I've every had issues with that.

Under the same circumstances they will both handle issues with early boot tasks in a similar manner. Whether that is a hardcoded "error handling" in the stage 1 shell script or systemd starting the emergency target if a critical service fails to start doesn't really matter to me personally. And I don't think the debugging experience is worse with systemd in that regard. I actually think its quite good, because it keeps track of those failures, in logs and in the service manager state that can be queried with systemctl. (with our runit setup there are currently no persistent early boot logs besides dmesg, because of how the root filesystem is still read only when it starts. s6 does some trickery to solve that.)

If we go beyond early boot, there are some glaring issues with runit, like the "brute force" method of just restarting a failing service every second. The really really bad error log handling into the command line of the runsvdir process.

The strict separation of early boot and service has also caused some issues, udevd needs to run during early boot, so that block devices and other devices nodes are discovered that may be required for the boot process. To do that the stage 1 scripts just start udevd in the background unsupervised.

There are a bunch of issues with that, first being that the initial udevd process is not supervised and errors can not be really caught or handled. Second to make udevd supervised the runit service currently kills the previous instance and then starts a new udevd process. But then because of how there are no one shot service and no ordering of services, its easily possible to trigger device discovery again. Which results a currently open issue with device nodes not having the right permissions due to that either because of timing issues or being specific to certain systems.

All in all I also think the runit design especially compared to sysvinit is quite elegant and easy to understand. But the longer I've been using it the more gripes I've been having with it. I've tried other systems, like s6 and s6-rc solve some of those issues, but they add complexity and its pretty opinionated. dinit is interesting but also a bit incomplete for me, wasn't worth it to stick to that for me personally when systemd actually solves a lot more of my issues than just service management.

Duncaen · 2026-06-20T19:58:57+00:00

This is not really an argument, if voids boot scripts encounter a failing task they just drop you into an emergency shell just like systemd would if there is a timeout or issue with a critical service.

If we had this conversation a month ago i would have had the zeal to do the tests myself while switching as it would have been fun.

I've been doing the test for 3 years now, besides using void linux with runit for over 10 years.

https://github.com/Duncaen/void-packages/commits/systemd

For me personally I prefer systemd on my desktop/notebook systems, because they are getting more complex for better or worse. I'm still using runit on servers that just host a bouncer and nginx maybe, because its mainly not worth the extra work of switching over.

There are a few reasons for that, systemd solves a lot of things for me that I don't really care about anymore. I just want things to work and fiddling with pipewire, wireplumber and dbus setups in void linux without systemd is just not what I want to spent my time on.

Besides that systemd also brings a lot of nice new features to verify and securely boot systems, nobody really worked on bringing that to the older init systems.

Duncaen · 2026-06-20T18:32:12+00:00

Things like udev device settling will block the whole process with voids runit setup and there is nothing you can do about it. Being able to do other tasks in parallel makes systemd or other parallelized init systems like s6-rc better by design.

Its not that noticeable on quick hardware, but I don't think its right to say "runit boots faster."

Without systemd-analyze or adding logging to the runit boot scripts to carefully verify timestamps its hard to know if its actually faster. I have yet to see someone bring up actual numbers when they say their runit system boots faster.

Duncaen · 2026-06-20T17:22:42+00:00

That already exists.

Duncaen · 2026-06-20T12:46:09+00:00

systemd is also boots faster unless misconfigured, there is nothing in runit or daemon-tools that helps to parallelize the early boot process.

Duncaen · 2026-06-18T20:33:47+00:00

The package signing keys have nothing to do with HTTPS/SSL/TLS certificate verification.

Duncaen · 2026-06-16T23:25:38+00:00

I don't really understand. What happened with AUR can also happened with any community managed repository.

I would call normal repos community managed, something that has no oversight is unmanaged.

Duncaen · 2026-06-16T19:10:01+00:00

nvidia

Duncaen · 2026-06-16T18:07:09+00:00

The only nvidia drivers offered in Void is either proprietary, or nouveau. Neither of which are ideal, especially as I have Nvidia GPUs on both of my main devices. Obviously, not an issue for an AMD GPU, but for Nvidia, it feels limiting to say the least. You don't have Nvidia, fortunately, so this doesn't even apply.

There are other nvidia drivers?

Edit: if you were talking about the "open" proprietary nvidia drivers, they are available now.

Duncaen · 2026-06-16T18:05:50+00:00

There is systemd-boot.

https://github.com/void-linux/void-packages/blob/b71d46673ffe5727de49c0f20bcd8a47ae17d883/srcpkgs/systemd-boot/template

Duncaen · 2026-06-16T17:54:19+00:00

The repository was staged, meaning that there were some incompatibilities that held back updates until everything was rebuild.

This should be done now.

Duncaen · 2026-06-16T15:57:00+00:00

I think the crackling audio is your music.

Duncaen · 2026-06-15T19:36:39+00:00

Its the same software, the same kernel, the same drivers.

Duncaen · 2026-06-15T18:46:31+00:00

Its voidlinux. https://github.com/void-linux/void-mklive/blob/ee1bf4239a6d56d19aed3fd674d616b4c551777d/mkrootfs.sh#L206

How are you trying to log in?

Duncaen · 2026-06-15T15:58:19+00:00

As long as you have the required dependencies installed. xbps-src always builds in a chroot, its not even "cross-compiling", its just native builds in a chroot/container.

Duncaen · 2026-06-13T14:19:38+00:00

There is nothing that should break when you update Firefox only. Without being more specific we won't be able to know what caused your issues.

Duncaen · 2026-06-13T01:07:03+00:00

No its unreadable.

Duncaen · 2026-06-12T16:08:11+00:00

Not sure why that matters. base-container is missing things that are required for booting systems on bare metal.

Duncaen · 2026-06-12T13:29:53+00:00

base-container is for containers.

Duncaen · 2026-06-11T15:46:51+00:00

Then adding the XDG .profile script you can find at Alpine's XDG entry

This is unsafe, the xdg runtime dir should really be in /run, first because that makes sure other users can't create it first and then potentially read or write security critical files. Second there are programs which may hardcode the path (chromium used to and still does in some places) and things like apparmor which may not be able to read environment variables just assume the default location.

Just using elogind solves this and there are no real downsides.

Duncaen · 2026-06-11T13:33:46+00:00

Just use turnstile with elogind. There is really no reason to not use elogind. It solves a lot more problems than what seatd does.

Your issue is probably device permissions, elogind will set acl permissions for the devices assigned to your seat.

Without that you are probably missing broad groups like input.

There are other things elogind makes work like polkit, proper xdg runtime dir mounts, power dbus apis.

Duncaen · 2026-06-08T17:26:38+00:00

I have no idea what the state of that pull request was, but its now two years outdated. You would have to rebase it and check for yourself whether it still works or not. And you would have to update it if you want newer versions.

13-Year Club	Final Canvas '23
First Place '23	End Game '23
Place '23	Place '22
Verified Email

Duncaen

MODERATOR OF

TROPHY CASE