Bug#792882: machinectl fails to login to container

[Ben Longbons]

I ran into this, and everything works now after upgrading all systemd
packages to 226-2 and rebooting.

Note that this bug is *completely* unrelated to having dbus installed
in the container or having /dev/pts/0 in /etc/securetty, it happens
before that is relevant.

Note that systemd-container does not have a versioned `Depends:` on
systemd, and `systemd` does not have a versioned `Suggests:` on
systemd-container (if that even makes sense). I have not tested what
happens when they are not upgraded in lockstep.

With 225-1:

* systemd-nspawn -b provides a login prompt (on /dev/console).
* If container is started with systemd-nspawn -b, machinectl login
fails (tries to use hosts's /dev/pts/0 instead of container's).
* If container is started with machinectl start, machinectl login
fails (tries to use hosts's /dev/pts/0 instead of container's).
* If container is started with systemctl start, machinectl login fails
(tries to use hosts's /dev/pts/0 instead of container's).

With 226-2:

* systemd-nspawn -b provides a login prompt (on /dev/console).
* If container is started with systemd-nspawn -b, machinectl login
fails (tries to use hosts's /dev/pts/0 instead of container's).
* If container is started with machinectl start, machinectl login
fails (tries to use hosts's /dev/pts/0 instead of container's).
* If container is started with systemctl start, machinectl login fails
(tries to use hosts's /dev/pts/0 instead of container's).

Note that `machinectl shell` has the same results as `machinectl
login` in the cases I have tested, which is not all of them.

Note that the error message differed depending on whether /dev/pts/0
existed on the host or not. If you are running KDE, it usually appears
graphically (to catch wall(1) notifications).