Hacker News Reader

Comment by int_19h | Hacker News Reader

I see that systemd is still doing this thing where they are trying to strong-arm all Linux distros into arbitrary stuff that someone decided is the only right way to do something:

> 5.2.2. systemd message: System is tainted: unmerged-bin systemd upstream, since version 256, considers systems having separate /usr/bin and /usr/sbin directories noteworthy. At startup systemd emits a message to record this fact: System is tainted: unmerged-bin. It is recommended to ignore this message. Merging these directories manually is unsupported and will break future upgrades. Further details can be found in bug #1085370.

No option to disable this either, per discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370

View on HN

You may not like it, but “arbitrary” isn’t a fair description; there’s reasoning behind it that is over 10 years old:

http://0pointer.net/blog/projects/stateless.html

https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...

That said, my knee-jerk is also that this is about strong-arming distros. Which leaves a bad taste in my mouth. I’d be interested to hear other viewpoints though.

Note that this is about a different thing - Debian has also merged its /bin into /usr/bin, but now systemd also wants /usr/bin and /usr/sbin to be merged.

Oh thanks, I totally missed that distinctions. You’re right.

My first thought is to wonder: why would systemd care about this then? Any idea?

My second thought is: with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin? My understanding is that sbin has historically been useful to have statically linked binaries that can be made available early during boot without needing various lib dirs mounted. But that need seems obviated by a unified /usr…

> with a merged /usr, where /usr/{bin,sbin} are on the same filesystem, what’s the benefit of even having a distinct sbin?

There really isn't any, the sysmlink being for compat. Early boot is nowadays taken over by an initrd/initramfs. Some say what you say sbin was for were actually the root /bin (early boot) and /usr/bin (elsewhere) but it was all just so arbitrary and no-one could actually agree on what is for what actually.

Some say sbin is for static binaries, others for superuser binaries and either destinction really doesn't make sense nowadays as earlyboot is initrd and a lot of "superuser binaries" actually also are fine to use unprivlidged in certain scenarios (e.g. `mkfs.*` for making disk images) so having them in a separate dir is just arbitrary (e.g. `cat` can also fail if I cat the shadow file).

sbin is for binaries intended for the superuser, so it is only in the PATH for root, but not for anyone else. This is useful as it doesn't bloat the completions with stuff I never care to run anyways.

>No option to disable this either, per discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370

The discussion in that bug is that the Debian maintainer (and upstream dev) is open to an upstream patch to add such an option.

> Debian maintainer (and upstream dev) is open to an upstream patch to add such an option

Wild interpretation right here.

There are only 2 realistic choices: Leave it as is or patch out the warning message in the Debian package

Debian maintainer is clearly deflecting the responsibility here because everyone knows very well that upstream wouldn't accept such a patch.

As it's already explained in the bug report, since Debian has no plan to do that migration in the near future, aforementioned warning isn't only useless and annoying, it's also potentially harmful, thus the correct action would be to remove it downstream like they did it in xscreensaver (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84)

But then they'd face the wrath of Lennart, so the only choice left is ignoring the report.

Perhaps we need to have a concept of separation of upstream and distros.

Why do you think this is an attempt at a persuasion tactic? Taint flags in this context just means something that might be relevant to debugging. Which this condition might be, if people in the future are unfamiliar with a potentially anachronistic split between /usr/bin and /usr/sbin. The debug message isn't there to judge the morality of your configuration. It's actively improving your ability to continue to support both ways, by properly indicating what style of system it is for troubleshooting purposes.

> Why do you think this is an attempt at a persuasion tactic

Because they said so:

> As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration [1]

1. https://0pointer.de/blog/projects/the-biggest-myths.html

This was written 11 years before that debug log was added. Extremely loose connection. Things do actually change over the course of 11 years, believe it or not.

It's their modus operandi and it haven't changed, believe or not.

> it is definitely our intention to gently push the distributions in the same direction so that they stop supporting deviating solutions for these things where there's really no point at all in doing so. [1]

> Distros may deviate from this by patching this downstream, but by shipping this as secure default I do hope to gently push everybody in the same direction.

> start pushing people gently to define GPT partition type UUIDs for missing archs > Let's generate a single gcc `#warning` message asking people to define partition type UUIDs for their architectures if they are missing. [3]

[1] https://lists.freedesktop.org/archives/systemd-devel/2010-Se...

[2] https://lists.freedesktop.org/archives/systemd-devel/2011-Ma...

[3] https://github.com/systemd/systemd/commit/d42e4fa258701ff5e0...

How and why is this relevant to debugging?

Also, like it or not, the word "tainted" bears a negative connotation. It's hard to imagine that it was chosen arbitrarily.

Lovely.

Debian choosing systemd (not that it's a new decision) is the reason I'll be switching my Proxmox to FreeBSD/bhyve (FreeBSD has great ZFS support btw).

Once I get the hypervisor systemd-free (no systemd on FreeBSD), I can then install a minimal distro in a VM mean to do containerization (like, say, the Talos Linux distro for K8s, that only has a few executables and they're all immutable) and then I can run containers that, by design, have something that is precisely not systemd as PID1.

So life is good: there's a systemd-free world at the end of the tunnel.

> Debian choosing systemd (not that it's a new decision) is the reason I'll be switching my Proxmox to FreeBSD/bhyve

Did you consider Devuan? Or is this just taking one annoyance as motivation to fix others at the same time?

Reply on news.ycombinator.com