Currently I am able to build an Ubuntu 18.04 32-bit chroot on my developer machine and I wanted to know if I can have the process happen inside a docker container.

The process I use:

  • Untar an ubuntu base image (ubuntu-base-18.04.3-base-i386.tar.gz)
  • Copy the resolve.conf from the host to the untarred file system
  • Mount /sys, /proc and /dev
  • Run chroot /location/of/filesystem /bin/bash to get into the chroot and run further setup
  • When done I unmount everything and tar up the /location/of/filesystem.

Is it possible to do this same method inside a docker container?

I don't see anything about being able to mount/unmount files from within a docker container.

  • What do you want to do with this tarball that you create? Oct 29 '19 at 20:09
  • Move the tar to the system that it will run on, untar it, and then run chroot /location/of/filesystem /usr/bin/app-inside-chroot --flags. The reason is we have an old OS (updates are in the works but won't be done in time for what we are trying to develop) that needs to run a newer version of an app we are developing. Said app is not compatible with the host OS, but it is compatible with the chroot environment.
    – Wimateeka
    Oct 30 '19 at 12:59
  • Are you looking to replace the chroot with a Docker container? Oct 30 '19 at 13:05
  • No, because the host OS is 32-bit and Docker can only run in 64-bit architectures. I just want an environment where I can build the chroot in a repeatable way. This repeatable build in a docker container will hopefully be able to run on Jenkins.
    – Wimateeka
    Oct 30 '19 at 13:06
  • 1
    I don't see anything fundamental that would prevent it from working. The chroot /path/to/filesystem /bin/bash will block, but you might be able to turn the work after that into a script that you execute at that point. Oct 30 '19 at 17:28

The problem I thought I initially had was because of how I had programmed the script run by the docker container to create the chroot.

It is possible to create a 32-bit chroot in a docker container. I had to run a privileged container, otherwise I could not mount required dirs/file systems (Ex: /proc) to the chroot (And I would receive errors).

I had to modify the steps I used slightly:

  • The docker command I used was: docker run -t --rm --name "chrootTest" -v $(pwd):/root/<CHROOT_SCRIPT_DIR> --privileged --workdir /root/<CHROOT_SCRIPT_DIR> <IMAGE>:<TAG> ./build-chroot.sh <CHROOT_DIR_LOCATION>
  • I do not have to mount /dev or /sys for the chroot modifications I am doing. (The modifications consist of removing directories/files/symlinks and apt-get install-ing some dependencies. I only needed to mount /proc for these actions, but if you are doing something different you may need to mount the other directories.)
  • The script untars the archive into <CHROOT_DIR_LOCATION> and copies the resolve.conf from the host to the untarred file system, while also making any required dirs for mounting.
  • Then I have a heredoc that goes into the chroot and does required setup chroot "$CHROOT_DIR_LOCATION" /bin/bash <<'EOF' ... EOF
  • After setup I tar up the chroot files system, and remove the workdir <CHROOT_DIR_LOCATION> and the script ends and the docker container is removed.

Because of the volume mount, the tar archive with the newly created chroot still exists on the host running the docker command.


I use docker to make changes to the Ubuntu installer live CD. It contains a casper/filesystem.squashfs that is similar to a chroot environment; i.e., it is a complete root filesystem that gets written to the target filesystem during installation. I make changes to the filesystem.squashfs like this:

# extract installer iso
$ osirrox -indev ubuntu-18.04.4-desktop-amd64.iso -extract ./ ./ubuntu-18.04.4-desktop-amd64.d

# extract filesystem squashfs
$ unsquashfs ubuntu-18.04.4-desktop-amd64.d/casper/filesystem.squashfs

# create filesystem tarball
$ tar -cf squashfs-root.tar -C squashfs-root .

# create docker image 
$ docker image import squashfs-root.tar squashfs-root:latest

# create docker container, make changes inside
$ docker run --name squashfs-mine squashfs-root sh -c 'touch /etc/my.conf'

At this point, the now-stopped container squashfs-mine contains the original filesystem, along with any modifications performed during its run. You can now export the container's filesystem as a tar archive:

# extract filesystem tarball
$ docker export -o squashfs-mine.tar squashfs-mine

In my case, I would want to generate a new filesystem.squashfs into the original *.iso contents and re-pack the *.iso:

# populate filesystem directory
$ tar -xf squashfs-mine.tar --one-top-level

# create filesystem squashfs
$ mksquashfs squashfs-mine ubuntu-18.04.4-desktop-amd64.d/casper/filesystem.squashfs

# re-pack iso
$ xorriso -as mkisofs ... -o ubuntu-18.04.4-desktop-amd64.iso ubuntu-18.04.4-desktop-amd64.d

...but your needs are probably different.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.