Problem

Sometimes you just don’t have a stable (or even functioning network) to leverage when dealing with a piece of hardware. In all my years in Linux admin/development I’ve always worked around this problem with some sort of sneakernet, but there is another way.

Typically when bringing up new hardware one of the most basic interfaces you have is a serial console connection and I just learned recently how to transfer files over that serial console connection rather than requiring a net (tcp/ip) connection.

History

It’s a new year and it has been 5 years since the last time I updated this blog post series. This time I’m updating to Fedora 41 and also bringing forward a lot of changes I’ve made over the last 5 years.

As mentioned previously for now I’m using Fedora Silverblue on my laptop systems and continuing with a BTRFS+snapper setup for my desktop. This series describes the BTRFS+snapper setup.

In the past I have documented this setup and all the steps I took in detail for Fedora 22 (part1 and part2), 24, 25, 27, 29 and 31. This is a condensed continuation of those posts for Fedora 41, but there are a few changes I’ve made.

Recently I looked into enabling and testing multipath on top of iSCSI for Fedora and Red Hat CoreOS. As part of that process I had the opportunity to learn about iSCSI, which I had never played with before. I’d like to document for my future self how to go about setting up an iSCSI server and how to then access the exported devices from another system.

Setting up an iSCSI server

First off there are a few good references that were useful when setting this up. The RHEL 9 documentation for managing storage devices was one. The other was the targetcli man page.

Recently we switched our 9p filesystem usage in CoreOS Assembler to use virtiofs.

This is the technology behind a lot of new lightweight container VM technology like kata-containers and libkrun, but can also be easily used with libvirt.

Running as non-root using qemu:///session

Currently the virtiofs integration doesn’t work as non-root via a qemu:///session connection. There is an oustanding RFE for this upstream and downstream in RHEL that can be followed for updates.

virtiosfs with virt-install

I typically use virt-install to automate creation of my libvirt virtual machines. Using virt-install we can use the --filesystem= and --memorybacking= parameters to get what we want. The --memorybacking= parameter will add shared memory to the instance, which is required for virtiofs.

Earlier this summer I spoke at the Fedora 38 release party about Fedora CoreOS. As part of this I had the privilege of giving the presentation alongside Marc Pusey from Columbia University. Marc talked about how Columbia University uses Fedora CoreOS and his experience participating in the Fedora and Fedora CoreOS communities.

It was a real treat and quite nice to see Fedora CoreOS being applied in such diverse ways for research and learning.

Someone recently asked me about locking down a bond to specific NIC devices within the machine. Specifically they were concerned with the sometimes unpredictable nature of NIC naming in Linux.

While there has been a lot of effort to make NIC naming more predictable, it turns out with the networking configuration stack we are using in Fedora/RHEL (NetworkManager) you don’t even really need to care about the NIC device names if you know the MAC Addresses of the interfaces you want to use.

Note: A more permanent version of this tutorial exists in the Fedora CoreOS documentation.

Fedora CoreOS recently started producing 64-bit ARM (aarch64) artifacts. These images can be used as the Operating System for the Raspberry Pi 4 device. Before trying to get FCOS up and running on your Raspberry Pi4 you’ll want to Update the EEPROM to the latest version and choose how you want to boot the Raspberry Pi 4. There are two options:

A couple of us recently gave an update to our Customer Experience team at Red Hat on the improvements that were made in Red Hat CoreOS for OpenShift 4.6. My part of the presentation focused on the new Live ISO that is now used for Fedora/Red Hat CoreOS installations and also the improvements that we made for being able to copy the install environment networking configuration into the installed system via coreos-installer --copy-network.

Introduction

I recently did a blog post series. showing how to get started with OpenShift OKD on Fedora CoreOS for DigitalOcean. For that series I wrote a script to do most of the heavy lifting because DigitalOcean isn’t a native supported platform by the OpenShift installer.

Today I’ll show off how to get started in GCP, which is supported natively by the OpenShift installer. This makes it much easier to get started because most of the heavy lifting (including infrastructure bringup) is done by the installer itself.

NOTE: The fourth post of this series is available here.

This blog post is the fifth in a series that illustrates how to set up an OpenShift OKD cluster on DigitalOcean.

Back on August 17th I highlighted this blog post series with a presentation and demo for the OKD working group’s Demo Marathon.

The video is posted on YouTube and also available below. If you’re interested take some time and watch the whole process work and see a cluster up and running at the end.