Part 2: Gumstick Gentoo

Now that we know the enemy, what are we going to do about it? Now, we need to setup our Gumstick Environment.


Part 2: Always two, there are. A Master and an Apprentice
------------------------------------------------------------------------------

The trick with making an "embedded" system is that you develop it on a full-fledged host system and deploy the results to your target device. Well, we apply that same idea here. The main difference is that we're keeping our emerge environment separate from our final system. Since it's unlikely that you will often update software in an embedded environment, this is a safe assumption. But, the way I do it preserves that emerge tree so that you can hook it back into your Gentoo system for any needed updates/additions.

So, you're asking... how in the HELL do we do that? With some simple tricks I've picked up on my travels through Linux.


The Environment:

I have a two-tiered Gentoo environment for this project. First, find a directory to do some work in. You will need the ability to use all the commands listed in Part 1. I usually do the following in my home directory:

# mkdir gentoo portage_tree

For this setup, gentoo/ will hold my target file system, and portage_tree/ will hold, you guessed it, Portage! Now, we need to populate these directories with their skeleton directories.

Portage Tree Directories:
---------------------------------
# mkdir -p portage_tree/usr_portage
# mkdir -p portage_tree/usr_src
# mkdir -p portage_tree/var_cache
# mkdir -p portage_tree/var_db
# mkdir -p portage_tree/var_tmp_portage


Target File System Directories:
-----------------------------------------
# mkdir -p gentoo/usr/portage
# mkdir -p gentoo/usr/src
# mkdir -p gentoo/var/cache
# mkdir -p gentoo/var/db
# mkdir -p gentoo/var/tmp/portage

Notice much symmetry to that?? Well, that's because we're effectively mirroring our portage tree to a remote directory. Since we have access to the mount command, we can abstract this quite well. This remote file system can eventually be mounted from a local machine like we are about to do, or it can be mounted on an entirely DIFFERENT machine that is accessible through NFS.


Now, we need to prep our environment for extraction of the Stage 3 tarball. I'm assuming, at this point, you actually know a bit about Gentoo and how to get hold of the stages and the portage snapshots.

Linking our Portage Tree to our System:
--------------------------------------------------
# mount -o bind ~/portage_tree/usr_portage \
~/gentoo/usr/portage
# mount -o bind ~/portage_tree/usr_src \
~/gentoo/usr/src
# mount -o bind ~/portage_tree/var_cache \
~/gentoo/var/cache
# mount -o bind ~/portage_tree/var_db \
~/gentoo/var/db
# mount -o bind ~/portage_tree/var_tmp_portage \
~/gentoo/var/tmp/portage

Now, I'm sure you're wondering, "what the hell is -o bind". Well, that is a nice option to mount. It allows you to statically link or "bind" one directory to a different one. Therefore, what ever happens in, for instance, ~/gentoo/var/cache is actually STORED in ~/portage_tree/var_cache. Neat trick, eh?

Now that we have our environment setup, how bout we extract those Stage 3 and Portage tarballs?

Extracting the Gentoo System:
------------------------------------
# tar -jxvf ~/stage3-.tar.bz2 -C ~/gentoo
# tar -jxvf ~/portage-latest.tar.bz2 -C ~/gentoo/usr

For those of you who have never seen the -C option here, it copies the resulting extraction into the specified directory.


At this point, your Gentoo system is ready for a workout.

# cp /etc/resolve.conf ~/gentoo/etc
# mount -t proc none ~/gentoo/proc
# mount -t sysfs none ~/gentoo/sys
# chroot ~/gentoo

Now my that hands are getting tired, I'll end this section here. If you've ever done a Gentoo installation before, you should be able to start tinkering as you wish. You might not even need the rest of the guide!!

On to Part 3