chroot--what is it and how do I use it?

[GrannyGeek]

I have recently installed VL Light on my Celeron desktop and I plan to use it for packaging. I know very little about packaging but I'm reading up on it and hope to make my first efforts in a few days. The partition is small (3.9 G) and has 1.2 G of remaining space.

My Light installation is clean, with nothing added except for patches. (I did add the executable for Tuxcards, but that's just one file and does not include any libraries or other things that might dirty the system.) I made a backup of the clean installation so that I can restore the installation if it gets dirty.

I read info chroot but I didn't understand anything, I'm sorry to say. How does chroot work and will it make it easier to maintain a clean system? Is it advisable to use chroot when creating packages? Is there some place I can read about chroot in a way I can understand?

I hope I'll be able to learn to create good packages for our repositories.
--GrannyGeek

[rbistolfi]

Hi Granny,

The chroot command allows you to switch the location of your / directory for a given shell. Is more easy to use it than to explain it. Lets say you are in your VL Std system and want to make a package but you dont feel like rebooting. You open a console and mount the Light partition somewhere, for example /mnt/linux. Then, with chroot /mnt/linux, all the commands you run from that shell will be executed as if /mnt/linux were /. In that way, when in the compiling  You have to keep your chroot clean as a regular install, but its a lot more comfortable and you can easily switch from a chroot to another. I have two VL trees in /opt, one for 5.9 and one for 6.0, and I chroot to them for packaging so I can still use the WM I am used to use, and I can access my own environment (which is very far from "clean") easily just focusing in another terminal.

HTH

[Windozer]

GrannyGeek,

thanks for asking about this - chroot has always confused me enough to keep from trying packaging this way too.

... Then, with chroot /mnt/linux, all the commands you run from that shell will be executed as if /mnt/linux were /.

Rodrigo, thanks for the good - and clear explanation!

So anything outside (or rather "above") /mnt/linux (e.g. /mnt, and my real, original "/" root) are inaccessable/invisible to the compile?

In otherwords, if I chrooted just as you describe, but had a compiler option that asked for a lib file from my original machine's path, it would fail to find that lib?  (So, I'd have to make sure I have the right *copies* of the libs in the new tree in question.)

- H

[GrannyGeek]

Thanks for your explanation. I thought I understood it and finally had time to try it today, but I discovered I'm just as confused as I was originally.

My first question:
If I mount my VL6 Light partition under /mnt/vl6light (which is my usual mount point for that partition) and then chroot /mnt/vl6light, what advantage for keeping that partition clean do I have over just booting to VL6 Light and building a package there? Wouldn't the chroot partition get just as "dirty" as building in the actual partition? I mean, if dependencies have to be installed in order to build the package, they get placed in the VL6 Light partition anyway, do they not, even using chroot? If I chroot VL6 Light and have to "dirty" it in order to build a package, wouldn't I have to reinstall VL Light from my clean backup so the partition is clean for the next build? Or is chroot /mnt/vl6light a virtual partition that disappears once I'm finished building a package? (Which brings up another question: how do I get rid of the new root and back to my "real" partition?)

As you can see, I still don't understand the advantage of using chroot.

My next question:
How do I get the "new" root with the chroot command? As root I did
chroot /mnt/vl6light
and I got this:
chroot: cannot run command `/bin/sh': Permission denied

I'm doubtless doing something wrong. What is it and what is the right way to run chroot?

I've looked at
info chroot
but it's WAY, WAY over my head.
--GrannyGeek

[Windozer]

GG,

the way you have it set up now is, coincidently, causing part of the confusion  - if I'm not confused too much too 

There's a difference here between the "mount point of a partition" - and the "root" of the system - although they *could* be the same.

Are you booting from bios through grub/lilo/win directly to  " /mnt/vl6light " ?

If you use Thunar or Midnight, where are you when you cd to ' / ' ?


Let's think in Windows terms, just to look at it from another angle.

The root (if you will) of windows C: drive is C:\ ... and everything builds from there.
Open explorer and type in,  say,

C:\Documents and Settings\Grannygeek\Desktop 
(or whatever your username really is)
 
If in that same explorer window, you type merely ' \ '
it will take you back to the root of the c drive at C:\

If windows could do this (maybe it can, but that's way over my head),
you could say, well I'd like you to "pretend" your root is really C:\temp\Hello\

At that point, if you typed " \ " in a *new* explorer window, explorer would *show* that you were at ' \ '
But --- and here's the trick --- your hardware is really aimed at C:\temp\Hello... the OS just thinks this directory IS the root.

So Physical Drive: C:\temp\Hello *equals* logical directory C:\

This is what chroot in linux does - like a mount, but NOT the same - it says, OK you want me to think hda2/temp/hello is root? Ok fine, from the chroot on, I'll treat it as such... it becomes a logical directory tree within the *bigger* physical tree. And the Shell window Rodrigo mentions doesn't know anymore about the bigger picture.

I think part of the confusion - and why you got the error message - is that you are chroot'ing to the physical tree partition base... it's like saying 'root = root'

Each 'install' lives in its own smaller tree within the bigger tree.
You start in the big, chroot to the small... but the shell window and what runs in it thinks the new tree is *all* it has ... it can't see the bigger tree.
That way you can create a bunch of smaller trees, each with their own flavor of os, and chroot to each as you need.

Rodrigo (or anyone more knowing) *please* correctly me if any of this is wrong!
say its ' / ' 

[rbistolfi]

If I mount my VL6 Light partition under /mnt/vl6light (which is my usual mount point for that partition) and then chroot /mnt/vl6light, what advantage for keeping that partition clean do I have over just booting to VL6 Light and building a package there?

It would be the same. In the case of packaging chroot only advantage is to avoid rebooting. I also have a clean chroot tarred, uncompressing it is quicker than a reinstall for me.

Wouldn't the chroot partition get just as "dirty" as building in the actual partition? I mean, if dependencies have to be installed in order to build the package, they get placed in the VL6 Light partition anyway, do they not, even using chroot?

Yes, you have to keep your chroot clean in the same way you would do with a regular install.

If I chroot VL6 Light and have to "dirty" it in order to build a package, wouldn't I have to reinstall VL Light from my clean backup so the partition is clean for the next build? Or is chroot /mnt/vl6light a virtual partition that disappears once I'm finished building a package?

The packages will be installed there and the partition will not go away. With chroot you only change the / location for the given shell. For the next build you have to removepkg the extra unneeded dependencies. Chroot doesn't help at all for keeping clean the build environment.

(Which brings up another question: how do I get rid of the new root and back to my "real" partition?)

With the exit command, or control+d in almost every shell.

My next question:
How do I get the "new" root with the chroot command? As root I did
chroot /mnt/vl6light
and I got this:
chroot: cannot run command `/bin/sh': Permission denied

chroot <path> would leave you in the new /.

vector1:/~
root:# pwd    
/root
vector1:/~
root:# chroot /opt/chroot6.0/
vector1://
root:# pwd
/

After executing chroot, the working directory of the current shell is / (the fake one). The error you are getting is maybe related to the options used for mounting the partition. Be sure you dont have noexec, or that you have exec after users or user. Users and user mount option implies noexec.

EDIT: Windozer beat me

[GrannyGeek]

The error you are getting is maybe related to the options used for mounting the partition. Be sure you dont have noexec, or that you have exec after users or user. Users and user mount option implies noexec.

Thanks! That was the problem. My mount line in /etc/fstab included users. I added exec after users. When I tried chroot /mnt/vl6light the next time, I did get the fake / and all the directories of the chroot partition were there. So that part is solved.

Now I have to try building a package. My first effort with sbbuilder failed, but I already see some things I did wrong. If I get too stumped, I'll ask for help in the forum.

In another topic someone mentioned a chroot jail. What is that and how would I set it up?

The first package I want to build is FontForge, which should be easy as I have all the recommended dependencies in the default installation.

Thanks again for the help.
--GrannyGeek

[GrannyGeek]

I won't be able to get back to learning to package until sometime next week.

I'm not sure this is completely related to the topic, but it's something I need to know. I am hoping to package Scribus 1.3.3.13. If I'm not successful at making a package, I'd like to compile and install 1.3.3.13 for my own use. I have all the dependencies on one of my VL6 Deluxe systems except one; I haven't checked the "clean" Light system yet. The new Scribus needs qt 4.4. I have 3.3.8b. We have 4.4.1 in the repos. I need to install 4.4.1 in order to compile Scribus, but I don't want to replace 3.3.8b.

How do I install qt 4.4.1 without messing up 3.3.8b? I assume they can coexist.
--GrannyGeek

[rbistolfi]

They can coexist, iirc the latest Qt package is named "qt4" instead "qt-4.1.1", slapt-get -i qt4 would do it and wouldnt upgrade "qt3". Check configure flags for scribus, you may need to point the specific qt4 location (/usr/lib/qt4). Also, some tools from qt are suffixed, they can coexist with qt3 tools in that way. For example "qmake" becomes "qmake-qt4" and "qtconfig" becomes "qtconfig-qt4".
Post back if you find any issues, some software need some help finding the shared libraries.

[GrannyGeek]

Thanks! I'll go ahead and install qt4 when I'm actually ready to work on the package.

That will dirty my clean box, but I already have a tarred backup of the clean partition. Erasing the files and restoring the backup will be a good test of whether the backup will actually work,<g> and if not, it's not much trouble to reinstall from the CD. I always back up my home directory, so replacing the new /home directory with the backed up /home directory will get me back to where I was before dirtying things.
--GrannyGeek

[stretchedthin]

Thanks for bringing up this thread GrannyGeek.  Packaging is an area I'll be putting some attention into soon.  You've been asking some questions that have been on my mind for some time.

[Daniel]

Is a chroot jail different from just using chroot?