04.11.2016 18:14, Marc Haber пишет:
> On Thu, Nov 03, 2016 at 10:55:35PM +0100, Lennart Poettering wrote:
>> On Mon, 26.09.16 07:02, Marc Haber (mh+systemd-de...@zugschlus.de) wrote:
>>> On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
>>>> The emergency mode assumes console access, which requires physical access,
>>>> which is quiet difficult if the machine is remote.
>>> It does also assume knowledge of the root password, which is in
>>> enterprise environments not often the case. Enterprises usually have
>>> root passwords stowed away in a safe, behind a three-headed guard dog,
>>> requiring management approval, and > 2 eyes mechanisms, and usually
>>> have password-changing processes attached that touch other machines
>>> sharign the same root password as well (for example because the root
>>> password hash is stamped into the golden image).
>>> Many enterprise environments that I know have their processes geared
>>> in a way that the root password is not needed in daily operation.
>>> Login via ssh key, privilege escalation via sudo.
>>> systemd requiring the root password because some tertiary file system
>>> doesn't mount is a nuisance for those environments.
>>> Some sites have resorted to adding "nofail" to all fstab lines just to
>>> find themselves with the next issue since the initramfs of some
>>> distributions doesn't know this option yet. 
>> "nofail" has been around as long as fstab has been around really. It's
>> not a systemd invention.
> I cannot say anything about that, I don't have any non-systemd
> machines left. However, that machines stop booting and require the
> root password is a totally new experience for me that came with systemd.

You mix two different things.

1. The behavior that if filesystem from /etc/fstab fails to mount, boot
is stopped and administrator intervention is required existed long
before systemd.

2. Password is requested not by systemd, but by command that it starts
to present shell. Default is sulogin. You are free to override it with
anything you want, including /bin/sh. Again, sulogin was often default
in this case before systemd as well.
systemd-devel mailing list

Reply via email to