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:

cross posted with this Project Atomic blog post

Introduction

RPM-OSTree/OSTree conveniently allows you to rollback if you upgrade and don’t like the upgraded software. This is done by keeping around the old deployment; the old software you booted in to. After a single upgrade you’ll have a booted deployement and the rollback deployment. On the next upgrade the current rollback deployment will be discarded and the current booted deployment will become the new rollback deployment.

Introduction

Earlier this month I was lucky enough to attend the 2018 Fedora Infrastructure Hackfest. It’s always a treat to hang out with some of the people who really make Fedora tick. Sinny Kumari and I were there to help represent the Atomic Working Group, and also get some face time with each other to learn and hack on a few things related to the Atomic Working group.

The Hackfest was held in Paul Frield’s hometown of Fredricksburg, VA. Since I live in Raleigh, NC I decided it would be nice to take the train since I don’t often get to take the train in the southeast. As can be expected the train was a little late, but got us there without a problem and was a pretty good experience.