Moving -- Going to Typepad.com

Since my wife and I have both decided to start contributing to a joint blog, we've moved over to

http://trotters4eva.typepad.com and

http://trotters4eva.typepad.com/papa_geek

Push Gmail For Windows Mobile

For the past month, since getting my Windows Mobile PocketPC, I've been having the hardest time finding an easy and FREE way to get my GMail pushed to my phone.

Well, I've finally found it. It goes by the name emoze. This is a native Windows mobile app that synchs your GMail inbox with your phone. However, messages deleted from the phone are not deleted from GMail. Also, it will download all your GMail contacts into your phone... This can be turned off, but usually, you'll have almost all of them before you can.

The nice thing is that once you have it all set up, it works like a dream pushing emails almost instantaneously.

Go to http://www.emoze.com For more info, and for direct install for the supported phones http://mobile.emoze.com

Mobile Blogger.com

Ohhhh yeah, I'm waaaaaay behind the time as this is my first official
mobile blog post. As I am doing this as a test of not only
blogger.com, but also of my new phone, I'm including a picture of
something on my desk for the fun of it.

Hope to be posting more often now.

I have returned

Sorry for the long delay, but I'm back to trying to update this blog... at least occasionally.

I've been running my tail off at work since we just released our new firmware for our switches, and I'm helping to track down a possibly bad Xorg driver (how I've come to loath silicon motion's linux drivers).

But on the positive side, I have started really porting linux 2.6.19.7 to our board that uses a Freescale MPC8272. I tell you what, we use every damn one of our SCCs and SMCs, plus the FECs as well.

Good news is I've got all those interfaces mostly working and can boot Linux very easily over NFS. (Yes, this just a debug step). I've even had fairly good success porting over our custom modules to the 2.6 way of "thinking".

I have a new appreciation of JTAG, I'll tell you that much!

Sorry for the Delays in Posting

I have recently been tasked with an interesting assignment that is driving me a bit batty and is consuming a lot of my mental effort during the day.

I'm in the process of porting an MPC8274-based 10Gb ATCA switch to work with the 2.6 series linux kernel. I'm having a hell of a time even getting the serial port to work (as in I haven't been successful even after a week of work).

So.... not much for updates other than informational today. Although, what I learn will be placed here as I can't find a damn thing on google to really help me with this....

THLinux Update

I know that this will sound crazy, but I'm radically changing my approach to THLinux and may shelve it completely. After tinkering around for a bit, I realized that I am basically trying to recreate Buildroot from scratch. Which is stupid because the developers of both busybox and uClibc maintain the Buildroot scripts.

So, what I am looking to do is use the buildroot to construct a basic, static bootable core environment. Then I will look into adding in debian-like support so that you can build up your own debian-derived system (as the basic dpkg is supported by busybox... as is).

So, as I said earlier about THLinux, it's extremely alpha and subject to my whims.... neither of which can be considered stable. ;-)

THLinux and Gumstick Gentoo Updates

As per my THLinux announcement, I have created a homepage for it. Now, don't laugh at the formatting of the page please. Remember, I'm an engineer... not a graphic design artist! But there are some basic gotchas and download link. Right now, the safest thing to do if you want to just try it out is to execute "#./build_thlinux; ./install_thlinux /dev/sd{a,b,c,d}1 {-g}"

sd{a,b,c,d}1 is your thumb drive device that you'd like the rootfs directory dumped into, and the {-g} will install and setup grub on the thumb drive(provided you have grub-install on your host computer).


THLinux TO DO:
---------------

• Add build/install support for "nslookup" as it is broken in my busybox build (will come from bind 9.4.0)
• Add elinks/lynx for web browsing
• Look at adding TinyX and Matchbox for GUI support
• Investigate Cross-Compiled installs... (this could get very interesting... )

Gumstick Gentoo TO DO:
-----------------------

• Create THLinux-like build scripts to construct Gumstick Gentoo with a simple build script
• Investigate the experimental uclibc-based Gentoo for shrinking image even more.
  

New USB Linux Solution Announcement: THLinux

After tinkering around with gentoo, debian, ubuntu, and many other distribution solutions, I found that none of them did what I wanted in a small space. Well, I believe I have finally solved the issue.

Announcing: THLinux
----------------------

A full 2.6.x series kernel distribution with a simple master build script that fits in <64mb>

Boots From USB thumbdrive

Linux 2.6.17.14 Kernel with approx 32MB+ of available modules

Scripted build environment with minimal deployment requirments

Custom Compiled

Build Script is customizable to update rootfs and kernel sources

Basic IPv4 Networking

Text Editing

Mount and read from nearly any type of file system

Patch minor bugs in busybox-1.4.1:

• Patched applets/applets.c to allow static busybox linked against glibc (although the developers might argue I broke it to allow statically linked .... ;-) )
• Fixed scripts/mkconfigs so that it generates a correct bbconfigopts.h
• Fixed scritps/trylink so that it will actually work in ubuntu(and probably other distributions as well)
  

TODO:
Download missing/newer sources and patches
Add more functional programs
Add support for Cross Compiling
Add support to build PXE-bootable images
Create a "make menuconfig" style interface

So far, I have been able to create a bootable thumb drive with the user needing only minimal command line interaction. A full build log is maintained in the background while providing simple status updates to the standard output.

As of right now, my build environment has been tested and appears to be fully operational in Ubuntu Dapper Drake and Edgy Eft(with downgrade to 4.0 series compiliers) . Granted, it's an early alpha stage, but what in the embedded world isn't?

Top Ten Ways to Get a Geek to Help...

In my browsing around the web and doing computer tech work for the past ten years, I've come across some truths in this world... relating to Geeks of course. Therefore, I intend to share my knowledge of how to actually get a geek to help you out when you need it.

• 0x0A - Ask Them
  
• This may sound completely insane, but sometimes you can actually get help from a Geek if you ask nicely. Usually, you can pick out the Alpha Geek easily with this tactic as (s)he will usually make some sound resembling a cackle and roll their eyes. Beta Geeks will mumble something about being too busy and walk away. Then you get to the Gamma(wanna-be) Geeks. Sure, it won't be the best Geek in the world to get your task done, but something at least will happen.
  
• 0x09 - Threaten Them
• This is only slightly better than the 0x0A approach. Mainly all this will accomplish is motivating the Beta Geek to get something done for you, if begrudgingly. However, expect a snide remark from an Alpha Geek, and you will most likely get a "deer-in-headlights" look from the Gamma Geeks.
• 0x08 - Pay Them
  
• As much as Geeks say they do it as a hobby, everyone likes money. Depending on the amount offered, you could easily net you an Alpha Geek.
  
• 0x07 - Buy Food for Them
  
• As much as Geeks like money, they like free things even more. Even if the free things are utter CRAP, it's like Geek Gold. Food however, is about an average-level enticement. Therefore, expect Gamma - Beta Geeks to be enticed.
• 0x06 - Give Old Computer Parts to Them
  
• Following on the same line of thought, this is a Gamma - (low-rent)Alpha Geek enticement. The only reason I say low-rent is that an Alpha Geek will most likely already own a small shed that does nothing but act as their spare parts bin.
• 0x05 - Tell Them You Can Do Something, and then Screw Up
  
• Now that we're past the NORMAL enticements, you need to understand something about Geeks. They love to show their superior knowledge about all things Tech. Therefore, if you don't want to take the direct approach with bribes, you need to appeal to another facet of the Geek's personality: Inferiority Complexes that are masked by in-depth knowledge of tech. So as the title suggests, tell the (Gamma - Beta) Geek all about this handy trick you just learned and how you want to show it off. Then as they are intently watching, intentionally do EVERYTHING wrong, and say, "Well it worked on that old Penturiam 98 Box downstairs... why doesn't it work here?" At this point, stand back and let the Geek get to work.
  
• 0x04 - Buy Beer for Them (Legal ages only, please)
  
• Ahh, now we're GETTING somewhere! About the only thing better than an all night-programming session is having a pack of frosty beverages to help "get you in the zone". This tactic will likely net you the big one, an Alpha Geek. Although, it does help to know what level your Geek is; therefore, be sure to use tactic 0x0A to figure out who is the Alpha Geek.
  
• 0x03 - Tell Them That There's No Way They Can Do Something
  
• The only thing an Alpha Geek likes better than beer or showing off what they know is a challenge, especially when you single them out in front of others to say they can't do something. If nothing else, the Geek will get it done out of SPITE. They will then make it known they did it out of spite and in a really loud manner. Be prepared to take a bit of diatribe at this point.
  
• 0x02 - Be a Member of the Opposite Sex
  
• Geeks need luvin too.... Even if there's no chance of it happening
  
• 0x01 - Be a HOT Member of the Opposite Sex
  
• Seriously, did you really think you were gonna get a date out of it?
  

Other World Computing Warranty Hassles....

Update 3/2/2007: After kicking it around at OWC, apparently, their owner made an exception and has granted my warranty request. I also want to point out that the original owner of the ram has used these people MANY times and has nothing but praise for them.


First off, let me say that I don't usually like to do these sorts of things, but I figured that people (especially Macintosh owners) might like to hear this.

Next, let me setup the situation. I bought a Mac Mini second hand from someone who had upgraded the ram with a 1GB DDR2700 DIMM from OWC, a computer upgrade website targeted towards the Mac user. The RAM has since gone bad and I'm trying to get a warranty replacement since it has a lifetime warranty.

As they have a confidentiality statement in their email that does not permit reproduction, I will give you a summary as to protect all involved except the company in question.

Since I saw no restrictions on the warranty information on their site, I emailed their RMA form and received a response .

The response seemed friendly enough asking if they could use the original credit card to place a hold in order to expedite a cross shipment(nothing outlandish there).

Since the original owner should not be liable for this, I let them know that I had ownership of the ram and would like to use my card and address to secure the cross-shipment.

They responded back saying that their warranty was not transferable.

At this point, I go to their website and read their warranty policies(see the quoted text at the end of this post). Nothing in there about being non-transferable or limited in any way other than direct physical abuse.

I respond back to my contact with this, to me, reasonable view of their warranty, and they once again said that their warranty was not transferable.

At this point I requested contact from the supervisor and have, as yet, received no response. Hence my dilemma. This RAM is about a year old, has verifiable problems, the warranty(as far as I can tell) should still be valid, but they won't do anything about it. The really interesting part however, is that the original owner CAN request a warranty exchange and I believe that they can use my card and address, but they won't do it if I make the request. What am I missing?

At least for initial owners, they seem good enough at customer service.

-- The Papa



Here the text of their memory warranty page as of 3/1/2007. (screen shot was too difficult to post on blogger. Although, I do have both a screenshot, an HTML dump, and all the emails for my evidence.

All OWC Memory is covered by a Lifetime Advance Replacement Warranty and 30 Day Money Back Guarantee! This warranty shows our commitment and confidence in the product we sell. OWC certifies and tests ALL OWC memory to ensure that this memory meets or exceeds the specifications for those systems a module is listed as being correct/compatible with. Unlike the competition, OWC owns and maintains our own lab that includes nearly every Apple/Mac model we list compatibility for. In addition to the long testing every OWC module undergoes before shipping (most just short test if they test at all), we also continuously batch test modules in the actual machines. You can count on OWC to consistently deliver the top quality memory products you need, correct for your system for a lifetime of reliable operation.

OWC Memory Warranty/Guarantee terms:

Within 15 Days of invoice date*: Should any issue be experienced with a module in a system it is listed to be compatible with, OWC will - At no cost to you, issue a Return Shipment Label that covers the return shipping of said product back to OWC. It will be your choice at that time for OWC to advance ship replacement product or request that OWC provide a full refund for the original product upon it's return to OWC. OWC covers the full cost of returning the product as well as the cost of shipping the replacement.

Within 30 Days of invoice date: Any memory module may be returned for refund or to be exchanged for a different item. Refund/Exchange value provided for memory returned is the lesser of the invoiced price or current web listed selling price. Return must be received within 30 days of the original invoice date, after 30 days - Lifetime Warranty terms apply.

A Lifetime Warranty applies to all OWC Memory items unless otherwise specified. Should your memory product cease to function in a system that module was listed as compatible with at the time of purchase, OWC will replace the module at no cost. At your option, OWC can either advance ship a replacement via a credit card authorization that will be released upon receipt of the original product or do standard replacement whereby OWC will ship the replacement memory upon receipt of the suspect product. In either case, you will be responsible for the return freight to OWC and OWC will be responsible and cover the cost for shipping the replacement product to you.

The OWC Lifetime Warranty on memory does not cover damage that is the result of mishandling, incorrect installation, or incorrect use and is limited only to the OWC memory module. Although relatively rare, the most common mistake we see with memory installation is where a module has been forced into a slot backwards. All memory modules have a notch or notches on the pin connector that connects into the computer's memory slot. The memory slot has corresponding 'blocks/breaks' that
line up with the notches so the correct installation orientation is easy to determine. Sometimes it takes a little bit of force to push a module into the slot and you can remove and re-insert an existing module just to get comfortable with the process. As long as you have taken care to line the notches up, and push the memory in all the way, you'll be good to go every time!

*15 Day DOA Pickup policy applies only for delivery/pickup within the USA.

Gumstick Gentoo - Consolidated Links

I know that it might be difficult to find the location in my tutorial you'd like to start/end, so I decided to consolidate the links with a brief overview of what's covered in each section. Hopefully, this will aid the readers.

Part 1: Know thy Enemy - Portage

• Basic Difficulties of squashing Gentoo into a small space
• Identification of Directories holding much of the storage space
• Overview of tools we will need

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

• Basic definition of Embedded System Development (host, target)
• How to setup your Host for development
• Extracting the Base Gentoo Stage 3 setup

Part 3: Fattening the Turkey

• Developing the core Gentoo system for deployment
• Building kernel with needed options for USB boot
• Editing grub menu.lst for USB boot
  
• Installing X-windows and fluxbox

Part 4: Go forth and Multiply (except for snakes... they're adders)

• Partitioning/Formatting USB Device
• Mounting for deployment
• Deployment of Gentoo onto thumbdrive
• Final setup of Grub.
  

Debian Sarge on USB Thumbdrive

Honestly, I was quite surprised with Debian Sarge. It literally took just installing the OS on a thumb drive for it to work like a charm.

Personally, I downloaded the "businesscard" iso: http://www.debian.org/CD/netinst/

This is a core system that boots your host computer, sets up your network devices, and installs a debian system over the internet. Amazingly, it works like a charm.

The only thing I did to minimize the installation size was to choose "manually select packages" when queried about the type of system I would be using.

At the end I had an ~300MB rootfs with no gui. Adding in Xwindows server and a personally selcted KDE bumped this up to ~650MB (in other words, don't just ad in the KDE meta-package. Choose which parts you really need).

It's sad how simple it really becomes when a Distro like Debian uses an initramfs. I will definitely be looking into iniramfs for my PXE-Based Linux Test Software for work.

Request for Topics

If anyone reading this has a suggestion for Linux topics to cover, I'd be happy to entertain them. I currently am developing multiple root file systems for a new distribution I'm calling "THLinux". All of them will be embedded in nature and fit into as small a footprint as possible.

Currently, I've been working on a ~600-750MB Debian USB drive with KDE and a tar-gziped deployment archive(~256MB download).

Feedback is definitely welcome!

Part 1: Gumstick Gentoo

I redid the time stamps so this flows more logically down the page.

To recap: I have been able to fit a full Gentoo distribution (with X server and Fluxbox) into a 1GB, bootable USB thumb drive. This is from a standard Stage3 install of full glibc (not the experimental uClibc/busybox distributions).


Part 1: Know thy enemy.
----------------------------------------

The major difficulty surrounding any "embedded" install of Gentoo lies in one of its greatest strengths:

PORTAGE

Most people who have installed a Stage3 system without really delving into the particulars of Gentoo probably have one simple question rolling around in their heads:

"Why is Gentoo SOOOOO big when it's a custom-compiled Linux Distribution?!?!?!"

Well, the short answer to this is quite direct. Portage is freaking HUGE! So, what is a Linux Embedded OS Developer (who REALLY likes Gentoo) to do? Why, take out your enemy of course! Figuratively speaking....

Portage has several directories in the file system that it directly manipulates:

• /usr/portage (duh)
• /var/cache
• /var/db
• /var/tmp/portage

Well, that's nice. But there is also another major culprit in shrinking a Gentoo install

• /usr/src

Now that you know the major "hogs" to a Gentoo system, what is one to do? Why quickly, quietly, and methodically "take them out of the picture", of course!

As a teaser... I will let you know some of the standard Linux utilities that you will be using to make this Gumstick Gentoo work:

• mount
• chroot
• emerge
• nano/vim(my tool of choice)
  

Is that it, you ask? Why yes Virginia, that's all you really need!

On to Part 2

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

Part 3: Gumstick Gentoo

To recap, we've identified our trouble (portage tree); we've removed it from our final system; and, we have entered our Stage 3 install via chroot

Part 3: Fattening the Turkey
----------------------------------------

I am assuming that you know how to setup your USE, MAKEOPTS, and CFLAGS options with Gentoo. If not, go read their documentation. They are usually very good.

First things first, we need to be sure we are running the latest and greatest.

# emerge --sync
# emerge portage (if suggested)
# etc-update (if needed)


Ok, now we have the most up-to-date portage and portage tree. What to do? Why make sure we can boot this puppy! That means kernel and bootloader.

Since we will be using this stick on multiple computers, I'd definitely reccommend a microkernel approach except for a few particular modules. Namely, we expect to be putting this on a USB Drive. That means that genkernel would be a great choice since it turns most everything into modules. So:

# emerge gentoo( or vanilla)-sources genkernel grub vim(my editor of choice)
# genkernel --menuconfig all

Note: All the following is from memory, so be lenient on me for minor errors. But, please to notify me of problems!

In your menuconfig, you need to traverse through the tree to both the SCSI the USB Drivers section. Say yes(not M) to the following modules:

EHCI (usb 2.0)
UHCI (the OTHER usb 1.1)
OHCI (usb 1.1)
USB Mass Storage (and all sub modules)
USB HID (and all sub modules)

SCSI devices(your thumb drive will look like a scsi device.)

Exit and save your kernel. From here, genkernel can will take control. However, since you don't have a boot loader configured AND you're in a chroot environment, you'll have to do some boot loader config manually. Also, lets make some easy to use symbolic links in /boot.

# cd /boot
# ln -s {kernel image} vmlinuz
# ln -s {initrd image} initrd.img



Boot Loader:
----------------

Now, you notice that I chose grub as that is my most familiar. So everything in this section is dependant on that.

First thing with grub is that you need to specify what device map to what identifier. For instance.

#vim /boot/grub/device.map (you probably don't have one of these, so this will also create it)

Inside VIM:
- /dev/sda (hd0) #USB Thumbdrive
- /dev/hda (hd1) #in case you have a kernel on the primary IDE drive you wan to use
- /dev/fd0 (fd0) #floppy disk
-

Now, we also need to create a menu for grub.

#vim /boot/grub/menu.lst (also, you probably don't have this one)

Inside VIM:
-
- defalut 0 #which "title" option to boot by default... 0-based
- timeout 5 #5 seconds to change your mind
-
- title Gentoo Stick
- root (hd0,0)
- kernel /boot/vmlinuz ro quiet rootdelay=10
- initrd /boot/initrd.img


Some explaining:

root - in this case, specifies that any "/"(root) directory is on the first partition on the first device in device.map

kernel - path to your kernel... relative to "root" plus any other options

initrd - path to your initrd... relative to "root"

rootdelay=10 - this is a bit of a hack built into 2.6 kernels. It pauses for 10 seconds just before it tries to load your root file system specified on the kernel line. This allows your usb device to actually be detected by drivers that may be a bit slow on the uptake.

NOTE: we have yet to do a "# grub-install" for a very good reason; ie We're ina chroot environment and we don't have our target drive mounted... So, DON'T try it yet.

Now, we just need the fun stuff... a GUI

# emerge fluxbox x11 xfree86-vesa xdm
# echo "exec fluxbox" >> ~.xinitrc
# passwd

Now, we should have a base system configured ready to deploy... What's one to do? Why exit our chroot.

# exit
# umount ~/gentoo/proc
# umount ~/gentoo/sys
# umount ~/gentoo/dev
# umount ~/gentoo/usr/src
# umount ~/gentoo/usr/portage
# umount ~/gentoo/var/cache
# umount ~/gentoo/var/db
# umount ~/gentoo/var/tmp/portage

On to the final Part 4

Part 4: Gumstick Gentoo

To recap, we've built a basic stage3 Gentoo system in a chroot environment. Now, we are ready to deploy that image.

Part 4: Go forth and Multiply (except for snakes... they're adders)
---------------------------------------------------------------------------

Now, we've got a nice prepared stage3 Gentoo ready for deployment. It's even nicer because we have removed our portage tree and have it available for later upgrades.

So now, what do we do? Why deploy our image.

First we need to prep our disk drive. Since Ext3 fs is compiled as a module, this will be a good choice for our final file system. The first step is to create a partitioning scheme. Since flash disk have a limited life span and are damn slow to access, we do NOT want to create a swap partition there. However as a teaser, I'll let you know that it's possible to steal ram from your video card (that's not in use) and turn it into a block device... i.e. perfect swap space.

#fdisk /dev/sd{a,b,c,d}(your drive goes here... and alwas specify it without a number)
fdisk> d(elete all partitions currently on the system)
fdisk> n(ew, create a primary partition that takes up your entire drive)
fdisk> a( set the boot flag on partition 1)
fdisk> w(rite the partition table and exit)

Ok, now we need to create our file system on the new partition, mount the new fs, and deploy our image.

#mkfs.ext3 /dev/sd{a,b,c,d}1 (this time we specify a number because we need the partition)
#tune2fs -c0 -i0 /dev/sd{a,b,c,d}1 (disable error checking... these do have limited writes...
#mount /dev/sd{a,b,c,d}1 /mnt
#cd ~/gentoo
#find . | cpio -pdm{u}{v} /mnt

The command that includes cpio is useful for many reasons. CPIO is an extremely useful backup utility as it can take a stream from FIND and copy the files anywhere you want them. Also, the {u} allows you do to an unconditional overwrite, and the {v} will tell you all about your progress. It should be noted that {p,d,m} are required to maintain your permissions, create needed directories and accept piped names.

Now you have to edit your grub file in such a way that is knowledgeable of the fact that your USB hard drive is trying to be loaded at the same time as you are trying to execute "/sbin/init". I will leave the rest of the configuration up to you except for the usb-specific kernel parameters. The parameter that you will specifically need is "rootdelay={5,10}". This rootdelay command does exactly what it says. It delays trying to activate your root partition for x seconds (5 or 10 as shown above). This will give your kernel enough time to recognize the thumb drive and activate it before the concurrent thread tries to load up your root file system.

After you have configured grub, you can execute the following to attempt an automatic setup.

#grub-install --root-directory=/mnt /dev/sd{a,b,c,}

The root directory tells grub where to look for /boot/grub/ and the other part specifies the MBR of the usb drive you are attempting to set up. If this fails for any reason, you're like going to need to do a manual grub install. That's something for another article.

Now if all went well, you should be able to #umount /mnt and attempt a reboot of your new Gumstick Gentoo.