Systemd 217 Updated In Debian & Soon Making Its Way To Ubuntu 15.04

[KellyClowers]

That is not an issue with systemd but an issue with a failed disk.

Would you rather systemd tried to boot from failed drives and screw any hope of data recovery?

Don't be absurd.

The disk was gone - needed to replace its board. But when systemd couldn't find /dev/sdc or LABEL=DATA whatever it was listed as to mount to /data, it would fail to boot entirely. Had to use a livecd and change fstab, then it could boot.

[Ericg]

Don't be absurd.

The disk was gone - needed to replace its board. But when systemd couldn't find /dev/sdc or LABEL=DATA whatever it was listed as to mount to /data, it would fail to boot entirely. Had to use a livecd and change fstab, then it could boot.

Isn't that what the spec (or at leas the general understanding thus creating an implied spec) says to do? INIT should fail to boot if any drive not marked with nofail refuses to mount / is not mounted successfully. Hence the nofail option, it tells the kernel / init that the device is not important and/or may not be available at all times.

[KellyClowers]

Isn't that what the spec (or at leas the general understanding thus creating an implied spec) says to do? INIT should fail to boot if any drive not marked with nofail refuses to mount / is not mounted successfully. Hence the nofail option, it tells the kernel / init that the device is not important and/or may not be available at all times.

Well, it certainly didn't happen when I was using SysV init. It would give an error, but it booted fine.

And the man page says "nofail do not report errors for this device if it does not exist". Nothing about those errors stopping the boot.

[Gusar]

Well, it certainly didn't happen when I was using SysV init.

That's a failure of sysvinit and/or the scripts a distro used on top of sysvinit. Or if failure is too strong a word for you, see it as difference of implementation. systemd is not "bad" or whatever because it behaves this way, it's just different. More strict in its interpretation of the nofail option.

I remember a very similar thing when Arch switched over to systemd - there were quite a few posts on the forums the likes of "I ran halt and my system didn't shut down! What's wrong?". And the answer is, nothing is wrong, the system did exactly what it was told, it halted. To shut it down, the correct command is poweroff. That the system didn't behave as these people expected isn't something that's wrong with systemd, it was a shortcoming of the old Arch init scripts that they didn't differentiate between halt and poweroff.

[KellyClowers]

That's a failure of sysvinit and/or the scripts a distro used on top of sysvinit. Or if failure is too strong a word for you, see it as difference of implementation. systemd is not "bad" or whatever because it behaves this way, it's just different. More strict in its interpretation of the nofail option.

I remember a very similar thing when Arch switched over to systemd - there were quite a few posts on the forums the likes of "I ran halt and my system didn't shut down! What's wrong?". And the answer is, nothing is wrong, the system did exactly what it was told, it halted. To shut it down, the correct command is poweroff. That the system didn't behave as these people expected isn't something that's wrong with systemd, it was a shortcoming of the old Arch init scripts that they didn't differentiate between halt and poweroff.

Hm, I would say difference in implementation. I certainly don't think systemd is bad because of it! And I can see the use of stopping if a FS doesn't exist; in some cases it could be very useful. This was just my home machine, so whatever. I personally would argue for a situation where the default to continue, but throw errors, and have an option to not throw errors, and another option for the opposite, where it would stop altogether. But they didn't go that way, that is ok. I didn't read up enough ahead time to catch it. *shrug*

In general systemd is great. I start on the CLI and run startx, before everything was in shell start up scripts and xinitrc, now I have moved everything over to systemd user units, with levels for CLI and X. It's pretty great.

Thought I do still have to sort out a little issue with systemd-user/logind/pam/gnome-keyring. But for now it just means I have to enter my password one extra time.

[MoonMoon]

I personally would argue for a situation where the default to continue, but throw errors, and have an option to not throw errors, and another option for the opposite, where it would stop altogether. But they didn't go that way, that is ok. I didn't read up enough ahead time to catch it. *shrug*

For now the default is to wait for a filesystem until a timeout is reached and then to boot into an emergency console. I am not at my machines currently to test that, but from what I read that timeout is pretty long (5 minutes?), though the documentation describes an option to specify the length of the timeout.

[KellyClowers]

For now the default is to wait for a filesystem until a timeout is reached and then to boot into an emergency console. I am not at my machines currently to test that, but from what I read that timeout is pretty long (5 minutes?), though the documentation describes an option to specify the length of the timeout.

That seems reasonable. This was a bit of an older version... I don't recall for sure, but I think I left it for like 15+ minutes and it didn't go anywhere. And I tried the Debian default "rescue" grub entry, but it didn't work.. possibly it was not using the right options for systemd rescue? Still once I looked it up on my other system, it was easy enough to live boot a cd and change fstab.

I should test it now, see how it goes...

[MoonMoon]

That seems reasonable. This was a bit of an older version... I don't recall for sure, but I think I left it for like 15+ minutes and it didn't go anywhere. And I tried the Debian default "rescue" grub entry, but it didn't work.. possibly it was not using the right options for systemd rescue? Still once I looked it up on my other system, it was easy enough to live boot a cd and change fstab.

I should test it now, see how it goes...

The correct option is "systemd.unit=rescue.target". Alternatively you can just use the option "1", like you could do with most sysvinit based distros.

[KellyClowers]

The correct option is "systemd.unit=rescue.target". Alternatively you can just use the option "1", like you could do with most sysvinit based distros.

Debian uses "single", same diff. Tried it just now, with disk disconnected and without "nofail" it waited 1 minute 30 seconds and then went to single user mode, where I was able to set it back to nofail. With nofail on, it boots to "runlevel 2" immediately. So that works as intended now.

[GizmoChicken]

When is soon?

Sorry if I missed this, but... The article mentions that systemd will "soon" be making its way to Ubuntu 15.04. Anyone know (and willing to share) what is meant by "soon" as mentioned in the article? That is, are we talking days, weeks or months before systemd is the default in daily versions of Ubuntu 15.04? I ask because I'm itching to give 15.04 a try, but I'd rather wait until 15.04 is default before intalling it.