Skip to content

Commit 5df22d6

Browse files
J-LinarisJ-Linaris
committed
Tutorial 2 inclusion and minor fixes on tutorial 1.
1 parent 1783922 commit 5df22d6

File tree

2 files changed

+158
-1
lines changed

2 files changed

+158
-1
lines changed

‎_posts/2026-03-17-free-software-development-mac0470-tutorial-1.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ sudo virt-customize -a "${VM_DIR_ARM}/arm64_img.qcow2" --root-password password:
3737

3838
in order to reset the password from the local machine using libvirt.
3939

40-
2. cloud-init trying to communicate with a metadata server: Everytime I booted the VM, it kept displaying multiple messages about cloud-init not being able to connect to a server. Later, with the help of Google Gemini this time, I figured it out that this command had to do with the expectation brought when we upload VMs in actual production servers, that try to communicate with metadata servers. This increased considerably my VM's booting time and, therefore, I shut this service down by simply running the command: `sudo virt-customize -a "${VM_DIR_ARM}/arm64_img.qcow2" --run-command "touch /etc/cloud/cloud-init.disabled"`
40+
2. cloud-init trying to communicate with a metadata server: Everytime I booted the VM, it kept displaying multiple messages about cloud-init not being able to connect to a server. Later, with the help of Google Gemini this time, I figured it out that this command had to do with the expectation brought when we upload VMs in actual production servers, that try to communicate with metadata servers. This increased considerably my VM's booting time and, therefore, I shut this service down by simply running the command after booting into the VM: `touch /etc/cloud/cloud-init.disabled`
4141

4242

4343
These two errors were great for me to get to know more about how the VM is set up and the possible bugs when uploading a local VM.

‎_posts/2026-03-24-free-software-dev-mac0470-tutorial-2.md‎

Lines changed: 157 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,157 @@
1+
---
2+
layout: post
3+
title: Free Software Development (MAC0470) Tutorial 1
4+
date: 2026-03-24 13:14 -0300
5+
description:
6+
image:
7+
category:
8+
tags: academic
9+
published: true
10+
sitemap: true
11+
---
12+
13+
# Tutorial 2
14+
15+
## Introduction
16+
17+
After setting the environment up for developing the kernel, the next step in this journey of contributing to the Linux Kernel is to learn how to **configure, compile** and **boot** a customized kernel. Just as a reminder, we will develop for the IIO subsystem kernel tree, one of many Linux Kernel trees (kernel trees are different repositories containing the source code of Linux Kernel). For example, the IIO subsystem is widely applied in the industrial field.
18+
19+
In order to learn how to do these three major tasks, I followed the sequence of steps:
20+
21+
1. Install kw (a system that helps developers of the linux kernel reducing development overhead)
22+
2. Clone a linux tree (IIO subsystem in our case)
23+
3. Configure kw to develop on a local context (set up ssh connection between host and guest)
24+
4. Configure and build the custom linux kernel with kw (20 minutes to compile)
25+
5. Install the modules and boot the customized linux kernel
26+
27+
28+
Once again, I followed the second tutorial created by FLOSS at USP ( [FLUSP](https://flusp.ime.usp.br/) ) from the series of developing for the IIO subsytem. The tutorial is available [here](https://flusp.ime.usp.br/kernel/build-linux-for-arm-kw/).
29+
30+
## Experience on the tutorial
31+
32+
Although this tutorial had 5 steps, I only faced difficulties (a lot of them btw) on the last step, something not really expected. Anyway, let's dive deeper on these challenges:
33+
34+
### `kw` scope
35+
36+
As the first and easily fixable error, after I finished setting up kw inside my `$IIO_TREE` directory, for some reason, I tried to run kw ssh on this iio directory's parent directory. The result:
37+
38+
```
39+
$ kw ssh
40+
We could not reach the remote machine by using:
41+
IP: localhost
42+
User: root
43+
Port: 22
44+
Please ensure that the above info is correct.
45+
Suggestion: Check if your remote machine permits root login via ssh
46+
or check if your public key is in the remote machine.
47+
```
48+
The reason behind this error is a simple concept called "local context". Basically, kw works just like git in this manner, so, if you set it from a directory, most of your settings will only be available in the local environment, hence, the directory you set everything up (somethings like the .config file are considered in a "global" context).
49+
50+
Being honest, who identified this error was the teacher assistant of this discipline, who helped me a lot with this and one of the following errors. Moreover, if you want to diagnose if is it this that is happening to you, you could run:
51+
52+
```bash
53+
kw remote --list
54+
```
55+
56+
In your current directory and in the `$IIO_TREE` directory. This will list every host your kw system can see. To fix this, I simply went to the correct directory and ran the command `kw ssh`.
57+
58+
### Network issues (starting with no console issues)
59+
60+
As I was doing the last step of this tutorial (Installing modules and booting the custom-built Linux kernel), there's a part in which you delete your current VM and recreates a VM with your custom kernel. This was where it all started. First, when I did this, the major problem was:
61+
62+
- I initialized the custom kernel VM and it simply didn't connect my console to the VM's console.
63+
64+
Instead of asking for help (which I did after the following first attempt), I thought that the best solution would be to recreate the VM with the old kernel just to make sure it's all working. After this recreation, I managed to connect my console to the VM, however, everytime I'd try to connect to my VM using ssh, I would see the following error:
65+
66+
```bash
67+
ssh: connect to host <VMs-IP-ADDR> port <Nr-Port>: No route to host
68+
```
69+
70+
First, I tried to analyse the ssh logs both in my host and in my VM, but it led nowhere. After, with the help of Google Gemini, I managed to identify the problem: Basically, there were two factors:
71+
72+
1. My VM's netwrok interface was with the state DOWN, in other words, it was sleeping
73+
2. The IP address my host was looking for was the previously deleted VM's address, so it was basically looking for a ghost
74+
75+
How I diagnosed these errors:
76+
77+
I checked the status of the VM's internet interface and it's IP address using the command:
78+
79+
```bash
80+
@Guest (VM)
81+
ip addr
82+
```
83+
84+
And I checked the IP my host was looking for through libvirt using:
85+
86+
```bash
87+
@Host
88+
sudo virsh net-dhcp-leases default
89+
```
90+
91+
While the VM was running (important detail).
92+
93+
To fix this first network issue, basically, we have to make the internet interface always boot up (otherwise, we will have to boot it up manually all the time) and create a static IP address for the VM in order to facilitate the access (at least, setting a static IP was the solution I found and it seems good enough, given that I will just run this VM in my local network).
94+
95+
#### Making the VM boot up the network interface on boot:
96+
97+
As the first step, I had to figure out what network service my VM was using (NetworkManager? Netplan? systemd-networkd?). To do this, I manually checked if each of this services was running using `systemctl status <service-name>`, hence, the command that showed me that `systemd-networkd.service` is the one my VM is using was:
98+
99+
```bash
100+
systemctl status systemd-networkd.service
101+
```
102+
103+
Having this information in hands, according to systemd-networkd documentation and a post on the legendary Stack Overflow, I had to create a network configuration file that had priority over other network configuration files. The name of my VM's network interface is en1ps0. So, in order of forcing it to have priority, I had to make it be lexically prior to the other files, so I named it `1-en1ps0.network` and placed it under the directory `/etc/systemd/network/`.
104+
105+
Now, we have all the structure we need for the interface to start on boot. However, we actually need to write on this configuration file, which will also solve the second factor we noticed:
106+
107+
#### Setting the network config file and Making the IP address static
108+
109+
To accomplish the goals of making not only the configuration file work but also the connection issues relating to the update of the IP address of the VM from time to time disappear, we must write the configuration file correctly. For writing on this file, I ran:
110+
111+
```bash
112+
sudo nano /etc/systemd/network/1-enp1s0.network
113+
```
114+
115+
Since I chose to create a static IP address in detriment of using DHCP, the configuration file looked like this:
116+
117+
```bash
118+
[Match]
119+
Name=enp1s0
120+
121+
[Network]
122+
DHCP=no
123+
Gateway=<GATEWAY-ADDR>
124+
Address=<IP-ADDR>
125+
```
126+
127+
To get both the gateway and ip addresses, I ran:
128+
129+
```bash
130+
ip r
131+
```
132+
133+
looking for the part "default via <GATEWAY-ADDR>", and:
134+
135+
```bash
136+
ip addr
137+
```
138+
139+
looking for the part "inet: <IP-ADDR>".
140+
141+
[This article](https://askubuntu.com/questions/1391256/systemd-networking-basics-cannot-switch-from-dhcp-to-static-ip-address) was extremely helpful during this process.
142+
143+
After that, I just restarted the networking service on my VM with:
144+
145+
```bash
146+
sudo systemctl restart systemd-networkd.service
147+
```
148+
And it worked!! Now, I was able to ssh to the virtual machine using the ip address I configured on kw. Since it won't change, this problem is solved (I hope).
149+
150+
#### Solution for not connecting the console
151+
152+
As I talked to the teacher assistant of this discipline, he explained to me that this is a common problem, happening to a lot of students. His recommendation was to just keep connecting to the VM using ssh after waiting a while after starting the VM to let it boot properly, which simply solve the problem of lacking access to the VM!
153+
154+
## Conclusion
155+
156+
This tutorial has taught me some things about networking, what makes me really satified with the experience. In the end of the day, now, if I want to test my changes on the IIO subsystem kernel, I "simply" compile it (it took 20 minutes to do this in this tutorial), install the modules on the VM, shutdown and boot again the VM, which is a kind of a simple process now that I've done it once :). Finally, I'm really eager to see what is waiting for me in the next tutorial and what I'll know in the end of this semester.
157+

0 commit comments

Comments
 (0)