bind mount in 32bit chroot

Prev		Next

Newsgroups:  gmane.linux.debian.ports.amd64
Date:        Thu, 03 Mar 2005 18:07:23 -0500

> The "bind mount" section in the faq is not clear. I still have things that
> I don't understand.
>
> I understand in the chroot environment, at least the following has to be
> bind mounted:
>
> /home
> /tmp
> proc
>
> The faq then goes on:
>
> ,-----
> | Then mount them:
> |
> | mount /var/chroot/sid-ia32/home
> | mount /var/chroot/sid-ia32/tmp
> | mount /var/chroot/sid-ia32/proc
> `-----
>
> This is not clear. Should I do it in the chroot environment, or out side
> it? If I should do it in the chroot environment, isn't that
>
> "mount /home", etc, much clearer?

You have to do it outside because from inside the chroot you cannot see —the external— /home. Therefore while outside the chroot you bind /home to /var/chroot/sid-ia32/home, as from outside you can see both mount points.

> Q2, how about devices, Shouldn't /dev be bind mounted?

Apparently not, your chroot should have the devices created. I don't know what the reason is though, so if somebody can enlighten us here we would both learn something new :)

> Q4: I have various volumes mounted below /lfs:
>
> /dev/sda13 on /lfs/cache11 type reiserfs (rw)
> /dev/sda14 on /lfs/cache12 type reiserfs (rw)
> /dev/sda15 on /lfs/cache13 type reiserfs (rw)
>
> To access them in 32bit chroot, should I bind-mount only one /lfs, or each
> volume individually?

You need to user "rbind" mounts if you wish to only mount /lfs and get all the submounts as well.

> Both "bind mount" and "chroot" are new to me. Please help.

So are to me. Fortunately they have really fine manpages/documentation.

Disclaimer: I haven't tested the rbind scenario, I'm just reading that part from the mount(8) manpage as I write.

Javier Kohen

bind mount in 32bit chroot

> >Q2, how about devices, Shouldn't /dev be bind mounted?
>
> Apparently not, your chroot should have the devices created. I don't
> know what the reason is though, so if somebody can enlighten us here we
> would both learn something new :)

Several reasons to bind mount /dev:

/dev does not contain only devices (unfortunately) it also contains some named pipe and some named sockets:
```
%ls -l /dev  | grep '^[psd]'
prw-r--r--    1 root     root            0 mar  4 01:18 gpmdata
prw-------    1 root     root            0 jan 21 18:49 initctl
srw-rw-rw-    1 root     root            0 jan 21 18:50 log
prw-r-----    1 root     adm             0 mar  3 13:38 xconsole
```
The named pipes in the chrooted /dev and in the base /dev are unrelated. (You can read on one what is written to the other.) However, you can mount —bind each pipes separatly instead of the whole /dev directory.
For example if you run a 64 bit gpm repeater and a 32 bit Xserver, the Xserver will not be able to read the (non-chroot) /dev/gpmdata. Syslog will be broken in the chroot, etc.
You would have to take care of mounting devpts on both /dev/pts.
The tmpfs filesystems on both /dev/shm are unrelated. You will not be able to use shm for communicating between the chroot and the base.
Some programs can create devices dynamically. In this case you will have to create them manually in the 'other' /dev.
If you run the same debian release in the chroot and outside, using the same /dev will save you the trouble to take care of permissions and symlink, etc.

Bill Allombert

bind mount in 32bit chroot

> > Q2, how about devices, Shouldn't /dev be bind mounted?
> I'm not sure about this, but I think this is processed when creating the
> chroot.

This is true, though I think there are 2 options:

let the debian process create /$CHROOT/dev, then remove any junk you don't need (since it's eating inodes).
let debian create the /$CHROOT/dev. Then, rm -rf /$CHROOT/dev and bind mount to the master /dev so 32-bit processes can, e.g., access USB and other hotplug devices.

Stephen Waters