(Image: Club Logo) HCC

Getting chroots to Work
For the:
Halifax Computer Club
Halifax, Nova Scotia, Canada


How I am able to run Firefox 2 (which includes the Macromedia/Adobe Flash 9 plugin)
included in my SimplyMEPIS 7.0 installation
from my Kububtu 6.06/Dapper Drake installation on the same AMD64machine)

Abstract

After having used Kubuntu 6.06/Dapper Drake for roughly a year there were some issues, most especially with Firefox and Mozilla freezing up on my AMD64-based laptop when directed to a web page that included Flash content. After some investigation I decided to give SimplyMEPIS 7.0 a try. It was still in Beta and there were some issues with it but both Firefox and Mozilla (sorry, Iceape) worked well, including displaying pages with Flash content perfectly. I had RTFMed a bit about the chroot command and wondered if I could use it to run the MEPIS version of Iceape from my Kubuntu installation, until SimplyMEPIS 7.0 had worked through its teething troubles. After a couple of days of effort I succeeded. The method was to use the command schroot (which allows a normal user to do the change root), alter the .bashrc file on the MEPIS installation to make sure that the DISPLAY environment variable is correctly set, and to use the xauth command to create a .Xauthority file on the MEPIS installation that would allow MEPIS windows to be displayed by Kubuntu's Xserver. Of course, any other program on the MEPIS installation could also be invoked, with the caveat that it must be compatible with the Dapper kernel.

Introduction

I have been using Kubuntu 6.06/Dapper Drake for roughly a year. I finally got fed up with Firefox and Mozilla freezing up on my AMD64-based laptop when directed to a web page that included Flash content, as was happening more and more frequently. (I later discovered that this was because there is no nspluginwrapper package available for Dapper.) Also, I have become weary of KDE and wanted something much lighter. I tried XFCE 4.3.9 (the version of XFCE available with Dapper) but discovered there was a runaway process in it. I added lines to the sources.list file for Debian testing (which includes XFCE 4.4) but discovered that the Debian archives were not compatible with Dapper's. So I began thinking about alternatives, especially Debian testing.

Then I came across Steven J Vaughan-Nichols' excellent article on SimplyMEPIS 7.0 (MEPIS to switch from Ubuntu to Debian) and liked what I read. I already felt the same way about many of the disadvantages of Dapper outlined there, so decided to give MEPIS a try. It was still in Beta and there were some issues with it. Neither the MEPIS Network Assistant nor Network Manager was able to configure my Ralink RT2500 wireless card. And the XFCE 4.4 system was partly broken - parts of it could not be installed without having to remove libfam0, which would have broken the OS. In addition, it was not possible to set up /usr on a separate partition and the /etc/fstab file kept being rewritten on bootup so that I could not get my other partitions mounted as I wanted. Oh, and the 2.6.22 kernel would only support 15 partitions, and I had more than that.

But both Firefox and Mozilla (sorry, Iceape) worked well, including displaying pages with Flash content perfectly. I had RTFMed a bit about the chroot command and wondered if I could use it to run the MEPIS version of Iceape from my Kubuntu installation, until SimplyMEPIS 7.0 had worked through its teething troubles. After a couple of days of effort I succeeded.

Method

The idea of the chroot (change root) command is to specify another directory as the root directory instead of the original /. This means that there must be the usual bin, sbin, usr, dev, etc, lib, etc directories as subdirectories of the new root directory, together with all of the expected subdirectories and files. Chroot's are frequently used by developers to test software under development in isolation from, and as protection for, the main system directory hierarchy.

But what better place to find all of the neccessary infrastructure than on another operating system installed on another set of partitions on the same computer? With such large disk drives as are now found on most computers, multiboot systems are easy to create. For several years I have been checking out alternatives to my existing "working" OS by setting them up in such a multiboot environment. That was how I installed SimplyMEPIS 7.0 on the same machine as Dapper. I was hoping to be able to chroot to this installation from Dapper and run its version of Iceape instead of the Mozilla on Dapper.

I was already aware of one problem - chroot can only be issued by the superuser. The solution was to use the command schroot, which allows a normal user to do the change root. This command is available in the .deb package named schroot on Debian, Ubuntu and MEPIS (and presumably other Debian-based distributions). Included in the package is a configuration file named /etc/schroot/schroot.conf. I added the following lines to this file.

[MEPIS]
description=SimplyMEPIS 7.0
location=/SimplyMEPIS7.0
groups=jcw,root
aliases=mepis

This allows the change in root to be made by issuing, from a terminal window, either schroot -c MEPIS (using the name of the chroot specified in the square brackets) or schroot -c mepis (using the lower case alias, which is easier to type, at least for me). The description line is just that, the location line specifies the mount point within the Dapper installation at which the MEPIS partitions begin, and the groups line specifies the names of all groups whose members are allowed to successfully issue either of the previous schroot commands. I have used jcw as my username for decades and most Linux distributions now create a group for each user with the same name as the username.

And what do you know? It worked the first time! (This is a very rare occurrence for me.) I was immediately put into a shell on the MEPIS installation, in my home directory /home/jcw on that installation.

And then the problems began. When I issued firefox & to start up firefox there was an error message saying something like "cannot open display". It turned out that schroot had removed most of the environment variables, including DISPLAY, when it put me into the chroot.

The solution to this was simple. I just added the line

[ $DISPLAY ] || export DISPLAY=:0.0

to the .bashrc file in /home/jcw (my home directory) in the MEPIS installation. This checks to see if DISPLAY is set and sets it if it is not. Just to make sure I added the same line to the .bash_profile file in /home/jcw in the MEPIS installation as well.

This time firefox & resulted in an error message from Xlib saying something about no protocol had been specified so it could not open the display. The solution to this took a lot longer to figure out. It turned out that the protocol referred to was the authorization protocol. An Xserver has the capability of displaying Xclients running on machines anywhere on the Internet. There has to be some mechanism to prevent unauthorized Xclients from being so displayed. This is what the X authorization protocol does. It is actually a set of protocols, the appropriate one of which should be used depending on the circumstances. Modern Linux distributions set these up for you.

When the Xserver starts up and a user logs in from the login window, the Xserver creates a .Xauthority file in the user's home directory which gives the user permission to display Xclients on it. Since I was not logged in to the MEPIS installation directly from the Xserver there was no such file in my home directory there, and so I was not allowed to run Xclients in the MEPIS installation on the Dapper Xserver.

From poking around in the X documentation I discovered the xauth command, which turned out to be just what was needed. This command can be used to extract authorization records from one .Xauthority file and merge them into another .Xauthority file. After some experimentation I came up with the command

xauth extract - $DISPLAY | xauth -f /SimplyMEPIS7.0/home/jcw/.Xauthority merge -

to be issued from a terminal window on Dapper before issuing the schroot command.

The first part of this (xauth extract - $DISPLAY) extracts records from the .Xauthority file in my home directory on Dapper and writes them on stdout. The second part (xauth -f /SimplyMEPIS7.0/home/jcw/.Xauthority merge -) receives on stdin the records piped to it (the | operator) from the first part and creates the .Xauthority file in my home directory on MEPIS.

Finally I was homefree.

Fine Tuning

But who wants to remember all of that, and enter it on a command line everytime she/he wants to do a litte web browsing? Certainly not I. So I created the following alias and edited it into the .bashrc file in my /home/jcw home directory in the Kubuntu installation.
alias mepischroot='xauth extract - $DISPLAY | xauth -f /SimplyMEPIS7.0/home/jcw/.Xauthority merge -; schroot -c mepis'

That done, all I have to do is open up a terminal window in Kubuntu, issue the command mepischroot, and when the response indicates I am in the chroot, issue the command iceape &, wait until the browser comes up, and start surfing. (This assumes of course that the line setting up the DISPLAY has already been added to the .bashrc file in the MEPIS installation, as previously described.)

Summary and Conclusions

Setting up a chroot using the schroot command can be achieved by following 3 simple steps.

  1. Add lines defining the chroot to the /etc/schroot/schroot.conf file in the Linux distribution from which the user will log in.
  2. Add a line to set up the DISPLAY environment variable in the /home/<username>/.bashrc file on the Linux distribution to which you wish to chroot.
  3. Set up an alias in the /home/<username>/.bashrc file in the Linux distribution from which the user will log in, to create the .Xauthority file in the chrooted environment and chroot to it.

Once the chroot has been set up and invoked, any Xclient available in the chrooted environment can be executed, as long as it is compatible with the kernel executing in the login environment. Here "compatible" means that the Xclient will not attempt to use kernel facilities available from the kernel in the chrooted environment but not available from the kernel running in the login environment.

Jack Warkentin


Back to the: Tips & Tricks index

Home