Setting Up For The Lab

This lab uses a Fedora CoreOS image and several utilities (fcct, ignition-validate) to introduce a user to provisioning and exploring a Fedora CoreOS system. This lab is written targeting a Linux environment with a working libvirt/kvm setup.

To perform this lab you need to download the tar archive at this link (signed checksum file) and extract it.

We recommend extracting it into your home directory like so:

History

It’s almost 2020. Fedora 31 came out a month back and I’m just getting around to converting my desktop system to Fedora 31. As mentioned before, for my laptop systems I’ve moved on to Fedora Silverblue. As I continue to containerize my workflows I’m moving more and more of my daily workflows into Flatpaks from the Fedora registry, pet containers (via toolbox) and, single purpose containers. As I continue to convert my workflows into containers I’ll stick with the BTRFS+snapper setup for my desktop system, which still has the benefits of being able to snapshot and rollback the entire system by leveraging BTRFS snapshots, and a tool called snapper.

cross posted with this Project Atomic blog post

TL;DR Fedora 29 will be End Of Life soon. With it Fedora Atomic Host will have its last incremental release (based on the Fedora 29 stream). Please move to the Fedora CoreOS preview if you can.

Last year we introduced the plans for Fedora CoreOS including that Fedora CoreOS would be the successor to Fedora Atomic Host and Container Linux (from CoreOS Inc.). As part of that succession plan we decided that Fedora 29 Atomic Host would be the last stream of Fedora Atomic Host to be released.

Introduction

With Fedora CoreOS Ignition is being used to configure nodes on first boot. While Ignition json configs are not intended to be a tool that users typically interact with (we are building tooling like fcct for that) I’ll show you an example of how to deliver a script to a Fedora CoreOS (or RHEL CoreOS) host so that it will be run on first boot.

Write the script

Let’s say we have a small script we want to run that updates the issuegen from console-login-helper-messages to output the node’s public IPv4 address on the serial console during bootup.

Introduction

This is an update to my previous post about easily testing PXE booting by using libvirt + iPXE.

Several people have notified me (thanks Lukas Zapletal and others) that instead of leveraging PXELINUX that I could just use an iPXE script to do the same thing. I hadn’t used iPXE much so here’s an update on how to achieve the same goal using an iPXE script instead of a PXELINUX binary+config.

History

It’s 2019 and I’m just getting around to converting my desktop system to Fedora 29. For my work laptop I’ve moved on to Fedora Silverblue (previously known as Atomic Workstation) and will probably move my desktop there soon too as I’ve had a good experience so far. For now I’ll stick my desktop system to this old setup with BTRFS+snapper where I am able to snapshot and rollback the entire system by leveraging BTRFS snapshots, and a tool called snapper.

Update: A future post explains how to do this even easier without PXELINUX.

Introduction

Occasionally I have a need to test out a PXE install workflow. All of this is super easy if you have a permanent PXE infrastructure you maintain which traditionally has consisted of DHCP, TFTP and HTTP/FTP servers. What if I just have my laptop and want to test something in a VM? It turns out it’s pretty easy to do using libvirt and a simple http server.

cross posted with this Project Atomic blog post

Introduction

This week we put out the first release of Fedora 29 Atomic Host. This will be the last major release of Fedora Atomic Host as we prepare for Fedora CoreOS which will be released in Fedora 30.

In this post we’ll quickly list some known issues and then talk about updating an existing Fedora 28 Atomic Host system to Fedora 29. We’ll cover preparing the system for upgrade and performing the upgrade.

Introduction

Last time I talked about using rpm-ostree-bisect, a tool that I wrote to automatically bisect the history of an OSTree remote in order to find the exact commit when a problem was introduced. I recently put the tool to the test again.

The Problem

Recently a user reported an issue where their system was seeing timeouts on boot. They determined that if they removed the resume=/dev/mapper/fedora-swap argument from the kernel command line then the system would boot without timing out on the swap device (i.e. an extra 90 seconds added to boot time).

Introduction

Occasionally in OS land we’ll come across a bug that snuck its way into a build and has been in the wild for a while before anyone notices it. One example is a recent bug (originally discovered by the community of CoreOS Container Linux) where the jumbo packet MTU size of 9001 was no longer getting set properly on EC2 instances.

So we have this bug, and we know things used to work. I fired up the first and last releases of F28 Atomic Host. Both had the problem. I then went all the way back to the first release of F27 Atomic Host and fired up an AMI from that release. On that release the MTU looks good at 9001: