Ubuntu PandaBuilder

The DMS has quite a few awesome members, all of them working on amazing individual and group projects. But a little while ago we gained a new member named David Mandalla, and David just so happens to work for Canonical, better known as those awesome folks that make the Ubuntu Linux Distro! Not only does he work for Canonical, but he works on their ARM development team. He mentioned that he had a big project he was working on and many of us, myself included were pretty stoked to see what he had going on.

It seems that Canonical had a problem to solve. They wanted to build Ubuntu and its entire software repository for ARM. The only problem was time. Sure they could cross-compile everything but that could take a seriously long time. What they needed was a native build solution, a device that they could build everything on in a reasonable amount of time and ensuring relative security to all packages. What they came up with is pretty excellent.

This what David refers to as the Panda Builder. An ARM based 4U server comprised of 20 PandaBoards controlled by another Master board that will be used to compile all 20,000+ packages for Canonical. This is really a very slick build, it’s well laid out for optimal air flow, it’s modular design makes it easy to service and it’s not overly complex which provides very few points of failure. Now, let’s get into some spec porn shall we?

Here’s a basic list of the components in the chassis.

(21) PandaBoards
(20) 300 GB SATAII USB Hard Drives
(1) 200A 5V PSU
(1) 100A 12V PSU
(24) Serial Controlled Relays – Mounted on PCBs in arrays of 8
(21) Female CAT5 Ethernet Jacks – Not mounted in picture


In brief the PandaBoards each have an OMAP4430 app processor, 1GB of low-power DDR2 RAM, SD/MMC slot, and HDMI 1.3 connector, 3.5” audio out, 802.11 b/g/n, Bluetooth 2.1, 1 mini USB port, 2 USB 2.0 ports, Onboard 10/100 Ethernet and JTAG headers. All for about $174. Because of how inexpensive these boards were, David was able to build this setup for relatively cheap. So if you’re like me, you probably want to know how it works.

I won’t pretend to be an expert as I have a very indirect knowledge of the server but from talking to David here is the gist that I got. When a ‘customer’ requests time on the server to build and test a package a call is sent to the controller board which then queries for another board not in current use, when it finds one it trips that boards respective relay to reboot it, then issues a command to format its hard drive. Once that is complete the board is rebooted again and the controller PXE’s a pristine image of the build environment to the board in question.

This is crucial as it helps ensure the security of the packages being built on the server. Once the environment is booted and ready to go, the controller board hands off the environment to the ‘customer’. Pretty impressive no?
If you liked reading this and want to see more please check out David’s build log at http://dmtechtalk.wordpress.com/


Leave a reply

Your email address will not be published. Required fields are marked *