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
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) |
!!! 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.
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
-
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
-
From the
ignition-dracut
repository you made commits in, push yourignition-dracut
changes to your fork of theignition-dracut
repository (any branch is fine).
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 ===================
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`
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:
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.
- Use the userdata in the bug linked above.
- First boot CL, passing in the userdata as cloud-config.
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.
- console prompt before user input is required
- affected commands:
- check-console
- 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:
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-sequential
shows
this around 3/10 times (number occurences of panic
/ number of tests run in the script
).
- Recommended: run the scripts from within the CoreOS SDK chroot (tutorial to create: https://coreos.com/os/docs/latest/sdk-modifying-coreos.html)