Go get your nightly builds here.

After a failed flashing attempt(don’t attempt to tftp flash u-boot.kwb from within U-Boot!) I needed to use JTAG combined with the included JTAG adapter.  To do this, make sure that the UART cable is unplugged, and the JTAG cable is plugged in(unplug/replug the USB adapter just to be safe). First grab the guruplug-installer package, then grab a known-good copy of U-Boot.


$ cd Downloads/
$ tar zxvf Guruplug-installer.tar.gz
$ cd guruplug-installer
$ sudo ./runme.sh ../uboot.guruplug.bin
(lots of scrolling text)


At this point U-Boot is restored, and all that’s needed is to upload a new kernel(and maybe rootfs). Your old kernel won’t work with this new version of U-Boot, so make sure that you have a kernel compiled and ready to use. If you don’t feel like patching(and manually fixing the failed patches) I’ve provided a 2.6.34 kernel for you, complete with modules. To upload the new kernel you’re going to need to attach your GuruPlug to your network with it’s top-facing ethernet interface(near eSATA port).

After attaching the UART cable to the GuruPlug again(and unplugging JTAG, then unplugging/replugging the USB), you’ll need to connect to it with a serial console. On Linux it’s enumerated as /dev/ttyUSB0. My favorite program to do this is simply screen. Start it by issuing the command ‘sudo screen /dev/ttyUSB0 115200′. Afterwards, hit ‘Enter’ a few times to get some output. If no output comes out, power-cycle the Guruplug without removing the UART cable. Press ‘Esc’ to pause it’s automatic booting. This should drop you off at a U-Boot prompt.

To send the kernel over, you’ll have to have a TFTP server set up reachable from the Ethernet cable plugged in to the Guruplug(on Gentoo I used net-ftp/tftp-hpa), issue the following into your working serial prompt:


setenv serverip 192.168.1.2
setenv ipaddr 192.168.1.222

Set the ‘serverip’ variable to the IP address of the TFTP server. Set the ‘ipaddr’ variable to a free IP address on your network. Then issue the following commands:


tftp 0x6400000 kernelImageName
nand erase 0x100000 0x400000
nand write.e 0x6400000 0x100000 0x400000


From here you can type ‘reboot’ to restart the plug and let it boot automatically. Hopefully everything should come up, albeit with some errors along the way(these are due to missing kernel modules). Copy the modules to a USB stock, or wget them on the live plug, then untar them into /lib/modules/2.6.34/. Afterwards, reboot and you should have a happy plug!

Some of the OSUOSL employees attended the recent DefCon 18 conference.  One of the more uncommon features was the conference badge.

In addition to being a ticket for entry into the conference,  it’s also a hackable piece of hardware complete with 128×32 LCD screen, and microprocessor.  The source code for the badge is available online.

Corbin Simpson, a developer at the OSU Open Source Lab spent a large portion of his time at the conference developing and uploading new software onto his badge.  His first badge hacking project was to upload new images to show his appreciation for the lab.

At which point I decided I wanted to try to restore the original kernel, so that I would at least have a working system with which to test.  Therein lied the rub.  The files posted here are completely broken.

Thankfully, a friend of mine also ordered a GuruPlug.  So I grabbed his images. Here’s how to ACTUALLY restore your GuruPlug if you flash a bad kernel to it.

Download the extracted uImage.  This was created by the command ‘dd if=/dev/mtdblock1 of=uImage’.

Download the rootfs from the PlugComputer wiki.

Download the kernel 2.6.32 modules.

Boot your GuruPlug with serial attached and enter the u-boot interface by interrupting it with a keyboard press.

Make sure that you’re running a tftp server. Inside your tftp root, gunzip the uImage.

bkero@ponderosa ~ $ gunzip uImage.gz
bkero@ponderosa ~ $ sudo mv uImage /var/tftp/
bkero@ponderosa ~ $ mv rootfs.ubi.img /var/tftp/


Ensure that an ethernet interface is run between your server and your GuruPlug.  Set your server’s IP to 192.168.2.1.


Marvell>> setenv ipaddr 192.168.2.2
Marvell>> setenv serverip 192.168.2.1
Marvell>> tftp 0x6400000 uImage
Marvell>> nand erase 0x100000 0x400000
Marvell>> nand write.e 0x6400000 0x100000 0x400000

Now your kernel should be flashed to the GuruPlug.  Time to upload the rootfs.


Marvell>> tftp 0x6400000 rootfs.ubi.img
# This will take a few minutes. Get a beer.
Marvell>> nand erase 0x500000 0x1fb00000
Marvell>> nand write.e 0x6400000 0x500000 0x(number of hex bytes flashed)
Marvell>> setenv filesize B940000
Marvell>> setenv fileaddr 6400000
Marvell>> saveenv
Marvell>> reset

At this point your useless GuruBrick should reboot and become a useful GuruPlug again!  You’re almost out of the woods.  Once you boot up you’ll notice that you’re missing a lot of modules, causing a lot of errors on bootup.  We’ll need to reinstall the /lib/modules/2.6.32-stuff directory.  Luckily, we have that packaged.


guruplug-debian:~# apt-get install bzip2
guruplug-debian:~# wget http://code.corbinsimpson.com/modules.tar.bz2
guruplug-debian:~# cd /
guruplug-debian:/# tar xvjpf /root/modules.tar.bz2
guruplug-debian:/# reboot

This should restore your GuruPlug to it’s original functionality!

The RouterStation Pro comes preloaded with a relatively old installation of OpenWRT Kamikaze.  Being a sucker for bleeding-edge software, I definitely wanted to check out code from the main Subversion repository to get it up-to-date as far as development goes.  Here’s how I did it.

bkero@ponderosa ~ $ svn co svn://svn.openwrt.org/openwrt/branches/backfire
bkero@ponderosa ~ $ cd backfire
bkero@ponderosa ~/backfire $ make menuconfig

Now you select some options to specify that we are building an OpenWRT image for a RouterStation Pro:

Target System (Ateros AR71xx/AR7240/AR913x)
Target Profile (Ubiquiti RouterStation Pro)

Select the Exit option by pressing the right arrow key, then hit Enter.  Save the config, then:

bkero@ponderosa ~/backfire $ make -j4

Adjust -j4 for the number of cores in your box(n+1 or n*2) are popular.  This is going to take quite a while, so go to lunch or watch some more Star Trek.

If all goes well, you should have several image files ready.

bkero@ponderosa ~/backfire $ ls bin/ar71xx/
md5sums
openwrt-ar71xx-rootfs.tar.gz
openwrt-ar71xx-root.jffs2-128k
openwrt-ar71xx-root.jffs2-64k
openwrt-ar71xx-root.squashfs
openwrt-ar71xx-root.squashfs-4k
openwrt-ar71xx-ubnt-rspro-jffs2-factory.bin
openwrt-ar71xx-ubnt-rspro-jffs2-sysupgrade.bin
openwrt-ar71xx-ubnt-rspro-squashfs-factory.bin
openwrt-ar71xx-ubnt-rspro-squashfs-sysupgrade.bin
openwrt-ar71xx-uImage-gzip.bin
openwrt-ar71xx-uImage-lzma.bin
openwrt-ar71xx-vmlinux.bin
openwrt-ar71xx-vmlinux.elf
openwrt-ar71xx-vmlinux.gz
openwrt-ar71xx-vmlinux.lzma
packages

We’re concerned with the file “openwrt-ar71xx-ubnt-rspro-squashfs-factory.bin”.  Make sure the box you’re doing this on has the ‘tftp’ package installed.  A second ethernet interface would also be helpful.

Unplug your RouterStation Pro.  Hold the reset button down and plug the power back in.  Hold the reset button down until the RF LED on the front of the board becomes solid.  Plug a computer into the WAN port of your RouterStation Pro.  For some reason it brings up 192.168.1.20 on the WAN port, and the LAN ports become unused.

bkero@ponderosa ~/openwrt/backfire.rspro/bin/ar71xx $ tftp 192.168.1.20
tftp> binary
tftp> put openwrt-ar71xx-ubnt-rspro-squashfs-factory.bin
Sent 2949120 bytes OK.
tftp> quit

Give your router 10 minutes for the recovery process to run.  Plug your computer back into a LAN port and try pinging 192.168.1.20(the default IP).  Mine didn’t come back up alright with the default configuration settings, so I had to hold the reset button down for 20 seconds(LEDs on the board will change).  Afterwards, the router was up and pingable/telnetable at 192.168.1.20.   Telnet in and you’ll be presented with a default installation of OpenWRT.

Right now the system will be probably useless for you.  To install a familiar web interface for configuration, simply install luci:

root@rspro:~$ opkg install luci
root@rspro:~$ passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
root@rspro:~$ /etc/init.d/uhttpd enable
root@rspro:~$ /etc/init.d/uhttpd start
Starting uhttpd... OK

Now point your browser at http://192.168.1.20, and login!

Looks like I’ll be going back to my real incognito mode of simply using another firefox profile and deleting it afterwards.

Link to the  bug

One solution I tried was to turn up the time between tests from 5 minutes to 10 minutes. This still had generated problems, as munin-cron runs still weren’t done after 10 minutes, and any greater time between polls meant subpar graph granularity.

My final solution was to modify munin’s cron entry to the following:


*/7 * * * * munin test \( ! "$(pidof /usr/bin/munin-cron)" \) && test -x /usr/bin/munin-cron && nice -19 /usr/bin/munin-cron


I ran a test to see if there’s still a PID active from munin-cron, and if not check to see if the munin-cron executable exists. If it does exist, run a munin-cron job with the nicest setting possible.

This has solved the problem while still keeping granular graphs, and has significantly reduced the load on the virtual machine.
load average: 0.09, 0.42, 0.38


A tarball of all relevant files can be found here.

All files are hereby released under the GNU Public License version 2, and are apparently copyrighted by Oregon State University.

There are 2 major parts to this system. The first is the cf.classes file, which simply describes which hosts belong in each class. The relevant classes are as follows:

service_munin_host = ( larch )
service_munin_node = ( binhost columbia coos fir fraxinus g1 g2 g3 g4 )
package_munin_node = ( service_munin_node www_phpbb_com )


The second part is the cf.munin file, which holds all the rules that each host should follow. Included are several support files that do such things as generate the munin.conf file, since that is difficult to do by hand.

If you have any questions about how it’s implemented, feel free to drop me a line on IRC and I can help explain things to you.

First off, you’re going to have to install the munin package. You’ll also need to have a web server installed, I prefer apache:

# For Gentoo,
emerge munin apache
# For CentOS/Fedora
yum install munin apache
# For Debian
aptitude install munin apache


Gentoo and CentOS both install the HTTP root in /var/www/localhost/htdocs/munin. After setup, the graphs will be available at http://localhost/munin

Debian requires a bit more attention. Debian munin installs the HTTP root in /var/www/munin. so after the setup, a vhost will have to be created to access it. To do this(on Gentoo) I created an apache vhost file, /etc/apache2/vhosts.d/08_munin.conf. On Debian, the file is the same but the path is different, /etc/apache2/sites-available/08munin


ServerAdmin root@localhost
ServerName munin.blueheaven.ws
DocumentRoot /var/www/localhost/htdocs/munin

Options FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
ServerSignature On



If you set up the Vhost, you’ll need to create the appropriate DNS entry, and kick apache.

/etc/init.d/apache2 reload


Now we have to deal with the configuration of munin itself. There’s only one file for the munin-master configuration, and it resides at /etc/munin/munin.conf. Note: Depending on your operating system, these paths might be different!

dbdir /var/lib/munin
htmldir /var/www/localhost/htdocs/munin
logdir /var/log/munin
rundir /var/run/munin
tmpldir /etc/munin/templates
[ponderosa]
address 127.0.0.1
[colo;fortress.dionysian-mind.net]
address 10.0.9.252
[colo;maetel.dionysian-mind.net]
address 10.0.9.3

Each section beginning with a hostname, such as “[ponderosa]” is a munin-node reached at the address attribute. To group hosts you may prefix them with a a group name followed by a semicolon, such as “[colo;maetel.dionysian-mind.net]“. This will make more sense when you actually see the HTML pages.

There is no munin-master daemon! The munin master is a cron job run by the munin user and resides at /var/spool/cron/crontabs/munin. This file is installed when munin is installed through your package manager.

Ideally that’s all you’ll have to do to set the munin-node up. You could wait 5 minutes and check http://localhost/munin to see if the graphs are generated correctly, or you could try running things by hand to make sure they work properly. Under no circumstances run this as root, you’ll screw up your permissions. To run the munin cron job by hand:

sudo su - munin
/usr/bin/munin-cron


If for some reason the master refuses to work, inspect the logs located in /var/log/munin. Additionally you may netcat/telnet to the node in the same way references in Part I.

If all goes well you should be able to load up http://localhost/munin and view your pretty graphs! If your organization uses cfEngine continue on to Part III to learn about how we use Munin at the OSUOSL.