Sunday, November 01, 2009

Introducing the Improved Z2 Shell (aka Shell with benefits)

I have been cranking away on my Zipit doing all sorts of neat things with it. I want to first thank all of the folks in #zipit on and of course the fine people at Zipit Wireless (namely rossimo). They have all been a tremendous help in putting this new image together! Also - big shouts to Hunter Davis (the Zipit hacking pioneer).

Today I am releasing the first of what will probably be several versions of the Zipit Shell with some added binaries. The Z2 Shell is freely available for download from the Zipit Wireless "linux hacking" site. I have taken this shell and added all sorts of interesting new compiled binaries (irc, nmap, etc). I have been amassing a growing collections of add-ons to the generic Shell image and some of them required slight modification to the script. This script is rather touchy, and screwing is up will render your Shell image useless. Rather than make people download and assemble all of these little code snippets, I decided to create my own "Shell with benefits".

You can download it here:

Here is a "demonstration" video which was poorly shot and narrated by myself.

IZ2S - The "Improved" Z2 Shell v2.01 - (aka Shell with benefits) from Ray Haque on Vimeo.

Here are the release notes from the included README file ...
IZS - The "Improved Z2 Shell" (aka Shell with Benefits) v2.01

This collection was built by Ray Dios Haque out of sheer necessity. I wanted something that I could play with that would not effect the stock software that comes on the Z2. The easiest way to do that was to take the Z2 Shell that was built by rossimo from Zipit Wireless and expand upon it. I take no credit for his work. Be it known that if I don't mention adding it, it was something that Ross built for us. By the way, thank you Ross. This image has been a lot of fun for me and I hope that by releasing this image of my own I can give something back to the Zipit community.

Format your SD card as a FAT or a FAT16 file system. Copy everything from this zip file onto the root of the card (preserving all paths/directories). Insert your SD card into the Zipit and boot it up. Note that you can only boot this image if you are running the Stock OS that came with your Zipit. If you have installed OpenEmbedded or Debian, then you have probably replaced the stock operating system which included a routine to look for the script. For legal purposes, I cannot provide you this stock operating system. Some of the smarter people in the Zipit community might be able to help you restore this OS (see CHAT below).

Come chat with us! There is a thriving (?) community of the worlds best Zipit hackers who hang out in #zipit on You can fire up 'irc' from this very image and come hang out.

wget, ircii-20090520 (irc), wireless-tools (ifrename, iwconfig, iwevent, iwgetid, iwlist, iwpriv, iwspy), ftp (ftp, /etc/services), unzip (unzipsfx, unzip, funzip), nmap (nmap, *new* ncat), wpa_passphrase, less (lessecho, lesskey), grep

ncurses (libform.a, libform_g.a, libmenu.a, libmenu_g.a, libncurses++.a, libncurses.a libncurses_g.a, libpanel.a, libpanel_g.a)

- Added a routine asking if you would like to configure your wireless card. This was not possible before as there was no scanning routine and the image lacked the wpa_passphrase utility. You can now scan for and configure your wireless settings entirely from the zipit.
- Added "cp /mnt/sd0/etc/services /etc/services" which gives the ftp command the port numbers it needs to function.
- Added "cp -R /mnt/sd0/etc/terminfo /etc", "export TERM=vt102", "export TERMINFO=/etc/terminfo" to help irc understand the screen layout.
- Added "ln -s /mnt/sd0/lib/* /lib" to make ncurses libraries usable, and any future libraries that you or I might add.
- Added "ln -s /mnt/sd0/share /share" for nmap and anything else that might require a "share" directory to be present to function.

- Replaced the stock keyboard driver in /modules with one that was created by Kenyon from the Zipit Yahoo Group. This removed all of the problems with keys not working, or repeating while typing. The original drivers remain, but have been renamed to *.orig.

- A script to download and install "packages" (zip files) using wget, unzip, and a "binary repository" on A similar system could provide updates when I provide them.
- rkdavis from #zipit would like me to add sound to this. I will as soon as I add something to this collection that needs it!
- A terminal based image viewer. I have been messing with a couple, but much of what I have experimented with requires X11 libs. Without X11 on this image that results in some very large and slow moving kludgey code.

IFAQ (InFrequently Asked Questions)
Q. Why does nmap (or some other binary) run so slow?
A. Because everything has to be built "static" to run on the Z2. That means that where you might normally have hundreds of shared libraries on a linux machine, the Z2 Shell must embed the libraries into each running binary. It makes for some bloated inefficient stuff. But, it works. If you want a better system - start writing it! Otherwise, try to limit the actions of what you are doing. For instance, use an address range or port range with nmap. Don't start long running scans on entire networks. This is a Z2 we're talking about. The resources are pretty lean.

Q. How can I add my own binary/package?
A. There are several ways to go about this. The method I have used to compile everything is "scratchbox". Scratchbox is a program which let's you cross-compile applications. That means that you can build stuff for an ARM platform, even though you have a regular x86 machine. It can be tricky and complicated. Try reading up on what I have posted at

Q. Why did you *insert snarky comment here*?
A. If you find that I did something stupid and inefficient, do let me know. I don't claim to have any expertise in the area of building software. If you have some suggestions on how to improve things or would like to help with the next release of this improved Z2 Shell, email me at I would love to collaborate with some folks who might be more talented than myself.

Q. Will you build *insert package name here* for me?
A. Probably. Unless you are asking me to build something that has an endless list of dependencies. In which case I will probably tell you to install OpenEmbedded or full fledged Debian. They all ready have all of these packages. I am only expanding upon the old Z2 Shell because I find it lean and useful.


  1. hmm, there is uclibc toolchain available for scratchbox, uclibc is not that big and complex as glib, just two files to install, the one might be good one to try. And you can still link something static even with uclibc

  2. fanoush - this is pretty exciting stuff. I had no idea that the scratchbox folks offered little code snap-ins like this. I can see why they do though. Lately a lot of my coding struggles have been with run-away gnu tools that don't really understand the environment I have trapped them in. Case-in-point, the ldd tool has been leaping in on me and connecting lib's to binaries while I am trying to build my binaries staticly. I have been looking at using Qemu to try and dodge those problems ... but scratcbox has been much easier to get up and running with.

    Thanks for your comment. I'm going to try this uclib addition. Perhaps then I could get Pidgin/Finch to build!

  3. yes, there are mutiple toolchains to install and use, every scratchbox target can use different toolchain/libc and is independent (except home directory which is shared). when creating another target (run sb-menu inside scratchbox, first item 'setup target', create new) you can select which toolchain/libc you want to use for this new target. You can switch between targets via sb-menu->Select. Personally I have like 10 targets in same scratchbox installation each using different compiler/libc - four arm/glibc and four x86/glibc for maemo 2,3,4,5 and one for uclibc (nokia 770 uses it for boot-time binaries in its initfs partition). it is quite easy. And as said even if you want to build statically, uclibc is beter than glibc. uclibc produced static binaries are much smaller (similar in size to dynamic ones with glibc - static uclibc dropbear has 200KB, dynamic uclibc one has 100KB, see e.g. dropbear and utelnetd binaries here ).

  4. Hmm, when checking your zip it looks like you are already using uclibc at least for some binaries. I'm not sure why dropbear has 500KB then. It can be trimmed down a bit by 'strip -R .comment file' but it is not much. Anyway, after checking your blog a bit more, I see you probably already know everything I mentioned in previous post.