Saturday, February 28, 2015

cubietruck setup, though my card reader is flaky

Finally setup my cubietruck that I purchased late last year. Here it is under my desk running Fedora 21:

Riveting, I know.

I mostly just followed bits from Rich's and Kashyap's blog posts, and the Fedora ARM install instructions. I used this serial adapter, though note you need to make sure to make sure the TX pin on the board is wired to the RX pin USB end, and vice versa. Probably obvious to some people but I would have been stumped if I hadn't seen it mentioned in an Amazon review.

Everything is working now but my hardware has a bit of a malfunction that I mentioned in this fedora-arm thread. Basically the device can boot off the SD card, but linux doesn't detect it. If I wiggle the card around a lot while inserting it I can get linux to detect it about 1/5 of the time, but after rebooting the device is back to not being detected. In the thread, Hans guessed that the card-detect pin is flaky or not connecting well, but it doesn't affect the cubieboard firmware which just ignores that pin and assumes the device is present.

Since I was planning on using a SATA drive anyways, this isn't that big of a deal, just delete everything on the SD card except u-boot, and the SATA drive will be used /boot and /. But if I ever want to update u-boot on the SD card, I'll have to go through the whole wiggle process again and manually 'dd' it into place using the steps on the Fedora install page.

Monday, February 16, 2015

Fedora 22 Virt Test Day scheduled for Thu Apr 16

Just a quick note that the Fedora 22 Virt Test Day is scheduled for Thursday April 16th. The inprogress landing page is at:

If you're interested in helping out please mark your calendars.

Friday, February 13, 2015

git up: The better git pull

A while ago I stumbled across a nice git extension 'git up'. The README synopsis lays out the motivation:
git pull has two problems:
  • It merges upstream changes by default, when it's really more polite to rebase over them, unless your collaborators enjoy a commit graph that looks like bedhead.
  • It only updates the branch you're currently on, which means git push will shout at you for being behind on branches you don't particularly care about right now.
Solve them once and for all.
As implied above, git-up will update all your branches that are tracking a remote branch. This often comes in handy in fedora git repos:

 [crobinso@colepc openbios (master)]$ fedpkg pull  
 Already up-to-date.  
 [crobinso@colepc openbios (master)]$ git up  
 Fetching origin  
 f20  fast-forwarding...  
 master up to date  
 returning to master  

Another useful bit is that it will stash and unstash uncommitted changes. Often times I find myself doing this:

 [crobinso@colepc ~]$ cd src/virt-manager/  
 # Hack some minor bug fix  
 [crobinso@colepc virt-manager (master *)]$   
 # Oops, I should pull first, maybe the issue is fixed  
 [crobinso@colepc virt-manager (master *)]$ git pull  
 Cannot pull with rebase: You have unstaged changes.  
 Please commit or stash them.  
 [crobinso@colepc virt-manager (master *)]$ git up  
 Fetching origin  
 stashing 1 changes  
 master up to date  
 [crobinso@colepc virt-manager (master *)]$   

Nowadays I don't even attempt the pull, git up is my reflex. (And yes I should just make it a reflex that I switch to a branch before doing any hacking...)

Nice to see that nowadays git-up is packaged in fedora, so grab it with sudo yum install rubygem-git-up

Friday, January 9, 2015

Using git-remote-hg with bitbucket

Occasionally I want to contribute to a project using mercurial on (like pylint). Since I always forget the steps, I'm documenting here how I've managed that without having to actually use mercurial.
  • From, log in, find the repo you want to contribute to, use the web UI to fork it under your account.
  • yum install git-remote-hg
  • Clone your fork using git
    • Generic format is: git clone hg::$URL
    • So for my fork of astroid, the command looks like: git clone hg::ssh://
  • Create a git branch, the name must start with 'branches/' to make mercurial happy when we eventually push things. So something like: git checkout -b branches/myfix
  • Make your changes in the branch
  • Push the branch to your repo: git push origin branches/myfix
  • Use the bitbucket web UI to submit a pull request.
  • That's it.
Though I haven't figured out how to update a pull request... instead I've resorted to closing the first request, creating a new branch on my fork, and submitting a brand new pull request. There's probably some nicer automagic way but I haven't figured it out.

(Hopefully in the near future more of the python ecosystem will move to git.)

Monday, December 15, 2014

Setting up a minimal rbd/ceph server for libvirt testing

In my last post I talked about setting up a minimal gluster server. Similarly this will describe how I set up a minimal single node rbd/ceph server in a VM for libvirt network storage testing.

I pulled info from a few different places and a lot of other reading, but things just weren't working on F21; trying systemctl start ceph just wasn't producing any output, and all the ceph cli commands just hung. I had better success with F20.

The main difficulty was figuring out a working ceph.conf. My VM's IP address is 1902.168.124.101, and its hostname is 'localceph', so here's what I ended up with:

auth cluster required = none
auth service required = none
auth client required = none
osd crush chooseleaf type = 0
osd pool default size = 1

mon data = /data/$name
mon addr =
host = localceph

keyring = /data/keyring.$name
host = localceph

osd data = /data/$name
osd journal = /data/$name/journal
osd journal size = 1000
host = localceph

Ceph setup steps:
  • Cloned an existing F20 VM I had kicking around, using virt-manager's clone wizard. I called it f20-ceph.
  • In the VM, disable firewalld and set selinux to permissive. Not strictly required but I wanted to make this as simple as possible.
  • Setup the ceph server:
    • yum install ceph
    • I needed to set a hostname for my VM, ceph won't accept 'localhost': hostnamectl set-hostname localceph
    • mkdir -p /data/mon.0 /data/osd.0
    • Overwrite /etc/ceph/ceph.conf with the content listed above.
    • mkcephfs -a -c /etc/ceph/ceph.conf
    • service ceph start
    • Prove it works from my host with: sudo mount -t ceph $VM_IPADDRESS:/ /mnt
  • Add some storage for testing:
    • Libvirt only connects to Ceph's block device interface, RBD. The above mount example is _not_ what libvirt will see, it just proves we can talk to the server.
    • Import files within the VM like: rbd import $filename
    • List files with: rbd list
Notable here is that no ceph auth is used. Libvirt supports ceph auth but at this stage I didn't want to deal with it for testing. This setup doesn't match what a real deployment would ever look like.

Here's the pool definition I passed to virsh pool-define on my host:

<pool type='rbd'>
    <host name='$VM_IPADDRESS'/>