I recently bought a Sharp Netwalker netbook for daily use in class and on the go. One of the parts that I didn’t like was the crusty old Ubuntu 9.04 install that came with it. Thankfully that’s not the only option available to me. I read some reports online that booting from the MicroSD card is possible. I also found a really cool tool in Ubuntu called rootstock. There’s even an android port for it.
I wanted a recent Ubuntu distribution though, which I couldn’t find provided for me online. So I rolled my own, and am reasonably pleased with the results. All of the hardware works, although there are some annoyances, such as no battery meter in the GNOME notification area, and the wireless card isn’t supported by NetworkManager, although still works with iwconfig and wpasupplicant. Additionally, the hotkeys on the top are not bound to any programs.
So here it is.
UPDATE: Commenters brought it to my attention that the link I posted may not work for some people. If that is the case, please try downloading from here, or here. Thank you.
To install this guy, format an SD card with one big ext3 partition and untar the tarball to it.
$ wget http://files.blueheaven.ws/netwalker/netwalker-lucid-0.1.tar.bz2
$ sudo fdisk /dev/mmcblk0 # Make a big partition
$ sudo mkfs.ext3 /dev/mmcblk0p1
$ sudo mount /dev/mmcblk0p1 /mnt
$ cd /mnt
$ sudo tar xvjpf ~/netwalker-lucid.0.1.tar.bz2
$ cd ~
$ sudo umount /mnt
Afterwards, eject it and insert it into the Netwalker(unless you’re doing all this FROM the netwalker). Then shut the system completely off. To boot off of the MicroSD card, hold both mouse buttons down, then press and hold the power button for 2 seconds. Continue holding the mouse buttons down until black text bleeds through the white ‘SHARP’ splash screen. The first boot should take noticeably longer than other boots. The default username and password are both ‘ubuntu’.
I’m currently updating the image to use Ubuntu Maverick, and will publish a new post once I have a working image.
That’s right boys and girls. I’ve started compiling RouterStation Pro OpenWRT nightly builds for all punks who like to live on the edge. From my testing these images are rather stable, and aren’t prone to consistent or serious issues. Since this changes nightly your mileage may vary.
Go get your nightly builds here.
I recently had more time to investigate my earlier problems with the GuruPlug. The problem was discovered by some people on the plugcomputer.org forum. The problem stock U-Boot is that is incorrectly reports the arcNumber. The solution then, is to upgrade U-boot!
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.
Continue reading “Upgrading GuruPlug Kernels”
In an effort to upgrade my network from the aging–and failing WRT54G’s, I purchased a RouterStation Pro. A RouterStation Pro is an embedded Linux board with some impressive hardware specs. The part that appealed to me was the 3 Mini-PCI slots that allowed me to use wireless cards that had support in the Linux kernel. There’s a large portion of 802.11N routers that are using Broadcom chipsets which are only supported by a proprietary blob(wl.ko).
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.
Continue reading “RouterStation Pro OpenWRT upgrade”
Recently I’ve migrated my munin instance onto a Linode virtual machine. Having fewer resources was a potential source of problems.
One of the problems that I ran into early on was that sometimes a munin-cron run would still be executing when another munin-cron was scheduled to start. This caused many contention issues, ridiculous load(35+), and once caused a reboot of the VM.
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
At work we use munin and cfEngine extensively, therefore it is accurate to assume that we have a tight-knit setup that allows us to scale munin-node to all hosts in cfEngine, and have the munin-master configured through it as well. This post describes our configuration, and how it takes place. Continue reading “Part III: Munin[node] in cfEngine”
Hopefully you’ve read the first part(Munin-Node), and have one or more nodes already configured. It’s alright if the munin-node is running on the same machine as the munin-master. The master is more of a pain to set up than the client, and could require significantly more debugging. Continue reading “Part II: The Munin-master”
After becoming increasingly frustrated with cacti’s lack of sane repeatable configuration and extensibility I began to explore other options.
Munin showed the most promise and compatibility with many of the services we run at the OSL, such as memcached and varnish. I liked how the plugin system is set up independently on each host, and that each plugin can be managed, configured, and consolidated through symlinks. Continue reading “Part I: Setting up Munin-Node”