A recent update to Arch Linux replaced the qemu-kvm package with an updated version of qemu. A side effect of this change is that the qemu-kvm binary is no longer available, and any libvirt guests on your system utilizing that binary will no longer operate. As is typical with Arch, there is no announcement about this incompatible change, and queries to #archlinux will be met with the knowledge, grace and decorum you would expect of that channel:

I’ve set up my Raspberry Pi to communicate with my Arduino via I2C. The Raspberry Pi is a 3.3v device and the Arduino is a 5v device. While in general this means that you need to use a level converter when connecting the two devices, you don’t need to use a level converter when connecting the Arduino to the Raspberry Pi via I2C.

The design of the I2C bus is such that the only device driving a voltage on the bus is the master (in this case, the Raspberry Pi), via pull-up resistors. So when “idle”, the bus is pulled to 3.3v volts by the Pi, which is perfectly safe for the Arduino (and compatible with it’s 5v signaling). To transmit data on the bus, a device brings the bus low by connecting it to ground. In other words, slave devices never drive the bus high. This means that the Raspberry Pi will never see a 5v signal from the Arduino…unless, of course, you make a mistake and accidentally digitalWrite a HIGH value on one of the Arduino’s I2C pins. So don’t do that.

There are several Python libraries out there for interacting with the GPIO pins on a Raspberry Pi:

• RPi.GPIO
• The WiringPi bindings for Python, and
• The Quick2Wire Python API (which depends on Python 3)

All of them are reasonably easy to use, but the Quick2Wire API provides a uniquely useful feature: epoll-enabled GPIO interrupts. This makes it trivial to write code that efficiently waits for and responds to things like button presses.

The following simple example waits for a button press attached to GPIO1 (but refer to the chart in this document to see exactly what that means; this is pin 12 on a Raspberry Pi v2 board) and lights an LED attached to GPIO0 when the button is pressed:

I’ve recently started playing with an Arduino kit I purchased a year ago (and only just now got around to unboxing). I purchased the kit from SparkFun, and it includes a motley collection of resistors, LEDs, a motor, a servo, and more.

I was fiddling around with this exercise, which uses the SoftwareServo library to control a servo. Using this library, you just pass it an angle and the library takes care of everything else, e.g. to rotate to 90 degrees you would do this:

I’ve been reading up on Puppet 3 lately, and came across the following:

XMLRPC was the new hotness when development on Puppet started. Now, XMLRPC is that horrible thing with the XML and the angle brackets and the pain and sad.

(from http://somethingsinistral.net/blog/the-angry-guide-to-puppet-3/)

…which also accurately sums up my feelings when I come across yet another piece of software where someone has decided that XML (or even JSON) is a good user-facing configuration syntax.

In Fedora 17 there are still a number of services that either have not been ported over to systemd or that do not take full advantage of systemd. I’ve been investigating some IP failover solutions recently, including ucarp, which includes only a System-V style init script.

I’ve created a template service for ucarp that will let you start a specific virtual ip like this:

systemctl start ucarp@001

This will start ucarp using settings from /etc/ucarp/vip-001.conf. The unit file is on github and embedded here for your reading pleasure:

I’ve been working with Arch Linux recently, which uses dhcpcd as its default DHCP agent. If you try booting Arch inside an LXC container, you will find that dhcpcd is unable to configure your network interfaces. Running it by hand you will first see the following error:

# dhcpcd eth0
dhcpcd[492]: version 5.6.4 starting
dhcpcd[492]: eth0: if_init: Read-only file system
dhcpcd[492]: eth0: interface not found or invalid

This happens because dhcpcd is trying to modify a sysctl value. Running dhcpcd under strace we see:

I spent some time today looking at systemd (44) under Fedora (17). When stopping an LXC container using lxc-stop, I would always encounter this problem:

# lxc-stop -n node0
lxc-start: Device or resource busy - failed to remove cgroup '/sys/fs/cgroup/systemd/node0

This prevents one from starting a new container with the same name:

# lxc-start -n node0 
lxc-start: Device or resource busy - failed to remove previous cgroup '/sys/fs/cgroup/systemd/node0'
lxc-start: failed to spawn 'node0'
lxc-start: Device or resource busy - failed to remove cgroup '/sys/fs/cgroup/systemd/node0'

You can correct the problem manually by removing all the child cgroups underneath /sys/fs/cgroup/systemd/<container>, like this:

It took me an unreasonably long time to boot an LXC container with working console access. For the record:

When you boot an LXC container, the console appears to be attached to a pts device. For example, when booting with the console attached to your current terminal:

# lxc-start -n node0
...
node0 login: root
Last login: Mon Jan 28 16:35:19 on tty1
[root@node0 ~]# tty
/dev/console
[root@node0 ~]# ls -l /dev/console
crw------- 1 root tty 136, 12 Jan 28 16:36 /dev/console

This is also true when you attach to a container using lxc-console:

I was intrigued by this post on socket activated containers with systemd. The basic premise is:

• systemd opens a socket on the host and listens for connections.
• When a client connections, systemd spawns a new container.
• The host systemd passes the connected socket to the container systemd.
• Services in the container receive these sockets from the container systemd.

This is a very neat idea, since it delegates all the socket listening to the host and only spins up container and service resources when necessary.