About the Devuan excision [LWN.net]

About the Devuan excision

Posted Jul 1, 2026 3:08 UTC (Wed) by pizza (subscriber, #46)
In reply to: About the Devuan excision by Cyberax
Parent article: Xsnow "protestware" in Debian

> In particular, my breakage was caused by a unit (systemd-update-done.service) that starts _once_ on boot after a system upgrade (I bet you didn't know it exists?). It's a fine idea, except that it has DIFFERENT dependencies compared with a normal boot.

Is that a "systemd" bug, or that your particular distro's "system upgrade" flow/tooling doesn't correctly declare its dependencies ? Either way it appears to be trivially fixable by adding a local drop-in that that overrides the "After=local-fs.target" with "After=network.target" .

(I mean, an init script that a distro upgrade sets up to run only once after a system upgrade would break the same way for similar dependency issues. Or more likely, fail silently leaving things in a [not-so-]subtly incorrect state afterwards)

to post comments

About the Devuan excision

Posted Jul 1, 2026 4:05 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

It's a systemd bug, as it's a part of the default systemd installation. The distro is Fedora, btw.

> (I mean, an init script that a distro upgrade sets up to run only once after a system upgrade would break the same way for similar dependency issues. Or more likely, fail silently leaving things in a [not-so-]subtly incorrect state afterwards)

Probably. Or maybe not. The issue here is that systemd is a huge mess at the moment. It seems to do _everything_, but it does almost nothing completely right.

The core process supervision and journaling are OK. Everything around it is not. Mount units are a particular disaster area. I dare anyone to say that THIS is acceptable: https://github.com/systemd/systemd/blob/ee9a70ccc7a35b224...

About the Devuan excision

Posted Jul 1, 2026 14:32 UTC (Wed) by pizza (subscriber, #46) [Link]

> Mount units are a particular disaster area.

If mount units are a "disaster area" then the previous status quo mudball (static /etc/fstab + autofs + bespoke distro scripts that keeled over when you stray off the beaten path and/or something inevitably went wrong, no meaningful dependency tracking vs the filesystem(s) being online/accessible, etc) was an extinction-level-event asteroid impact.

Is it perfect? far from it. But it's still a *huge* net improvement.

About the Devuan excision

Posted Jul 2, 2026 8:17 UTC (Thu) by intelfx (subscriber, #130118) [Link] (1 responses)

> The issue here is that systemd is a huge mess at the moment. It seems to do _everything_, but it does almost nothing completely right.

It does most of the things pretty much right. People used to split hairs over "completely" since computing happened, and will do so for the foreseeable future.

> The core process supervision and journaling are OK. Everything around it is not. Mount units are a particular disaster area. Mount units are a particular disaster area. I dare anyone to say that THIS is acceptable: https://github.com/systemd/systemd/blob/ee9a70ccc7a35b224...

You are sensationalizing. If that's the worst you have, I'd say we are in pretty damn good place.

This is not an article about systemd

Posted Jul 2, 2026 18:49 UTC (Thu) by corbet (editor, #1) [Link]

I think that the systemd wars, beyond having been mostly settled years ago, are somewhat off-topic here. Let's not relitigate that one yet again.

About the Devuan excision

Posted Jul 1, 2026 4:06 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> Either way it appears to be trivially fixable by adding a local drop-in that that overrides the "After=local-fs.target" with "After=network.target" .

Well, yeah. I fixed it this way. After struggling to debug the issue that happened once in a while for an unknown reason.

About the Devuan excision

Posted Jul 1, 2026 5:31 UTC (Wed) by zdzichu (subscriber, #17118) [Link] (4 responses)

Easier to put "_netdev" in the fstab where the iSCSI volumes are mounted. Either way, a configuration bug, not a systemd one. And not Xsnow related.

About the Devuan excision

Posted Jul 1, 2026 5:39 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

fstab? Are you a caveman? You're supposed to use mount units: https://www.freedesktop.org/software/systemd/man/latest/s... And I don't believe that they support _netdev override.

Which is ironic, because /etc/fstab generator supports them.

About the Devuan excision

Posted Jul 1, 2026 6:24 UTC (Wed) by mb (subscriber, #50428) [Link]

>In general, configuring mount points through /etc/fstab is the preferred approach to manage mounts for humans.

About the Devuan excision

Posted Jul 1, 2026 9:23 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

If you're writing a mount unit, you can add the appropriate dependencies yourself; systemd-fstab-generator uses _netdev to choose a different set of After and WantedBy directives, nothing more.

About the Devuan excision

Posted Jul 1, 2026 20:18 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Not quite. systemd also has special treatment of mount units for shutdown and for containers. It's a minor thing, true, but it also reinforces my point. There are too many moving pieces in systemd that can have unexpected side-effects.

I'm not a systemd hater, and I absolutely LOVE not having to cargo-cult /etc/init.d scripts.

But I'm not at all positive about systemd's ability to carry out its stated goal: building a coherent low-level infrastructure layer. The same pattern keeps repeating again and again: systemd adds some component in an MVP fashion and then gives up on making it fit with the rest of the system before moving on to the next shiny thing. And/or takes shortcuts that shouldn't be taken.