Unrar on a RaspberryPi running Raspbian

To my surprise I found that there’s no usable unrar command on my RaspberryPi.
I run Raspbian on it and it so happens that I wanted to unpack a rather large rar file.
The unrar-free package is not good enough for some archives, so that is not an option.

So how to get a working unrar on a Raspbian 8.0? And do you really need it?

Well, there are 2 options that I found, either you use 7zip or if you really want the unrar command, you can build it from Debian source package.

Continue reading “Unrar on a RaspberryPi running Raspbian”

Segfaulting VIM. What?

I got quite the surprise today while opening a file for editing using vim.

fx@teikapi2:~ sudo vim /etc/hosts  
Segmentation fault  

Say what? Vim, segfaulting? Okay.

There was an automatic apt-get upgrade on this machine today, so that is the explanation.
Still quite weird and most definitely not expected.

Quick backtrace under gdb showed:

#0  _dl_lookup_symbol_x (undef_name=0x40a93987 <error: Cannot access memory at address 0x40a93987>, undef_map=undef_map@entry=0x76fff958, ref=ref@entry=0x7efff3ec,
    symbol_scope=symbol_scope@entry=0x76fffb10, version=0x76d1e500, type_class=1, flags=flags@entry=1, skip_map=skip_map@entry=0x0) at dl-lookup.c:715
#1  0x76fdb31c in elf_machine_rel (reloc=0x54abe014, skip_ifunc=<optimized out>, reloc_addr_arg=0x54c7f4a0, version=<optimized out>, sym=0x54b2c384, map=0x76fff958)
    at ../ports/sysdeps/arm/dl-machine.h:377
#2  elf_dynamic_do_Rel (skip_ifunc=<optimized out>, lazy=0, nrelative=<optimized out>, relsize=<optimized out>, reladdr=<optimized out>, map=0x76fff958) at do-rel.h:137
#3  _dl_relocate_object (scope=<optimized out>, reloc_mode=<optimized out>, consider_profiling=<optimized out>, consider_profiling@entry=0) at dl-reloc.c:264
#4  0x76fd23a4 in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:2201
#5  0x76fe5b30 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7efff800, dl_main=0x0) at ../elf/dl-sysdep.c:249
#6  0x76fd3c78 in _dl_start_final (arg=0x7efff800, arg@entry=0x0, info=info@entry=0x7efff580) at rtld.c:330
#7  0x76fd3f08 in _dl_start (arg=0x0) at rtld.c:558
#8  0x76fcfd50 in _start () from /lib/ld-linux-armhf.so.3

So looks like a fail whilst doing ELF dynamic relocation.

Somewhat regretfully, I reinstalled vim and this fixed the problem.

Now, in retrospect, should have saved the binary.
The more I think about it the more interesting this seems.

System testing after upgrades seems like a good idea at this point, ofc that would be an overkill for my poor raspberry Pi that servers mainly as a Samba server at home 🙂

More digging next time, eh?

Systemtap on Debian Jessie

So I wanted to play a bit with Systemtap on Debian Jessie.

I installed it:

sudo apt-get install systemtap  

Afterwards I wanted to run a quick one-liner:

fx@cloudhawk:~$ stap -L 'nd_syscall.*'  
Checking "/lib/modules/3.16.0-4-amd64/build/.config" failed with error: No such file or directory  
Tip: /usr/share/doc/systemtap/README.Debian should help you get started.  

It failed, but hey, at least it provided a clue – the README.Debian file.
So I looked at the provided doc in /usr/share/doc/systemtap/README.Debian.

I mean, you would imagine that this would be the best place to look for tips on how to get it running.

To quote it:

To use systemtap you need to  
manually install the linux-image-*-dbg and linux-header-* packages  
that match your running kernel. To simplify this task you can use the  
stap-prep command. Please always run this before reporting a bug.  

Then it goes on talking about using vim-addon-manager which makes no sense to me.
But ok, so far so good, the doc suggests to run stap-prep.

fx@cloudhawk:~$ sudo stap-prep  
/usr/bin/stap-prep: line 30: rpm: command not found

What the hell? RPM??? Crazy.

And if you look at the script, what it wants to do is to use yum to install the dependencies.
Looks as if someone @Debian just blindly took this from RedHat/Centos.

But all you actually need to get Systemtap going on Debian is to do:

sudo apt-get install systemtap linux-image-`uname -r`-dbg linux-headers-`uname -r`  

As simple as that.
Now it works:

fx@cloudhawk:~$ sudo  stap -L 'nd_syscall.*'|head -n 5  
nd_syscall.accept sockfd:long addr_uaddr:long addrlen_uaddr:long name:string argstr:string  
nd_syscall.accept4 sockfd:long addr_uaddr:long addrlen_uaddr:long flags:long name:string flags_str:string argstr:string  
nd_syscall.access name:string pathname:string mode:long mode_str:string argstr:string  
nd_syscall.acct name:string filename:string argstr:string  
nd_syscall.add_key name:string type_uaddr:long description_uaddr:long payload_uaddr:long plen:long ringid:long argstr:string  


As much as I enjoy hardcore command line stuff, it is nice to have some eye candy there as well.

Like htop, for example.
However I have recently discovered vtop.
Not sure about the practicality of it but it sure looks nice (albeit at the expense of some additional cpu cycles):

If you have node installed then installing vtop is just a matter of running:

sudo npm install -g vtop  

And as if that’s not enough, it supports themes 🙂

Azure + Packer

Yes, it works. How cool is that?
The hardest part is to set up your environment and even that is easy. Kudos to MS.

What you’ll need: a linux machine, golang, packer, Azure plugin for packer, nodejs, Azure cli tools and an Azure subscription.

I’ll start with a clean Ubuntu 14.04 machine.
Let’s start by installing node, npm, git and mercurial (which you’ll need to install the Azure packer plugin).

sudo apt-get install node npm git mercurial  

In Ubuntu node binary is called nodejs because there’s another package called node. One quick fix is to symlink nodejs to node.

sudo ln -s /usr/bin/nodejs /usr/bin/node  

Then we need to install Azure CLI tools. For this we use npm:

sudo npm -g install azure-cli  

And packer. But in order to use Packer and the Azure plugin for Packer you first have to have a recent version of Go (>=1.4).

wget https://storage.googleapis.com/golang/go1.5.1.linux-amd64.tar.gz  

Unpack it somewhere. I use ~/opt/go
Now we set it up

export PATH=$HOME/opt/go/bin:$PATH  
export GOROOT=$HOME/opt/go  
export GOPATH=$HOME/go  

You might want to add these to your shell settings (like .bashrc).
Test by running go version. You should see something like:

fx@azure-playground:~$ go version  
go version go1.5.1 linux/amd64  

Download packer from packer.io and unpack it:

wget https://dl.bintray.com/mitchellh/packer/packer_0.8.6_linux_amd64.zip  
unzip packer_0.8.6_linux_amd64.zip -d packer  

Now, install the Azure plugin for Packer

cd packer  
# the built plugin will be placed in current directory
export GOBIN=$PWD  
go get github.com/MSOpenTech/packer-azure/packer/plugin/...  

Now, set up Azure CLI if you haven’t done so already.
This is as easy as

azure account download  

This will give you a link to download your settings file. This will have to be done using a real browser. Once you have it, set it up:

azure account import ~/azuresubscription.publishsettings  

In order to use packer, you need a storage account:

azure storage account create packer -l "North Europe" -d "My Packer images" --type GRS  

Now is the moment of truth, if everything went well up to now then you should be able to create a packer image.
Let’s create a very minimal packer json file:

  "variables": {
    "sn": "Windows Azure MSDN - Visual Studio Ultimate",
    "ps": "/home/fx/azuresubscription.publishsettings",
    "sa": "packer"
  "builders": [
      "type": "azure",
      "publish_settings_path": "{{user `ps`}}",
      "subscription_name": "{{user `sn`}}",
      "storage_account": "{{user `sa`}}",
      "storage_account_container": "images",
      "os_type": "Linux",
      "os_image_label": "Ubuntu Server 14.04 LTS",
      "location": "North Europe",
      "instance_size": "Small",
      "user_image_label": "Ubuntu1404LTS"
  "provisioners": [
      "execute_command": "chmod +x {{ .Path }}; {{ .Vars }} sudo -E sh '{{ .Path }}'",
      "inline": [
        "sudo apt-get update",
        "sudo apt-get -y upgrade"
      "inline_shebang": "/bin/sh -x",
      "type": "shell"

You can see more examples on github.
Save it as ubuntu.json and check for errors:

./packer validate ubuntu.json

If no errors were reported, go ahead and build it:

./packer build ubuntu.json

Once the build is done you’ll see something like

==> Builds finished. The artifacts of successful builds are:
--> azure: {imageLabel: 'Ubuntu1404LTS',imageName: 'Ubuntu1404LTS_2015-09-27_13-55',mediaLocation: 'https://packer.blob.core.windows.net/images/Ubuntu1404LTS_2015-09-27_13-55-os-2015-09-27.vhd'}

Confirm by running:

azure vm image show Ubuntu1404LTS_2015-09-27_13-55  

Congrats, you have your first Packer image on Azure