Development Team/Chroot: Difference between revisions
New page: Sugar ought to be easy to run from chroots. For a variety of silly reasons, this isn't yet the case, but it might be soon. Ping Michael with questions. === X11 === Most X... |
No edit summary |
||
| Line 1: | Line 1: | ||
Sugar ought to be easy to run from chroots. For a variety of silly reasons, this isn't yet the case, but it might be soon. Ping [[User:Mstone|Michael]] with questions. | Sugar ought to be easy to run from chroots. For a variety of silly reasons, this isn't yet the case, but it might be soon. Ping [[User:Mstone|Michael]] with questions. | ||
=== Chroot Construction === | |||
There are lots of ways to create appropriate chroots; e.g. by hand, with debootstrap, with mock, etc. | |||
With debootstrap, you want something like | |||
debootstrap --arch i386 sid sid-root http://debian.lcs.mit.edu/debian | |||
sudo chroot sid-root /bin/bash -l | |||
With mock, it would be more like | |||
mock -r fedora-devel-i386 --init | |||
mock -r fedora-devel-i386 --shell | |||
=== X11 === | === X11 === | ||
| Line 5: | Line 19: | ||
Most X11 servers are configured to disable TCP connections. This means that in order to get a working X connection we can: | Most X11 servers are configured to disable TCP connections. This means that in order to get a working X connection we can: | ||
# bind-mount the X unix socket into the chroot. | |||
# ssh ''into'' the chroot with X11-forwarding enabled. | |||
# enable TCP on an X server, e.g. a nested Xephyr. | |||
We're going to try option (3) first: | |||
Xephyr -ac :1 | |||
and, inside the chroot: | |||
export DISPLAY=localhost:1 | |||
=== | ::''NB: If you figure out how to make Xephyr bind only to localhost sockets (or how to make it use a custom xauth config), speak up!'' | ||
=== D-Bus === | |||
Sugar wants to be able to use global state stored in both HAL and NetworkManager, both of which live on the system bus. Consequently, we need to bind-mount | |||
mount --bind /var/run/dbus $CHROOT/var/run/dbus | |||
before entering the chroot. (Mock uses unshare() to enter a new mount-point namespace since this makes garbage collection of mountpoints much easier.) | |||
With debootstrap, you'll also need to run some of | |||
mount -t proc proc $CHROOT/proc | |||
mount -t devpts devpts $CHROOT/dev/pts | |||
mount -t selinuxfs selinux $CHROOT/selinux | |||
manually in order to get a working chroot. | |||
Revision as of 18:31, 2 January 2009
Sugar ought to be easy to run from chroots. For a variety of silly reasons, this isn't yet the case, but it might be soon. Ping Michael with questions.
Chroot Construction
There are lots of ways to create appropriate chroots; e.g. by hand, with debootstrap, with mock, etc.
With debootstrap, you want something like
debootstrap --arch i386 sid sid-root http://debian.lcs.mit.edu/debian sudo chroot sid-root /bin/bash -l
With mock, it would be more like
mock -r fedora-devel-i386 --init mock -r fedora-devel-i386 --shell
X11
Most X11 servers are configured to disable TCP connections. This means that in order to get a working X connection we can:
- bind-mount the X unix socket into the chroot.
- ssh into the chroot with X11-forwarding enabled.
- enable TCP on an X server, e.g. a nested Xephyr.
We're going to try option (3) first:
Xephyr -ac :1
and, inside the chroot:
export DISPLAY=localhost:1
- NB: If you figure out how to make Xephyr bind only to localhost sockets (or how to make it use a custom xauth config), speak up!
D-Bus
Sugar wants to be able to use global state stored in both HAL and NetworkManager, both of which live on the system bus. Consequently, we need to bind-mount
mount --bind /var/run/dbus $CHROOT/var/run/dbus
before entering the chroot. (Mock uses unshare() to enter a new mount-point namespace since this makes garbage collection of mountpoints much easier.)
With debootstrap, you'll also need to run some of
mount -t proc proc $CHROOT/proc mount -t devpts devpts $CHROOT/dev/pts mount -t selinuxfs selinux $CHROOT/selinux
manually in order to get a working chroot.