Beta Released Of Devuan, The Systemd-Free Version Of Debian

[DebianLinuxero]

I have an issue I'm not sure it's Debian's config or SystemD's fault :

On startup, when a proccess takes more than 7 minutes, SystemD automatically closes it.

The times I boot that fsck forces itself to check the data partition due to the 30 mount times thing, as the partition itself it's large, it tooks more than 7 minutes.
Which means SystemD closes fsck without ending the check. Which means fsck tries to check the partition at the next boot because the previous check was incompleted. Which means the proccess repeats again on every boot.

I break this cycle by booting in Sysvinit mode and leave fsck do its job without interruption.

[microcode]

I still think SystemD is shit. It's become less shit than it was, but it's still shit. Here's the simplest way to fuck it up: create an NTFS partition, set it to auto in /etc/fstab, delete ntfs-3g, reboot, have a total fuck up. No, systemd won't say "I cannot mount /dev/blabla to /mnt/somewhere because necessary files might be missing", it will say something like "Bus error 801". WTF???? Really?! It's the best they can do?!

Don't take my words for granted, go check Fedora 23/24-alpha which contain basically a pure systemd implementation.

If you remove your filesystem driver, it cannot mount the filesystem. If it can't mount the filesystem, should it let other processes clobber the mountpoint? The mountpoint will be there as a directory. When you do repair ntfs-3g, you'll be left with a mountpoint which you cannot mount. It seems to me that the only sane way to proceed is to halt the boot process and display an error.

Considering that you can boot your recovery volume and resolve this with any reasonable system; I don't see why you would want the default behaviour to clobber your mountpoint and make it unmountable in the future.

[birdie]

If you remove your filesystem driver, it cannot mount the filesystem. If it can't mount the filesystem, should it let other processes clobber the mountpoint? The mountpoint will be there as a directory. When you do repair ntfs-3g, you'll be left with a mountpoint which you cannot mount. It seems to me that the only sane way to proceed is to halt the boot process and display an error.

Considering that you can boot your recovery volume and resolve this with any reasonable system; I don't see why you would want the default behaviour to clobber your mountpoint and make it unmountable in the future.

WTF are you talking about? My gripe is about the meaningless stupid uninformative error message that systemd is spewing at the user. You're discussing God knows what with God knows whom but certainly you're not replying to my original message.

Besides, one other major thing I've forgotten: upstart/sysVinit bail out by showing "cannot mount /dev/blabla" and then they boot you into runlevel 1 where you can at least try to fix the problem.

SystemD on the other hand stops booting altogether without giving me any options. Nothing. A stupid error message and nothing else. WTF am I supposed to do?

SystemD has been in development for 7 years, already, right? Then why is it so freakingly unusable? I have a gut feeling systemd will soon start copying Microsoft's error codes. Something like: "System cannot boot because of error 0x00001234". IOW, go fuck yourself and google for this error code God knows where.

[Krejzi]

Firstly, the error is exactly from systemd, secondly, in-kernel NTFS driver is not even built - I stopped using it circa 7 years ago.

So, the ntfs kernel driver isn't there and ntfs-3g is gone? Tell me again, how exactly can you mount a filesystem that can't be mounted and expect nothing to complain?

[phrx_reader]

it's about fragmentation and useless work

No It's not. It is really about init freedom. Debian does not provide init-freedom any longer. They are too heavy into the systemd dependencies. Therefore Devuan exists, and with Devuan you can use the init system of your choice, like sysvinit-core, openrc, s6, runit, etc. Devuan does not claim that sysvinit is the best choice, even if it is default right now, so stop nagging about that. And, if you want systemd you just stay with Debian, don't switch to Devuan. Understood? Add to that the issues of systemd-* features that worked perfectly in the *nix world for years, why provide this unless you wan to lock your user into the vendor dependency, like M$. Don't you think RH has an agenda (they are just hiding it behind the GPL (2, not 2+ or 3+) license, try to make modifications of that code monster, good luck).

[stqn]

Great news. Maybe I will be able to recommend Linux again to people (as recommending Gentoo isn’t really an option most of the time).

[Krejzi]

I have an issue I'm not sure it's Debian's config or SystemD's fault :

On startup, when a proccess takes more than 7 minutes, SystemD automatically closes it.

The times I boot that fsck forces itself to check the data partition due to the 30 mount times thing, as the partition itself it's large, it tooks more than 7 minutes.
Which means SystemD closes fsck without ending the check. Which means fsck tries to check the partition at the next boot because the previous check was incompleted. Which means the proccess repeats again on every boot.

I break this cycle by booting in Sysvinit mode and leave fsck do its job without interruption.

Ugh, that's a bummer. systemd will terminate any process which it has invoked, but hasn't finished settling (forked or otherwise notified systemd about finished startup) in 90 seconds. This is definitely a systemd issue and it's one that requires raising upstream attention.

[pjezek]

For them, who do not like use systemd, this is by design a very good alternative. Nothing less, nothing more. Any other comments are about nothing when users are not capable configurate their OS'.

[birdie]

So, the ntfs kernel driver isn't there and ntfs-3g is gone? Tell me again, how exactly can you mount a filesystem that can't be mounted and expect nothing to complain?

Are you a complete and utter retard? I perfectly know systemd cannot mount the partition but instead of plainly reporting it by saying "Cannot mount something to somewhere, system halted" it shows go-fucking-break-your-head message.

[Krejzi]

Are you a complete and utter retard? I perfectly know systemd cannot mount the partition but instead of plainly reporting it by saying "Cannot mount something to somewhere, system halted" it shows go-fucking-break-your-head message.

Ever considered that nobody run into similar issue yet to notify the devs that they should handle the error you mentioned in the error handler? Lots of software doesn't always handle corner cases correctly, and it wouldn't be able to do it at all if it wasn't for input from users.

Instead of complaining here, I suggest you take your issue upstream, let them know they don't handle a certain error and ask them to make whatever is responsible for mounting partitions from fstab at boot kindly tell you that you are an idiot for trying to mount a filesystem that can't be mounted (or whatever would make it more clear to you, as you complain the current one isn't clear at all).