# What exactly is a chroot? Is it similar to a simultaneous dual boot?

It has been suggested to me that the use of a chroot might solve my problem of building an application that must run on an embedded device. I have inferred from this description that it is somehow similar to creating the embedded environment locally on my machine which I can then use to develop on from my desktop development machine. Is this the right way to look at the functionality or have I totally misunderstood?

In order to get some idea of how it works I read this https://wiki.ubuntu.com/DebootstrapChroot which I will attempt to make a chroot for an old Ubuntu version on my machine. However, as I am a total linux novice, I am a bit concerned that as I do not entirely know what I am doing is there anyway that I could end up with an unusable system?? Is this something that a novice should even attempt???

-

chroot has nothing to do with dual booting. The idea behind chroot is the ability to switch one program, or one shell, etc., to a new root directory, allowing you to have multiple "systems" at the same time. "systems" is in quotes because there is still only one Linux kernel running. This other "system" is an additional set of the code tools, home directories, etc. So, if you are on an x86 machine, and are trying to build some software for ARM on your machine, you could create a chrooted environment whose /proc tells the software that it's on ARM, an ARM GCC toolchain, etc. (There are many programs that do that). The other thing chroot can do is some very limited sandboxing, that combined with something like SELinux and basic Linux permissions, could create a relatively secure sandbox, in which this application thinks it's on a different system. Another use of chroot would be testing. If you have an application that does different things based on some system directory, you can create a chroot to test it in.

-
So to make use of this in an embedded setup, I would create a base directory (the new root) then copy completely the file hierarchy and all of its contents from the embedded device onto my development machine and then chroot to it? –  mathematician1975 Jul 12 '12 at 15:10
@mathematician1975: You could. Not sure how well that would work though. What the chroot can offer you us something like that, where you have a new development environment for the device. Because the device's code is (most likely) not written for your architecture, you'd want to just get an environment where you trick your compiler, etc. that they are on your embedded machine, so they'll build for it. Take a look at this: help.ubuntu.com/community/BasicChroot –  Linuxios Jul 12 '12 at 15:14
Thanks that paints a clearer picture in my mind of whats going on –  mathematician1975 Jul 12 '12 at 17:37
avahi-daemon creates its own chroot when it runs to avoid any tampering with the root filesystem. –  Ken Sharp Jun 8 '14 at 21:23

I feel like nobody gave a full technical explanation, so here goes.

To understand a chroot you first have to understand the split between kernel (The Linux in GNU/Linux) and userspace (the GNU in GNU/Linux, or possibly something else, like busybox.)

The kernel controls all the hardware in your computer. It also provides the APIs for file access, networking, and so on, and controls which software programs are running. This all forms an abstraction of the computer, which is presented through an application programming interface (API). It doesn't do anything at all on it's own though, except maybe boot up to a black screen. Not even a shell prompt.

The userspace is everything else. All the software that you run on your computer. Actually the kernel only runs one userspace program directly, init, which is then responsible for starting everything else, like shells and desktop environments. Userspace also includes libraries, which generally start with libc, upon which all the other libraries build.

So, with that in mind, the concept of a chroot is simple. It just changes the root directory of the unix filesystem to a different one, just for whatever command you choose to run in this context. This is usually a shell which you can launch other software, much as the kernel only launches a single command directly. This new context can have a different set of userspace programs and libraries. The same kernel is running both sets of software, so both systems can use all the hardware resources, but (barring security bugs) the nested chroot cannot access anything from the primary filesystem. It has it's own version of /etc for configuration, it's own /lib for libraries, and it's own /bin, /usr/bin for programs.

You should be aware that the hardware devices are shared. So, unlike a virtual machine, if you format /dev/sda from inside the chroot, you will format your real harddisk. This is because the device nodes in /dev are a direct kernel interface, therefore they mean the same thing inside and outside the chroot.

One other thing: it is possible to give the chroot access to the outer filesystem with bind mounts. If you use a chroot building tool it is possible that it "helpfully" mounts /home from the main system inside the chroot. This is not a copy, it's the same filesystem, and in this case any changes you make inside the chroot will be performed on the original. So I recommend you build chroots manually until you are comfortable with how they work.

Other than these two potential problems there isn't much that can go wrong with a chroot, as it is mostly a self-contained system that will only be started when you ask for it.

-

Let me try to explain chroot in terms of Windows. In windows the "root" of the boot partition is called "C:\" In Linux it is called "/". choort (temporarily) allows you to make some other folder/partition/device the root partition. If Windows had a choot command it might have worked as follows.

Imagine you have a computer with two partitions or drives with two versions (or copies) of Windows installed. Lets Call them WinA and WinB. When you boot WinA, its root becomes C:\ and WinB may appear to be in D:. When you boot WinB, C:\ refers to the partition where WinB is installed and D:\ is where WinA is. Now let's say you want to make some changes to both WinA and WinB by running a program z. When you run z it does all the changes you want to the system that has the root C:. In the Windows world you have to boot WinA run z and then boot WinB and run z. chroot allows you to make the D:\ into C:\ without rebooting. So you can boot WinA run chroot to make the D: the new C: and run program z so that changes are made to the WinB which resides in D:\ instead of WinA, which is in the original C:.

Now let me give an example of how I have used chroot. Once my Ubuntu became unbootable. It turned out that the grub needed to be reinstalled. This is easy if I could boot Ubuntu and run the command that installs grub. But I needed to do this from an USB. So I booted Ubuntu from a USB drive. If I issued the command to install grub I would install grub to the USB. So I needed to mount the partion in the hard drive where the Ubuntu with broken grub is installed and use chroot to point to that mounted partition. Then I reinstalled grub and grub got installed in the hard drive where it should be.

-
That is a nice explanation –  mathematician1975 Jul 12 '12 at 17:37

Chroot allows you to run a command or shell from another root directory. If it was suggested to you because of an embedded device, it means that you will be running a shell from that device's root directory.

-
running a shell on my host machine from the embedded device? –  mathematician1975 Jul 12 '12 at 13:43
I'm pretty sure he means you can run a chroot in the embedded device's root directory. Either an image for the device, or via a USB or network link. It can be done on a live system though I wouldn't recommend it if it can be avoided. –  Ken Sharp Jun 8 '14 at 21:25

Not really, no.

Booting an OS involves loading a kernel that controls the hardware and then runs a number of other programs. chroot runs a program ( typically a shell, from where you can run other programs ) under your current kernel, only the kernel lies to the program and pretends that the root directory is some other directory than the one it is really using as the root. Hence, the name of the command, because it changes the root directory.

In your case, debootstrap sets up a directory tree that is suitable to use as a root directory. You could boot a kernel and tell it to use that directory as the root instead of your normal root fs, and you would be booting that system. By using chroot you can run programs as if they were being run under a kernel that booted using that directory as its root, without actually having to do so.

-
So it is like a custom built environment meant to "simulate" another? You create that environment and all software runs as if it were running in that new environment ? Or is that oversimplified (or wrong) –  mathematician1975 Jul 12 '12 at 15:08
@mathematician1975, you could look at the combination of chroot + debootstrap that way. –  psusi Jul 12 '12 at 23:21

When you are booting from another system, for example a Live CD, you can enter into a file system (linux) by using chroot.

With this, you could for example repair GRUB (in case of errors). This is also very useful if you cannot boot and want to download important files from a specific partition.

-
You do not use chroot for any of that. You would simply mount the filesystem. –  Ken Sharp Jun 8 '14 at 21:26