HomeLab on dev@iostream.pl

2026-06-17

Wed, 17 Jun 2026 08:15:00 +0200

Continuation of the post Hardware and Software (I)

Odroid M2

The Odroid M2 deserves a dedicated article, as installing and configuring the operating system requires a few extra steps and a fair amount of patience.

The board vendor seems particularly fond of shipping museum-grade software as officially supported images. Personally, I am not a fan of running Ubuntu 20.04 with a 4.9 or 5.1 kernel in 2026. That is not exactly what modern workloads are looking for.

Instead, I strongly recommend using Armbian, whose developers release updates regularly. If you’re impatient, you can always build your own image.

Unfortunately, after installing the official image on an SD card, it quickly becomes apparent that Kubernetes is not particularly happy with the default kernel configuration. The kernel is built with only a minimal set of features enabled, so it is time to roll up your sleeves and build a custom version.

Storage

The Odroid M2 provides an M.2 NVMe slot on the underside of the board, making SSD installation straightforward. Simply insert the drive, secure it using the supplied screw, and enjoy your new storage.

Important: The board cannot boot directly from an NVMe SSD. You must use either an SD card or the built-in eMMC module for booting.

Take a close look at the connectors and switches on the board. One of them controls the SD/eMMC boot source selection. During installation and initial setup, leave it in the Micro SD position.

Building the System

Additional requirements: two SD cards (assuming limited prior experience and the possibility of rebuilding the image later).

Bootstrap

Start by installing the latest version of Armbian onto an SD card and booting from it.

Complete the initial system configuration (passwords, user accounts, locale, and everything else the setup wizard asks for).
Allow your user to execute sudo without a password by adding something similar to /etc/sudoers:

marcin ALL=(ALL) NOPASSWD:ALL

Install git.
Clone the build repository:

git clone --depth 1 https://github.com/armbian/build

Launch the main build script:

cd build
./compile.sh

The script handles the entire build process:

installs missing dependencies,
guides the user through the required configuration,
downloads and builds the kernel,
fetches all remaining packages,
generates a complete system image.

Configuration and Build

Important options in the configuration wizard:

Show a kernel configuration menu before compilation

The default kernel configuration is generally reasonable, but it is worth verifying that options required by Kubernetes are enabled, particularly various netfilter features.

Choose a board → odroidm2
Choose a kernel → current
Choose a release package base → noble

(resolute has recently appeared, but I have not tested it yet.)

Choose image type → Image with console interface
Choose image type (II) → Standard image with console interface

You may spend anywhere from a few minutes to several hours reviewing kernel options, which is why I recommend having a spare SD card available.

Once configuration is complete, the build system will spend quite some time compiling kernels, building packages, and assembling the final image.

During that time, you can:

go for a run,
visit the swimming pool,
ride a bicycle,
or, as a last resort, take a very long walk.

Once the build completes successfully, you should find something similar to the following in output/images:

Armbian-unofficial_26.08.0-trunk_Odroidm2_resolute_current_6.18.35.img

Yes, every locally built image automatically receives the -unofficial suffix.

Writing the Image

Since the device only provides a single SD card slot, you will need to transfer the generated image to your regular workstation and write it to the second SD card.

After that:

shut down the device,
replace the SD card,
power it on,
enjoy your shiny new system,
go through the initial configuration one more time.

Make sure the SSD is visible:

lsblk | grep nvme0

The output should look similar to:

nvme0n1

Installing the System onto eMMC and NVMe

Running from an SD card is useful for diagnostics and experimentation, but the built-in eMMC should be used for everyday operation.

To begin installation:

armbian-install

The most important choice during installation is:

boot from eMMC, root from NVMe

The installer will warn about potential data loss, create fresh partitions on both eMMC and SSD storage, and transfer the already configured system onto the SSD.

As a result, you will not need to repeat the entire setup process again.

Once installation completes:

shut down the device,
remove the SD card,
switch the boot selector to eMMC,
power the board on,
enjoy a significantly faster-booting Odroid M2.

Final System Configuration

The first thing to do is disable swap.

Check whether swap is active:

swapon --show
free -h

Typical output:

NAME TYPE SIZE USED PRIO
/swap.img file 8G 0B -2

Disable it completely:

sudo swapoff -a

If swapon --show reports something like:

/dev/zram0

then zram should be disabled as well:

sudo systemctl disable --now armbian-zram-config

Optionally remove the configuration:

sudo rm -f /etc/default/armbian-zram-config

Kubernetes does not particularly appreciate active swap devices, so it is best to disable them before proceeding further.

Your user account probably no longer has passwordless sudo access, so repeat the same sudoers modification as before.

Finally, replace your SSH keys:

ssh-copy-id marcin@odroidm2

In my case:

ssh-copy-id marcin@10.10.10.24

Voilà. The system is now ready for the next stage.

2026-06-15

Mon, 15 Jun 2026 19:15:00 +0200

This post provides a brief overview of the hardware, installation methods, and software configuration used in my home Kubernetes lab.

Hardware

The cluster currently consists of:

Odroid N2
Odroid M2
Raspberry Pi 5
Raspberry Pi 500
Orange Pi 5 Plus

Among these devices, only the Odroid N2 lacks an M.2 interface for an NVMe SSD and must rely on an SD card for storage. All the others support NVMe drives — well, almost all of them, but we’ll get to that in a moment.

I’m only interested in 2280 form-factor drives due to their lower cost and wider availability.

Let’s take a quick look at what is required to use — and boot from — an NVMe drive on each platform.

Raspberry Pi 5

The Raspberry Pi 5 supports M.2 NVMe storage through an additional PCIe expansion board (HAT). The best option in terms of price and quality is the one made by Pimoroni.

The Internet is full of installation guides, so I’ll keep it brief. The process consists of:

attaching the metal standoffs,
mounting the SSD using the supplied screw,
connecting the ribbon cable,
attaching the HAT to the underside of the Raspberry Pi.

The SSD ends up hidden inside the assembly, between the Raspberry Pi 5 and the HAT itself.

Operating System Installation

There are two ways to install the operating system: with or without an SD card. For the purposes of this project, we’re only interested in Ubuntu Server.

Method 1

The first method is straightforward:

write a standard Raspberry Pi OS image (or any other operating system) to an SD card and boot the Raspberry Pi,
verify that the system can see the SSD:

$ lsblk | grep nvme0

The command should return something similar to:

nvme0n1

Then:

install and launch rpi-imager,
select Ubuntu Server from the operating system list,
choose the NVMe drive as the target device,
start the image-writing process,
shut down the Raspberry Pi,
remove the SD card,
boot the system again.

There is no need to modify the boot order and make NVMe booting the default. It’s useful to retain the ability to boot from an SD card “just in case”.

The Raspberry Pi will still boot from the NVMe drive automatically, albeit a few seconds later. Those extra seconds are hardly a problem.

Method 2

The second method requires an M.2 to USB adapter.

In this case, the operating system image is written directly to the SSD before it is mounted onto the HAT.

Once installed, the Raspberry Pi boots exactly the same way as in the first method.

Configuration

There are two things worth doing immediately after installation:

disable swap,
create a dedicated user account, grant passwordless sudo access, and exchange SSH keys.

You can verify whether swap is enabled using:

$ swapon --show
$ free -h

If swap is active, you’ll likely see something similar to:

NAME TYPE SIZE USED PRIO
/swap.img file 8G 0B -2

Disable swap immediately:

$ sudo swapoff -a

Then remove the corresponding entry from /etc/fstab, for example:

/swap.img none swap sw 0 0

This prevents swap from being re-enabled after a reboot.

Creating a dedicated administrative user is equally simple. Assuming the new user is called marcin, add the following entry to /etc/sudoers:

# marcins and others:
marcin ALL=(ALL) NOPASSWD:ALL

Finally, exchange SSH keys:

$ ssh-copy-id marcin@raspberry-pi-5-address

In my case:

$ ssh-copy-id marcin@10.10.10.21
$ ssh-copy-id marcin@10.10.10.26

With that done, the machine is ready for automation with tools such as Ansible.

In the next installment: Odroid M2 — and there will be quite a bit to talk about.

2026-06-12

Fri, 12 Jun 2026 19:15:00 +0200

Home Kubernetes Lab

I’ve always been a fan of ARM-based single-board computers (SBCs). My journey started with a Raspberry Pi 4, which served as my primary workstation for nearly two years, followed by an Odroid N2. These are simple, reliable devices that are surprisingly versatile—even capable retro-gaming machines.

While the Raspberry Pi 4 has since been replaced by a Raspberry Pi 5, the Odroid N2 remains in active service. It hosts several lightweight databases and web applications and continues to perform flawlessly.

Over time, my collection has expanded to include:

Odroid M2 — the next generation of the Odroid product line,
Orange Pi 5 Plus,
Raspberry Pi 500 — purchased as an impulse bargain.

Hardware Overview

Hostname	palladium	vanadium	iridium	ruthenium	tantalum
SBC Model	ODROID N2	Raspberry Pi 5	ODROID M2	Orange Pi 5 Plus	Raspberry Pi 500
SoC	Amlogic S922X	Broadcom BCM2712	Rockchip RK3588S2	Rockchip RK3588	Broadcom BCM2712
CPU Architecture	4× Cortex-A73 + 2× Cortex-A53	4× Cortex-A76	4× Cortex-A76 + 4× Cortex-A55	4× Cortex-A76 + 4× Cortex-A55	4× Cortex-A76
Memory	4 GB	8 GB	16 GB	16 GB	16 GB
Storage Type	microSD	NVMe	NVMe + eMMC	NVMe	NVMe
Storage Capacity	128 GB	512 GB	512 GB + 64 GB	512 GB	256 GB
Operating System	Armbian	Ubuntu Server	Armbian	Armbian	Ubuntu Server

Retired Systems

Hostname	ferrum	thorium
SBC Model	Radxa Rock Pi S	FriendlyElec NanoPi Neo
SoC	Rockchip RK3308	Allwinner H3
Architecture	64-bit (ARMv8-A)	32-bit (ARMv7-A)
CPU	4× Cortex-A35 @ 1.3 GHz	4× Cortex-A7 @ 1.2 GHz
Memory	512 MB DDR3	512 MB DDR3
Storage Type	microSD	microSD
Storage Capacity	64 GB	64 GB
Operating System	DietPi	DietPi

Objectives

The goal of this project is to build a robust Kubernetes cluster capable of hosting both personal and widely used applications and databases. The cluster should also include a complete platform engineering stack, featuring:

comprehensive observability,
CI/CD pipelines,
GitOps-driven deployments.

Proposed Node Roles

iridium — Kubernetes control plane,
palladium — lightweight worker node and test environment,
vanadium — CI/CD workloads,
tantalum — observability stack,
ruthenium — heavy worker node for resource-intensive web applications.

Tooling

k3s — lightweight Kubernetes distribution,
Ansible — infrastructure automation and configuration management.