rfairley

set release 32
set build (fedpkg verrel)
set pkg (string split -m 2 -r - $build)[1]
set tag (koji add-sidetag f$release-build)

fedpkg clone $pkg
cd $pkg
fedpkg request-branch f$release --no-git-branch

rfairley

import solv
import sys

pool = solv.Pool()
pool.setarch()

for r in ('rawhide', 'rawhide-source'):
    repo = pool.add_repo(r)
    f = solv.xfopen(f'/var/cache/dnf/{r}.solv')
    repo.add_solv(f)

rfairley

!!! Note: In process of reworking this - since modules are no longer being used for Rust packages, only an update to the RPM is necessary, but different from the usual workflow for RPM packages. Pending information from Fedora Rust folks on what the new processes without modules is.

Updating fedora-coreos-pinger

I run these steps from a fedora:rawhide container, with the RPM build tools installed inside the container.

To start and provision the container:

podman run --name=rust-dev-rawhide --privileged --net=host -v /path/to/working-directory:/srv/work -ti registry.fedoraproject.org/fedora:rawhide

rfairley

Testing ignition-dracut changes locally in Fedora CoreOS

1. Download the Ignition RPM source by cloning the following repository: https://src.fedoraproject.org/rpms/ignition

   git clone https://src.fedoraproject.org/rpms/ignition.git
   cd ignition
   

2. From the ignition-dracut repository you made commits in, push your ignition-dracut changes to your fork of the ignition-dracut repository (any branch is fine).

rfairley

Connecting to a Raspberry Pi through a VPS using a reverse SSH tunnel

SSH (Secure Shell) to a host existing in an internal network through a reverse-tunneled SSH connection to an externally accessible VPS (Virtual Private Server). This setup is described where the internal host is a Raspberry Pi, but can be generalized for any host on the internal network that runs an OpenSSH server.

  internal network                                                   Internet                                       home network
                                              ||                                                         ||
 ------------------                           ||                          ------------------             ||             ------------------
|                  | reverse SSH tunnel (VPS $tunnel_port to Pi port 22) |                  |            ||            |                  |
|   Raspberry Pi     ==================================================>         VPS          ===================

rfairley

Silverblue - Nits When Setting Up Podman Container + Vagrant VM Workflow

This collects some of the reference information I used when setting up my development workflow on Silverblue, and some nits along the way I encountered.

Mostly this applies for a workflow like https://github.com/projectatomic/rpm-ostree/tree/master/vagrant.

After installing vagrant-libvirt (e.g. after rpm-ostree install vagrant-libvirt and rebooting), you may need to do the following, otherwise vagrant can hit permission errors:

sudo restorecon -vR /etc/libvirt`

rfairley

Headless setup

For headless setup using Wifi, follow: https://www.raspberrypi.org/documentation/configuration/wireless/headless.md

An example wpa_supplicant.conf file can be found here, as well as other ways to find the IP address of the RPi (nmap, Apple's Bonjour): https://blog.erratasec.com/2018/08/provisioning-headless-raspberry-pi.html#.XNeVuKQpAaF

The command wpa_passphrase can be used to generate a hash of your Wifi network's security key, instead of store it in plaintext in the wpa_supplicant.conf file.

To initially find the IP address of the RPi, I logged into my home router's admin console to find the DHCP-assigned IP address. After doing that I could ssh pi@<ip address> and add the following unit for later use:

rfairley

Failing coreos-cloudinit config of locksmithd

This shows a failing and a successful case of coreos-cloudint configuring locksmith with the config used in coreos/bugs#2463. 20-cloudinit.conf is written before locksmithd is active, it seems, so this is not the race condition causing the failure. The logs have not revealed the cause of the failure.

The journalctl commands use -t to specify a syslog ID rather than -u for a unit, due to systemd/systemd#2913.

Steps to get logs

• Use the userdata in the bug linked above.
• First boot CL, passing in the userdata as cloud-config.

rfairley

Kola Output Additions

These are additional items I would like to see logged in the terminal, based on recent reading and getting familiar with kola and the Container Linux SDK.

Items

1. console prompt before user input is required

• affected commands:
  • check-console

2. console message indicating a typically long wait time for test to finish

• usually a wait time is before a cluster is spawning - can output a message indicating this
• affected commands:

rfairley

kola-find-bad-output

These are scripts that were handy in getting the panic to appear as a result of the race condition in coreos/bugs#1987. Running run-tests-parallel causes the panic to show in journal.txt around 2/5 times, and run-tests-sequentialshows this around 3/10 times (number occurences of panic / number of tests run in the script).

Prerequisites

• Recommended: run the scripts from within the CoreOS SDK chroot (tutorial to create: https://coreos.com/os/docs/latest/sdk-modifying-coreos.html)