Bug 86555

Summary: systemd-nspawn resolves symlinks of COMMAND on host, not in container
Product: systemd Reporter: Moritz Bunkus <moritz>
Component: generalAssignee: systemd-bugs
Status: RESOLVED MOVED QA Contact: systemd-bugs
Severity: minor    
Priority: medium CC: peter.hutterer
Version: unspecified   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Moritz Bunkus 2014-11-22 07:49:14 UTC
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.
Comment 1 Lennart Poettering 2015-10-06 10:54:50 UTC
Somebody posted this on github too. While we generally don't move bug reports I figure we can keep the one on github open and close this one.

https://github.com/systemd/systemd/issues/1400

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.