Bug#374713: [Buildd-tools-devel] Bug#374713: Aborts if cd fails but seems to use pwd -P

[Roger Leigh]

Christian Hammers <ch at debian.org> writes:

> dchroot stopped working for me. I tried schroot but it complains about
> the same:
>
>   $ pwd   
>   /home/ch
>
>   $ pwd -P
>   /mnt/local/home/ch
>
>   $ dchroot pwd
>   E: Could not chdir to '/mnt/local/home/ch': No such file or directory
>   E: Session failure: Child exited abnormally with status '1'

They are working as expected.  There is a good rationale for this
behaviour.  I'll try to explain why, and hopefully it will make sense
:)

The first thing is pwd.  I'm assuming here that /home/ch is a symlink
to /mnt/local/home/ch, or /home is a symlink to /mnt/local/home.  When
schroot runs, it can only rely on the path as obtained with getcwd(3).
This returns the real path, without any symlinks.  The shell also has
a virtual path, without the symlinks expanded, but this isn't
available to us.  So there is no way of us ever knowing you /really/
wanted to be in /home/ch, when the system tells us you are actually in
/mnt/local/home/ch.

When dchroot/schroot run, there are two ways of running it:

1) Without a command; a login shell is executed instead
2) With a command

When a shell is run (i.e. it's going to be interactive), it tries to
place you in the same directory /inside/ the chroot as you were on the
outside.  It tries, in turn:

- the current working directory
- $HOME
- passwd pw_dir
- /

Because it's interactive, if it fails the user will see e.g. in the
shell prompt, and we also warn about it:

rleigh at hardknott:/usr/local/etc/schroot$ schroot -c sid
W: Could not chdir to ¡Æ/usr/local/etc/schroot¡Ç: No such file or directory
W: Falling back to home directory ¡Æ/home/rleigh¡Ç
I: [sid chroot] Running login shell: ¡È/bin/bash¡É

When the user specified a command, the situation is rather different.
We want the behaviour to be deterministic and safe.  So (crude
example, to make the point)

$ dchroot -c unstable -- rm -f foo/bar

will cause a lot of trouble if it runs in $HOME or / because the
current working directory wasn't available inside the chroot.  That's
an extreme case, but undesirable (and unpredicatable) things could
happen if the user can't *rely* on the behaviour inside the chroot
being consistent.  Being consistent means we have to bail out if the
current working directory isn't there.

This would only affect commands that use files, but there's no way we
can predict what any given command will do, so we have to err on the
side of caution.

To work around this, you can

- make sure you are in a suitable directory, like / or ~, before
  running dchroot.
- use bindmounts to avoid the symlinks.

> I have just "/home/ch" as homedir in /etc/passwd and although it is
> mounted on a different partition in the host system, this should not
> affect the chroot. The /home/ch inside the chroot is created via the
> folling /etc/fstab entry on the host system:
>   /home/ch  /mnt/local/chroot_sid_i386/home/ch   none defaults,bind   0 0
>
>
> Any ideas how to get [sd]chroot working again?

I would suggest trying the bindmount suggestion above first.


Regards,
Roger

-- 
Roger Leigh
                Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20060621/a0d70c7a/attachment.pgp