systemd-nspawn

Systemd-nspawn

This is a just a note on how to use systemd-nspawn. On no circumstances should you consider this a total documentation on ”systemd-nspawn” , im just trying to figure out how it works and what i can do with it.

Lets start from the beginning

We need a file system

There are probably 100 ways of getting a file system. one way is to use:

Here is a link to get more information. But to download the zesty ubuntu to the ubuntu directory, here is the command:

a more elaborate way is to specify more options e.g:

 

 

Another way to get  a root-filesystem is to use  alpine. This will download an root file system which can be extracted. Though some changes needs to be done to actually have it working i.e the tty should be changed, see this script for more information. So now that we have the root file system we need to launch the actual container.

Systemd-nspawn

To be able to login to any the new linux system it’s most of the time necessary to set the root password. This can be done by running one program from the file system

e.g

This will start passwd and enables the reset of the password. The same thing applies to the alpine

Now that the password is set , its time to startup the actual container.

This should start a clean ubuntu. Neat and tidy!

Sometimes it’s crucial to have some of the system from the host machine mounted in the container image.  This is done with the help of the bind option.

This will mount the /home/fun in the same mount place as the in the container. If you want to mount it somewhere else then use : to separate the host with the target e.g

There are some things still missing though, lets start with networking.

 

Setting up network

First of all we need to setup the dns server.  In Ubuntu this is done via

Unfortunately there seems to be a bug somewhere in the resolvconf package that made the resolving failed with some sort of dnssec problem. I fixed this problem with:

Then restart the resolver

 

first lets check what interfaces there are on the host.

Since the container started with -n, –network-veth which basically uses the same interface for the host and the container. Which is nice, but if you want to run the container as basically a standalone computer, it would be more nice to have its own ip address. There are some different ways of doing this e.g using bridge, macvlan and maybe also ipvlan. The last one I haven’t tried so I’m not going to mention this again in this post. The Bridge is kind of neat, but as i figured I had to setup NAT too.  The easiest way was macvlan, so the rest of this description will be on that.

MACVLAN

So what is it? ”Macvlan and ipvlan are Linux network drivers that exposes underlay or host interfaces directly to VMs or Containers running in the host.” For a more elaborate description read this link. The first thing to do is to create a macvlan device.

this will create a new device (called mymacvlan1) connected to eth0 and is using the bridge mode.  Now if we start the Ubuntu container with:

 

This creates a new device in the container called mv-mymacvlan1, this device gets its own hw address. You can now assign ip address to this device, and it should work as a normal device.  The same thing can be done with a second container and so on. The neat thing with this is that its now possible to connect from one container to another. But , there is always a but! The Host is unable to connect to the containers, this due to there is no route.  This can be fixed by creating a macvlan on the host too, and use that interface to route (see this link )  through this interface.  Though one should be aware that if the eth0 device goes down, all the interfaces looses there connection. Anyhow here is how to do it

 

Now its possible for the host to connect to the containers too.

Cmake

In short here are some CMake things that are good to know.

 

ADD_DEPENDENCIES

Creates dependencies between targets , usually cmake can determine them automatically. add_dependencies typically used to specify inter target dependencies where at least one of the target is a custom target.

Add generator

Creates a generator (babelc) which can be used to generate ipc headers.

set(${RESULT} ${file_var} PARENT_SCOPE)Return from function calls

There are two ways of returning something to the caller.

The first way:

 

This function will create a new variable called BABELC_OUT_DIR which can be accessed by the parent scope. The next approach is to give a resulting variable where the variable name consists and is provided by the caller.

This way the caller provides the variable.

A really nice alias which gives the output of the graph in a coloring way can be added to the .gitconfig file.

 

Thanks to whomever wrote this, its beautiful 🙂

There are some other nice graph ways at
StackOverflow -git graphs

i2c on raspberry

Ok this is it..

This is obviously the first and maybe more for me to remember how I got things to work, more than for you to understand. But if you find it interesting  and useful Im glad i could help out.

Now to my small project, I’m trying to figure out the I2c protocol, and for that I first needed to enable i2c on raspberry pi. This was done using

 

Then choose interfacing options and choose i2c. Not much to it, i kind of remembered that i needed to do a reboot afterwards and if i2c-dev wasn’t enabled in /etc/modules
then add that too.

There are heaps of sites that shows you how to do it, so I want go into it any further.
The next part was to load an i2c program to arduino.
Usually I ony use bare-metal programming , but since i couldn’t be bothered to get a proper i2c library for the AVR and for Servo I just to the used sketch-language or whatever its called.
I used arduino since it has better PWM support, and in this way i could use the i2c between raspberry pi and arduino to steer the servo.

I set the slave address to 0x06 for the arduino

Ok i might have forgotten to add the breadboard layout, so here it is:

Breadboard

The i2c clock/Data is provided in parallell to both the lcd display (which is also using i2c but a different slave address 0x3f).
The master is the raspberry pi.

Anyhow since I didn’t find a useful fritzing model for i2c-lcd screens i just took one with out it, but the green cables are the clock, the yellow are data,black ground and red vcc.

Now the LCD screen that I got had a slave address of 0x3f , the best way to figure out what addresses that different peripherals are using, is to use the command:

Here we can see that 0x06(Arduino) and 0x03f(lcd) is found from the raspberry pi.

Servo

Since this is more or less quick and dirty, get everything up and running with as little effort as possible, the servo was connected to PWM on pin 9 on the Arduino. I use a cheap Micro Servo 9G which is quite crappy, but I bought it really cheap from http://dx.com , there are only three lines for the servo, one which is to PWM,VCC and ground, I used Servo library provided by Arduino, and for debugging purpose i used a serial line, though i haven’t really used it yet, maybe further down the road if I extend this project, this might become useful.

My intention is to send the position of the arm from the raspberry pi over the i2c to the Arduino which will set the right position. The Led will then show what position in degrees the servo has.

 

Raspberry Pi

Since it don’t care to much about speed in this project and the support for i2c and other things are quite good in python, this was my choice.

I used a LCD driver that i got from the link, unfortunately who ever wrote it manage to put in a static address for the LCD i2c slave address. So i had to fix that, other than that i didn’t bother to much, I just wanted it to work as quick as possible. Here is the python program that works fairly good.