5 and 6 sounds like good candidates for a bug reports/PR, if there's not already some "right" way to do it.

They're already reported. And ignored. Have you _seen_ the systemd issue backlog?

The iSCSI loop issue: https://github.com/systemd/systemd/issues/34164 It keeps popping up again and again and is summarily ignored.

The remote FS detection also came up multiple times, and the maintainers don't care.

▲

nomel 3 hours ago | parent [-]

> and the maintainers don't care.

I'm not sure that's fair. I think better proof of this would be a rejected PR rather than a neglected bug report.

This is Linux, after all. Problems found with specific hardware are almost always solved by people with that hardware, not the maintainers, who are usually busy with the 99%.

	▲	cyberax 2 hours ago \| parent [-]
		The problem here is more fundamental. Lennart refused to make all the /etc/fstab options available in regular mount units. And yes, there was an issue, no I'm too tired to look for it. The wording was pretty much: "Give up, and gtfo, this is not going to happen. Just because." I'm convinced that systemd can't be fixed by its current team of maintainers. They are just... untidy. I don't know about you, but if I end up writing low-level code that _needs_ to know whether the mounted file system is "remote", I won't do that by comparing against a hard-coded list of filesystems inside PID0. Or by using wild heuristics ("if it's on a block device, then it's local"). I would put these heuristics in a helper tool that populates the default values for mount units. Then allow users to override them as needed. With a separate inspector tool to flag possible loops.