Debian 8.0 Jessie Gets A Release Date

[FLHerne]

Does this release mean that all major distros are now finally standardized on systemd?

No, Mint will be on Upstart for at least another year, since it's being based off Ubuntu LTS releases.
Presumably Mint 18 will be based off Ubuntu 16.04 and hence get systemd then.

[BSDude]

No, Mint will be on Upstart for at least another year, since it's being based off Ubuntu LTS releases.
Presumably Mint 18 will be based off Ubuntu 16.04 and hence get systemd then.

IMO Mint ain't a _major_ distro plus it's not used anywhere as a serious server distro

[gigaplex]

systemd isn't required

My personal server runs Debian Jessie and still uses sysvinit. They didn't force the systemd upgrade, it's just the default for new installs. It's easy to switch back too.

[Lennie]

IMO Mint ain't a _major_ distro plus it's not used anywhere as a serious server distro

Mint might be a major distro on the desktop/laptop:

http://distrowatch.com/dwres.php?resource=popularity

[Calinou]

Mint might be a major distro on the desktop/laptop:

http://distrowatch.com/dwres.php?resource=popularity

DistroWatch is not a reliable source, it merely counts page hits on distrowatch.com.

[Morpheus]

My personal server runs Debian Jessie and still uses sysvinit. They didn't force the systemd upgrade, it's just the default for new installs. It's easy to switch back too.

That's good to know. I still have to get myself on this service files in case we decide to upgrade the Debian VMs (we usually wait for one year, since we don't run after blleding edge software at all costs). I would be curious to see the difference of booting with SysVinit VS booting with Systemd.

[interested]

grumble.

I've tried to use systemd for servers, I made a test-VM and the first thing I tried with it It completely failed at:

Which is starting up with problems with storage.

If systemd can't find the disks the system is configured with, it will fail to start. OK, this is kind of what you'd expect. But not in the way it does it:
[snip]

There doesn't seem to be any usable single-user mode to fix things either.
[snip]

If disks configured in fstab fail to show up, the system shouldn't boot since that could lead to silent data-loss etc. If the admin don't care whether a particular disk appear at boot time or not, he can mark the disk with "nofail" in fstab. That way systemd will continue the boot even if the disk is missing.

If a fstab disk is missing, systemd will try to give a rescue shell though it may not appear on tty1 if another process is hogging that, so try CTRL+ALT+F2 etc.

In any case, systemd provides many ways to boot into rescue mode, and if using initramfs it is possible to insert boot break points at various stages like adding "rd.shell' to the kernel command line. That way you can fix a missing rootfs from initramfs.

https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_troubleshooting

For systemd you can boot directly into either a rescue shell or a emergency shell.
Add "systemd.unit=rescue.target" or just "1" to the kernel command line. This is more or less the equivalent of "telinit 1" or "single-user mode".
or
Add "systemd.unit=emergency.target" or "emergency" to the kernel command line. This is the one to use if there are fstab problems.

(as a last resort you can boot directly into a shell by adding "init=/bin/sh" to the kernel cmd line.)

More info on system-debugging when using systemd here:

http://freedesktop.org/wiki/Software/systemd/Debugging/

[emerge-e-world]

If systemd can't find the disks the system is configured with, it will fail to start. OK, this is kind of what you'd expect. But not in the way it does it:

I tried a bunch of distros. On one distro it would just wait indefinitely for the missing disk to show up, on an other it would wait 5 minutes or more (it seemed like a really long time to have to sit their waiting) before it gave up and wouldn't continue starting.

Try the "nofail" parameter in your /etc/fstab or the respective .mount-unit file. From the manual:

nofail

With nofail this mount will be only wanted, not required, by local-fs.target or remote-fs.target. This means that the boot will continue even if this mount point is not mounted successfully.

source: http://www.freedesktop.org/software/...emd.mount.html

There doesn't seem to be any usable single-user mode to fix things either.

There is, you can boot into the rescue or emergency target. You may need emergency, as rescue includes local mounts as well. You can do that with the kernel parameter "systemd.unit=emergency.target". See: http://www.freedesktop.org/software/...mand-line.html

[FLHerne]

IMO Mint ain't a _major_ distro plus it's not used anywhere as a serious server distro

It's the second-most-popular personal desktop distro after Ubuntu, per Steam's survey, and third after that and openSUSE per Wikipedia usage (ignoring the meaningless-but-favourable distrowatch stats). That tallies with the significant proportion of users I've seen running Mint.

And no, it's not a server distro. The comment I replied to had nothing to say about server vs desktop. If you need to move the goalposts that much to make your point, you're not making a point.

[Lennie]

If disks configured in fstab fail to show up, the system shouldn't boot since that could lead to silent data-loss etc. If the admin don't care whether a particular disk appear at boot time or not, he can mark the disk with "nofail" in fstab. That way systemd will continue the boot even if the disk is missing.

If a fstab disk is missing, systemd will try to give a rescue shell though it may not appear on tty1 if another process is hogging that, so try CTRL+ALT+F2 etc.

In any case, systemd provides many ways to boot into rescue mode, and if using initramfs it is possible to insert boot break points at various stages like adding "rd.shell' to the kernel command line. That way you can fix a missing rootfs from initramfs.

https://www.kernel.org/pub/linux/utils/boot/dracut/dracut.html#_troubleshooting

For systemd you can boot directly into either a rescue shell or a emergency shell.
Add "systemd.unit=rescue.target" or just "1" to the kernel command line. This is more or less the equivalent of "telinit 1" or "single-user mode".
or
Add "systemd.unit=emergency.target" or "emergency" to the kernel command line. This is the one to use if there are fstab problems.

(as a last resort you can boot directly into a shell by adding "init=/bin/sh" to the kernel cmd line.)

More info on system-debugging when using systemd here:
http://freedesktop.org/wiki/Software/systemd/Debugging/

Thanks I'll give it a try.

I did not find that documentation at the time.

Also I could be wrong, but I don't think not all distributions that use systemd use dracut as well.

What I was doing is:

You have a 2-disk system with btrfs in RAID1 and grub on both disks so you can boot from both, you remove one disk. systemd would just keep looking for that disk.

Normally without systemd: with btrfs has a bunch of options which you can specify on the kernel commandline and then the system can boot in a degraded mode.

It seemed to be these options aren't being passed down to btrfs when mounting.

fstab in this case would only have one entry, in the normal case you'd want to system to boot normally. So fstab should remain normal, you'd want to know if something is wrong.

I couldn't fix any of the problems I had with the rescue shell.

This is the reason why I choose not to use systemd in production on servers yet, clearly I don't know enough about systemd yet to be able to use it in production.

You shouldn't run something in production you don't understand.

I should have been more clear: this doesn't have to be a systemd problem, this could just be me or a documentation problem.