I have several Linux distros located in directories into which I used to chroot in order to build packages. Now I'm trying to use systemd-nspawn for that. In order to run the shell I want to work with (zsh) I used to execute /bin/zsh with chroot. The corresponding call to systemd-nspawn fails with a Debian tree though because /bin/zsh is a symlink to /etc/alternatives/zsh which in turn in a symlink to /bin/zsh4.

systemd-nspawn seems to resolve this symlink before it sets up the container and complains if the binary is not found:

[0 mosu@sweet-chili /opt/linux] sudo systemd-nspawn --directory=/opt/linux/64/debian/wheezy --bind=/home/mosu --bind=/proc --bind=/sys --bind=/dev /bin/zsh
Directory /opt/linux/64/debian/wheezy lacks the binary to execute or doesn't look like a binary tree. Refusing.
[1 mosu@sweet-chili /opt/linux]

My host system is not a Debian machine, therefore it doesn't have the alternatives symlink system set up at all. So when the host resolves the symlink /bin/zsh it doesn't find /etc/alternatives/zsh and errors.

This works nicely with chroot as chroot as chroot either doesn't try to resolve the symlink before chrooting or it does relative to the chroot.

I can work around this issue with special-casing my scripts to execute /bin/zsh4 on Debian instead of /bin/zsh, but I still consider this a bug in systemd-nspawn because the shell is not the only thing on a Debian system that uses the alternatives system with absolute links.