Joey Hess Resigns From Debian, Unhappy With How It's Changed

[Ardje]

I am a long time Debian user, 10+ years now. I hate systemd. Yes, I can see the appeal, having pretty multicoloured dmesg trace logs. But what I don't like about it is this:
After upgrading to OSX Yosemite. My Boot bombed out into a single user mode under the new systemd startup process. Upon debugging/troubleshooting I determined it was because (and I am not making this up) OSX's partition failed to mount and it was listed in /etc/fstab. Now explain to me, why the fuck an incorrect fstab entry that is NOT the ROOT / filesystem, and not related to /bin or /sbin etc, why the hell that should cause a system to be unbootable? That's like nuking a Windows startup because a USB stick wasn't plugged in. That is a huge step backwards for usability.

I have multiple systems that suddenly hat problems with /etc/fstab. LABEL= doesn't work anymore, /dev/disk/by-label or my LVM did not work. So I installed systemd-shim, and it worked again.
On openwrt I have procd and netd, which seem to work good too :-)

[eplight]

After upgrading to OSX Yosemite. My Boot bombed out into a single user mode under the new systemd startup process. Upon debugging/troubleshooting I determined it was because (and I am not making this up) OSX's partition failed to mount and it was listed in /etc/fstab. Now explain to me, why the fuck an incorrect fstab entry that is NOT the ROOT / filesystem, and not related to /bin or /sbin etc, why the hell that should cause a system to be unbootable? That's like nuking a Windows startup because a USB stick wasn't plugged in. That is a huge step backwards for usability.

If you had bothered to check documentation you would know that this behavior can be changed (http://www.freedesktop.org/software/...nt.html#nofail).

But I suppose this is way too much to expect from a hater.

[Gusar]

having pretty multicoloured dmesg trace logs.

Multicolored dmesg has absolutely *nothing* to do with systemd. It's a feature of dmesg, which is part of the util-linux package, which isn't even maintained in the systemd repository, util-linux an entirely different project.

why the fuck an incorrect fstab entry that is NOT the ROOT / filesystem, and not related to /bin or /sbin etc, why the hell that should cause a system to be unbootable?

Every fstab entry that doesn't have nofail in its options is considered by systemd to be critical for boot. Once you understand that, it's a neat feature - instead of the boot process waiting for all filesystems to get fsck'd, booting can continue as soon as the critical filesystems are checked, the non-critical ones can be checked in parallel with the rest of the boot-up. You can also tell the system to not check a particular filesystem, that's what the last number in fstab does (0 means don't check).

Basically, you went on a rant over something that's configurable behavior. Next time, please try to inform yourself better before slamming away. Rants like yours are part of the reason anti-systemd people aren't taken very seriously.

what is your problem ?
did any one of those two people even mention Ian or systemd ?
why are you shoehorning your belief that everyone should blindly accept systemd into everything ?

what is your problem ?
did interested mention everyone should blindly accept systemd ?

Not to mention Joey Hess *did* mention Ian: https://lists.debian.org/debian-ctte.../msg00048.html <- That post, in combination with Joey's other posts, leaves little to the imagination, interested is fully correct, Joey did leave because of Ian's political games.

[valeriodean]

I am a long time Debian user, 10+ years now. I hate systemd. Yes, I can see the appeal, having pretty multicoloured dmesg trace logs. But what I don't like about it is this:

After upgrading to OSX Yosemite. My Boot bombed out into a single user mode under the new systemd startup process. Upon debugging/troubleshooting I determined it was because (and I am not making this up) OSX's partition failed to mount and it was listed in /etc/fstab. Now explain to me, why the fuck an incorrect fstab entry that is NOT the ROOT / filesystem, and not related to /bin or /sbin etc, why the hell that should cause a system to be unbootable? That's like nuking a Windows startup because a USB stick wasn't plugged in. That is a huge step backwards for usability.

I saw that question answered several times and, trust me, I'm far from to be an sysadmin. How can you miss the reasons behind it?
You can find the answer with google, such as this discussion (it's debian, when you say the coincidence!).
You could find interesting also the page systemd.mount
The fstab file generated so far during the installation process doesn't include the "nofail" option, then every filesystem is treated as "important". In such case, if the mount command exit with an error, a good init system must ask for the admin input before to continue the boot.
In the case of systemd, it should drop into the emergency mode, where you can fix your fstab file and then proceed.
This is *simple* the correct behaviour.

[energyman]

It looks like he has a problem with how Debian is steered. He seems to dislike the use of "political bugs" and endless bureaucratic games that especially Ian Jackson likes to play.

Jackson is at the moment making a lot of proposals, and by claiming they are just clarification of the the original systemd ctte decision, he proposes votes that are overriding developer decisions. So in effect he is tricking the ctte to become a top down leadership, which it was never meant to be.

The ctte was meant to only to be involved when developers no longer can agree, but with the latest Ian Jackson proposal and vote:

https://lists.debian.org/debian-ctte/2014/11/msg00003.html

this is no longer the case. Now the ctte is making developer overruling top down decisions without any developer asking for the ctte to interfere, or without any developer disagreement and with almost no voting/discussion period. Ian Jackson's proposal is innocently disguised as a "clarification" of an existing decision in order to circumvent the fact that no developer have asked for such a ctte decision.

Here is what Joey Hess wrote about the above ctte decision:

https://lists.debian.org/debian-ctte/2014/11/msg00045.html

So too much politics involving lots of complicated rules made by people with endless time for creating proposals and play legalese games with a complicated constitution. The end result is that Debian developers are being top down steered by a certain faction of political game shysters.

Expect an endless amount of "political bugs" planted in the Debian bug tracker, that will allow Ian Jackson and his party to harass Debian developers, hitting them in the head with a barrage of his "proposals" and ctte decisions. His GR proposal is the ultimate top down steering tool to force Debian developers to do what he demands. Really not fun for voluntary developers to be ordered around and do things they may not believe in.

(edit: wrong citation)

reminds me of the bad old days in gentoo land, when Ciaranm and his posse found some loop hole, exploited it than, if somebody else used it to or asked if that was the right thing to do made a fuss about it, until some new rules were created covering that hole. And so on and so forth. Gaming the system, forcing everybody and everyone to come up with new rules and regulation and than being adamant that everybody follows the whole mess. While looking for the next hole...

Sickening.

[gerddie]

Every fstab entry that doesn't have nofail in its options is considered by systemd to be critical for boot.
[...]
Basically, you went on a rant over something that's configurable behavior.

That's nice and shiny, the problem is, so far "nofail" meant "Do not report errors for this device if it does not exist." and if it was not set an error was reported, but unless the missing partition was critical the error was not critical. Making this error critical is where the problem lies, especially, when the system is switched to systemd without a big warning message (which happened to me on testing some time ago). I didn't even get a root shell, I had to reboot from a secondary Linux installation to fix the problem. Well, it was in testing, so I added my comment to the corresponding, already existing bug report and moved on, but happy I was not.

IMHO instead of relying on an existing flag "nofail" it would have been a good idea to propose a new mount flag called "critical" that would invoke the behaviour that we now get from a missing "nofail". Old installations would have worked like before, maybe with an additional warning, and new installations could make use of the new feature.

[interested]

That's nice and shiny, the problem is, so far "nofail" meant "Do not report errors for this device if it does not exist." and if it was not set an error was reported, but unless the missing partition was critical the error was not critical. Making this error critical is where the problem lies, especially, when the system is switched to systemd without a big warning message (which happened to me on testing some time ago). I didn't even get a root shell, I had to reboot from a secondary Linux installation to fix the problem. Well, it was in testing, so I added my comment to the corresponding, already existing bug report and moved on, but happy I was not.

IMHO instead of relying on an existing flag "nofail" it would have been a good idea to propose a new mount flag called "critical" that would invoke the behaviour that we now get from a missing "nofail". Old installations would have worked like before, maybe with an additional warning, and new installations could make use of the new feature.

The credo, "if a program have to fail, have it fail early and fail noisily", is actually "Unix Philosophy", see here under the "Rule of Repair". http://en.wikipedia.org/wiki/Unix_philosophy

So systemd is following traditional Unix development here when a mount point in fstab fail to boot, instead of allowing a potentially "silent" data corrupting behaviour like SysVinit distro does.

The "Unix/systemd way" of handling missing disks makes the system much more trustworthy, and makes it easier to spot and repair problems, and, most importantly of all, may prevent that critical data is lost because of disks missing at boot.

Marking some disks "critical" in order to cover up over bad fstab entries seems like a very bad idea, especially since there have been a way to mark non-critical disks for a long time with "no-fail".

Assuming that every disk is critical unless told otherwise seems to be the best overall strategy.

[gens]

what is your problem ?
did interested mention everyone should blindly accept systemd ?

Not to mention Joey Hess *did* mention Ian: https://lists.debian.org/debian-ctte.../msg00048.html <- That post, in combination with Joey's other posts, leaves little to the imagination, interested is fully correct, Joey did leave because of Ian's political games.

yes, Interested did say that
a couple times, before
and he did bring systemd in a topic far from it

do you know Joey ?
did he ever say "Ian made me do it" ?
even if you lined all the msgs where Joey replied to Ian, that wouldn't say shit
might as well be "Russ made me do it"
and he did say that he didn't like the whole political thing in debian ever since it started
since it started, a long time ago

and it's funny how you can call that "obvious",
but having 2-3 people paid by redhat in a debian techical committee is not an obvious conflict of interest
as long as we are making assumptions...

Ian gave over 18 years to the debian project
a lot more then most of the political committee


all in all who are we to say anything about it all
again, let the man leave in peace

[gens]

So systemd is following traditional Unix development here when a mount point in fstab fail to boot, instead of allowing a potentially "silent" data corrupting behaviour like SysVinit distro does.

mount(8) will tell you when something can't be mounted...
it will even be logged...

and if it can't be mounted, it can't be corrupted...

[Gusar]

(a bunch of drivel)

*facepalm*