32BitChroot

Differences between revisions 1 and 3 (spanning 2 versions)
Revision 1 as of 2008-03-17 16:56:25
Size: 4291
Editor: ip68-100-202-178
Comment:
Revision 3 as of 2008-03-23 16:20:14
Size: 4567
Editor: ip68-100-202-178
Comment:
Deletions are marked like this. Additions are marked like this.
Line 10: Line 10:
ia32-libs is an incomplete solution for 32 bit compatibility. It does not contain all necessary libraries (for example, SVG icons won't load in 32 bit GTK applications), and many applications and libraries have hardcoded paths and will not look for dependencies in lib32. In addition, one cannot simply install a 32 bit deb for an application that doesn't have a 64-bit version.  ia32-libs is an incomplete solution for 32 bit compatibility. It does not contain all necessary libraries (for example, SVG icons won't load in 32 bit GTK applications), and many applications and libraries have hardcoded paths and will not look for dependencies in lib32. In addition, one cannot simply install a 32 bit deb for an application that doesn't have a 64-bit version, and multiarch seems unlikely to be implemented anytime soon.
Line 49: Line 49:

One problem is the inability to access fuse mounted filesystems over bind-mounts; any fuse filesystem mounted inside the home or tmp directory on the main system will not carry over the bind mount to the chroot.

Create an easy way to setup and integrate a 32 bit chroot for 64 bit Ubuntu

Abstract

ia32-libs is an incomplete solution for 32 bit compatibility. The inability to use 32 bit debs forces the user to manually install, defeating the ease and consistency of using packages.

This proposal aims to solve this problem by using a chroot and setting it up to be as seamless as possible.

Rationale

ia32-libs is an incomplete solution for 32 bit compatibility. It does not contain all necessary libraries (for example, SVG icons won't load in 32 bit GTK applications), and many applications and libraries have hardcoded paths and will not look for dependencies in lib32. In addition, one cannot simply install a 32 bit deb for an application that doesn't have a 64-bit version, and multiarch seems unlikely to be implemented anytime soon.

See https://blueprints.launchpad.net/ubuntu/+spec/trivial-32bit-app-install-on-64bit

Implementation

This should probably be implemented as a package that could be installed to add 32 bit support, perhaps named app32-chroot. schroot will be used to allow the user to enter the chroot without being root.

The package should create a directory in /var/lib/chroot/ubuntu32 for the chroot, and unpack a minimal installation. Dependencies will be added as the user installs debs or selects individual 32 bit applications in synaptic or aptitude.

A number of bindmounts will need to be added to make use of the chroot as seamless as possible. An example fstab snippet is below:

/home           /var/lib/chroot/ubuntu32/home           none    rbind          0          0
/dev            /var/lib/chroot/ubuntu32/dev            none    rbind          0          0
/proc           /var/lib/chroot/ubuntu32/proc           none    rbind          0          0
/media          /var/lib/chroot/ubuntu32/media          none    rbind          0          0
/mnt            /var/lib/chroot/ubuntu32/mnt            none    rbind          0          0
/tmp            /var/lib/chroot/ubuntu32/tmp            none    rbind          0          0

Hardlinks or some other kind of synchronization from the base to the chroot will have to be done for at least the following files:

/etc/hosts
/etc/passwd
/etc/shadow
/etc/group
/etc/resolv.conf

An integration problem would be applications such as Firefox calling helper applications to open files that exist outside of the chroot. Is it possible to create a chroot of the bindmounted root install inside a chroot in order to do this? The amount of recursion is somewhat headache inducing. Duplicate 32-bit versions could be installed, but would be suboptimal. One would have to repeat the additional integration steps below in reverse for the 32 bit chroot to call stuff from the 64 bit base.

.desktop files inside /usr/share/applications inside the chroot will need to be copied or symlinked to /usr/share/applications outside the chroot. A utility should probably be created to manage the ones that are desired.

A script to launch applications should be created for each and every executable in /bin, /usr/bin, and /usr/local/bin that is in the chroot, and these should be placed in /var/lib/chroot/launchscripts. The launch script will simply call schroot to execute the executable and preserving the environment. These will be symlinked to the appropriate bin directories, or if an existing executable with the same name exists in the 64 bit installation, the result would be influenced by the aforementioned management utility, which would disable or enable these launch scripts and assosciated.desktop files.

In the event of a conflict, the 64 bit exe will be diverted to /var/lib/chroot/diverts, and the alternatives system will be used to select which one to use, defaulting to 32 bit script if there is no .desktop file referring to the executable. If there is, the 64 bit bit version becomes the default, and the .desktop file for the 32-bit version has it's path modified to refer to the absolute path of the launch script, and renamed to indicate it is the 32-bit version.

Modifications to update-manager to update the chroot, and gdebi to install i386 packages into the chroot will have to be done. synaptic32/aptitude32 scripts will be used to modify packages inside the chroot.

One problem is the inability to access fuse mounted filesystems over bind-mounts; any fuse filesystem mounted inside the home or tmp directory on the main system will not carry over the bind mount to the chroot.

BluePrints/32BitChroot (last edited 2008-08-06 16:15:23 by localhost)