I just finished setting up a "fake" Gentoo installation inside a chroot jail. Seems to work pretty well for development, I can experiment with no fear of sodding up my actual workstation. In case anyone is interested, here is my "Captain's Log" that details the commands that I ran to build my "Faketoo" instance.

You should run these commands from a working Gentoo installation. Do not reboot off of the Gentoo install CD or anything.

I just finished setting up a "fake" Gentoo installation inside a chroot jail. Seems to work pretty well for development, I can experiment with no fear of sodding up my actual workstation. In case anyone is interested, here is my "Captain's Log" that details the commands that I ran to build my "Faketoo" instance.

i guess i must be slow...but this creates a "fake" workstation?
why would you want to do this?_________________#include <LinuxUser #324070>
main()
{
printf("and i'm sorry my spellign sucs.");
}

UML doesn't work (kernel won't compile, or just coredumps when run) if you have glibc compiled with NPTL support (he says, speaking from experience).

I have used a very similar technique to "clone" my live gentoo system into a chroot jail - I use LVM2 to grab and release the disk space on-the-fly. (I've got a large script, too long to post unless people are really keen)

I use this to do things like compile latest QT & KDE packages when not wanting to break my "real" desktop. Using "emerge -b" means binary packages are created, which I can then "emerge -k" onto my "real" machine once the full build is complete.

This wil only be dangerous to experiment in for real... one wrong /etc/init.d/net.eth0 start from within the chrooted gentoo and you may be disconnected... or emerging incompatible GCC versions... I can imagine this could raise hell on a production system. Would never dare try it...

If you want an extra chroot for the UML kernel that's possible too (bind mount /proc/cpuinfo, /proc/mm, /dev/net/tun and preferably /tmp to tmpfs). But that's if you don't trust the UML kernel enough AND maybe don't trust the users inside.

As noted above, my primary motivation for this is for ebuild testing. Yes, UML or VMware would also work, but a simple chroot jail is much more lightweight than both of them, and much more free as in beer than VMware.

BudgetDedicated wrote:

This wil only be dangerous to experiment in for real... one wrong /etc/init.d/net.eth0 start from within the chrooted gentoo and you may be disconnected...

Agreed, the init scripts are problematic. See my Danger Will Robinson note above. I am looking for a work-around, maybe taking the

Code:

chmod a-x /etc/init.d/*

would be a start. Another (better) idea would be to make /etc/init.d (inside the jail) a loopback filesystem and mount it with the 'noexec' option. I will try this out when I have some time and report back.

BudgetDedicated wrote:

or emerging incompatible GCC versions...

And how would these GCC versions break out of jail?

BudgetDedicated wrote:

I can imagine this could raise hell on a production system. Would never dare try it...

I do not really consider my workstation a "production" machine, and the worst thing that can happen is a spurious reboot (which is undesirable, but not fatal, and hopefully I will have a solution for this before long). I consider this safe enough for my needs._________________Josh Glover <jmglov@gentoo.org>
Gentoo Developer (http://dev.gentoo.org/~jmglov/)

This wil only be dangerous to experiment in for real... one wrong /etc/init.d/net.eth0 start from within the chrooted gentoo and you may be disconnected...

Agreed, the init scripts are problematic. See my Danger Will Robinson note above. I am looking for a work-around, maybe taking the

Code:

chmod a-x /etc/init.d/*

would be a start. Another (better) idea would be to make /etc/init.d (inside the jail) a loopback filesystem and mount it with the 'noexec' option. I will try this out when I have some time and report back.

Yes, mounting /etc/init.d loop,noexec works. As you can see, I updated the Captain's Log to do this for safety's sake.

I will look into getting init scripts to actually work safely, but this will at least protect you in the time being._________________Josh Glover <jmglov@gentoo.org>
Gentoo Developer (http://dev.gentoo.org/~jmglov/)

FYI - Many people use a similar technique with AMD64 as a temporary fix for stubborn 32-bit-only apps. My solution isn't too involved - I created a new root directory and installed an x86 stage1 tarball in it. I then do a mount --bind to map a few key key directories (/tmp for X11, /home for user files, /usr/portage/distfiles to go easy on the mirrors), but for the most part it is a complete installation. You do want to mount --bind /tmp otherwise you have to use TCP sockets for X apps and performance is much lower. Then again, for testing purposes it should be fine not to mount it - in the AMD world the 32-bit chroot is actually used for production.

I even use some init.d scripts to run daemons which are stubborn in the 64-bit world, and Java apps (the JVM's are pretty unstable in 64-bit-land, or at least they are for me...).

Check out the AMD forums for some tips - the same techniques would work for a 32-bit chroot jail.

Also, if you're back in the 2.4 world the grsecurity patches provide additional protection for chroot environments I believe (from my casual reading they seem to come close to real user-mode-linux).

UML doesn't work (kernel won't compile, or just coredumps when run) if you have glibc compiled with NPTL support (he says, speaking from experience).

I was wondering, if glibc with PIC enabled on the host, can brake my UML??
Sometimes my UML die unexpectedly...

PS for POLTO: Try to build a DMZ with three different UMLs with SELinux I'm doing just that
Thanks to you POLTO, you made me discover Gentoo as you gave me the LPI101 courses.!!! Do you know who I am???_________________Linux nb that actually RTFM

Imagine you have a dual optron workstation. And a 486 laptop how would you install a custoimized gentoo on the laptop? chroot it's harddrive on the workstation, compile everything and then just swap the hd...

Imagine you have a dual optron workstation. And a 486 laptop how would you install a custoimized gentoo on the laptop? chroot it's harddrive on the workstation, compile everything and then just swap the hd...

I was going to say that I have used this method twice now to install an operating system onto computers that don't have CD-ROM drives, but can boot from floppy disks.

I create the chroot and basically follow the handbook for every step after chrooting into /mnt/gentoo. I can emerge and configure packages (but haven't dared running init scripts there) on my fast machine without setting up distcc or anything. Then I start an FTP server, share a zipped version of the filesystem, boot the client machine with a floppy that has wget, tar, and preferably bzip2. On the target machine I mount the partitions in the correct places and unload it all to the root partition, preserving permissions and such.

Actually, that is one of my favorite features of this operating system: I can install the whole thing on a completely isolated computer before copying!_________________rtylershaw: "My computer doesn't even work and I love this distro. Weird."

Thanks for the guide, followed up to mkreiserfs -f ...etc. ;seems I have run into a snag though:

Code:

/root/faketoo/loopbacks/etc-init.d is not a block special device
Continue (y/n):y
Guessing about desired format.. Kernel 2.6.9-zdawg-rc3 is running.
reiserfs_create: can not create that small (1 blocks) filesystem

Hmmm ..._________________Me, myself and I are fighting ... now none of US are speaking..