From Fedora Project Wiki

Fedora CoreOS Test Week
Fedora CoreOS

Date 2023-03-28 to 2023-04-03
Time all week

Website QA/Test Days
IRC #fedora-coreos (webirc)
Mailing list test


Can't make the date?
If you come to this page before or after the test day is completed, your testing is still valuable, and you can use the information on this page to test, file any bugs you find at Fedora CoreOS issue tracker, and add your results to the results section. If this page is more than a month old when you arrive here, please check the current schedule and see if a similar but more recent Test Day is planned or has already happened.

What to test?[edit]

Today's installment of Fedora Test Day will focus on Fedora CoreOS

Who's available?[edit]

The following cast of characters will be available for testing, workarounds, bug fixes, and general discussion ...

For real time help, please join us on the IRC: #fedora-coreos[?] on https://libera.chat/.

Documentation is also available here. Documentation feedback is welcome through chat, mailing list, github tracker and in the form of a pull request to the documentation sources.

Prerequisites for Test Day[edit]

  • Virtual machine (x86_64, aarch64, s390x)
  • Test day Image

Grab images/artifacts/information for the most current next stream release (38) from our download page: https://getfedora.org/en/coreos/download?tab=cloud_operators&stream=next

How to test?[edit]

Run the tests[edit]

Visit the results page and click on the column title links to see the tests that need to be run: most column titles are links to a specific test case. Follow the instructions there, then enter your results by clicking the Enter result button for the test.

Reporting bugs[edit]

Please report all bugs, issues or enhancement proposals to the Fedora CoreOS issue tracker.

If you are unsure about exactly how to file the report or what other information to include, just ask on IRC #fedora-coreos[?], #fedora-test-day[?] or #fedora-qa[?] and we will help you.

Test Results[edit]

Installation[edit]

User Profile Virtual install Bare Metal install References
azukku
Pass pass
[1]
Pass pass
[2]
Pass pass
[3]
  1. All worked fine for me : 1. rpm-ostree install 2. rpm-ostree kargs --append 3. rpm-ostree kargs --delete 4. static IP via ignition kernelArguments
  2. All worked fine for me : 1. rpm-ostree install 2. rpm-ostree kargs --append 3. rpm-ostree kargs --delete
  3. zVM + DASD - all works fine: 1. rpm-ostree install 2. rpm-ostree kargs --append 3. rpm-ostree kargs --delete
brianmcarey 38.20230322.1.0/x86_64/QEMU
Pass pass
danniel 38.20230322.1.0/x86_64/QEMU
Pass pass
donaldsebleung fedora/x86_64/coreos/next (38.20230322.1.0) on QEMU/KVM
Pass pass
garrmcnu 38.20230322.1.0/x86_64/QEMU
Pass pass
geraldosimiao 38.20230322.1.0/x86_64/QEMU
Pass pass
hricky 38.20230322.1.0/x86_64/QEMU
Pass pass
Pass pass
pnemade 38.20230322.1.0/x86_64/QEMU
Pass pass
sayaksarkar 38.20230322.1.0/x86_64/QEMU
Pass pass
vishalvvr 38.20230322.1.0/x86_64/QEMU
Pass pass

S90x[edit]

User Profile Virtual install Bare Metal install IBM Cloud References
azukku
Pass pass
[1]
Pass pass
[2]
Pass pass
[3]
  1. All worked fine for me : 1. rpm-ostree install 2. rpm-ostree kargs --append 3. rpm-ostree kargs --delete 4. static IP via ignition kernelArguments
  2. All worked fine for me : 1. rpm-ostree install 2. rpm-ostree kargs --append 3. rpm-ostree kargs --delete
  3. zVM + DASD - all works fine: 1. rpm-ostree install 2. rpm-ostree kargs --append 3. rpm-ostree kargs --delete
brianmcarey 38.20230322.1.0/x86_64/QEMU
Pass pass
danniel 38.20230322.1.0/x86_64/QEMU
Pass pass
donaldsebleung fedora/x86_64/coreos/next (38.20230322.1.0) on QEMU/KVM
Pass pass
garrmcnu 38.20230322.1.0/x86_64/QEMU
Pass pass
geraldosimiao 38.20230322.1.0/x86_64/QEMU
Pass pass
hricky 38.20230322.1.0/x86_64/QEMU
Pass pass
Pass pass
lravicha IBM Cloud/s390x/bz2-1x4/Fedora CoreOS 38.20230326.10.0
Pass pass
[1]
  1. Worked fine for me: 1. Download F38 ibmcloud-qcow image 2. create ibm cloud resources for cloud object storage using above qcow 3. create cloud instance using dedicated cloud resources 4. successful ssh to the F38 cloud instance
lravicha https://github.com/LakshmiRavichandran1
Pass pass
[1]
  1. IBM Cloud / s390x / bz2-1x4 / Fedora CoreOS 38.20230326.10.0
mnguyen bx2-2x8
Pass pass
pnemade 38.20230322.1.0/x86_64/QEMU
Pass pass
sayaksarkar 38.20230322.1.0/x86_64/QEMU
Pass pass
vishalvvr 38.20230322.1.0/x86_64/QEMU
Pass pass

Cloud launch[edit]

User Profile AWS Azure GCP DigitalOcean VMWare Exoscale IBM Cloud VirtualBox Vultr OpenStack Alibaba References
apiaseck aws m5.large, fcos next Image: ami-05426870cdf857352,
Pass pass
[1]
  1. A few things did not resonate as straightforward in the documentation for a novice aws user. Since my AWS account was pretty much 'clean' I had to figure out a few details that led me to a successful implementation of this test case. Things that slowed me down: 1. Create private VPC with a set up of subnets with an appropriate pool of IPv4 CIDR 2. Security groups inbound rules / adding the SSH access for the sg 3. Creation of elastic IP, and elastic IP association
dustymabe s-2vcpu-2gb in nyc3
Pass pass
fifofonix Newly provisoned 'next' nodes on vSphere 7.0.3.01200
Pass pass
[1]
  1. Provisioned via terraform. This testing also validated: (i) corproate proxy configuration, (ii) systemd rpm-ostree layering of open-vm-tools.
hhei Launch 38.20230322.1.0 on gcp
Pass pass
[1]
  1. 1. Launch with gcloud using GCP web console, and also add an Ignition file that includes ssh public key with hhei, verify vm works well and hhei can login via ssh. 2. Launch with gcloud from local client, and no any custom instance metadata, verify vm works well and can ssh using $ gcloud compute ssh core@fcos --zone=us-central1-a.
lravicha IBM Cloud/s390x/bz2-1x4/Fedora CoreOS 38.20230326.10.0
Pass pass
[1]
  1. Worked fine for me: 1. Download F38 ibmcloud-qcow image 2. create ibm cloud resources for cloud object storage using above qcow 3. create cloud instance using dedicated cloud resources 4. successful ssh to the F38 cloud instance
lravicha https://github.com/LakshmiRavichandran1
Pass pass
[1]
  1. IBM Cloud / s390x / bz2-1x4 / Fedora CoreOS 38.20230326.10.0
mnguyen bx2-2x8
Pass pass
ravanelli 38.20230322.1.0/x86_64/GCP
Pass pass
ravanelli VirtualBox 7.0.6 r155176 (Qt5.15.2)
Pass pass
[1]
  1. Tested using NAT networking
vishalvvr VirtualBox 6.1.42 r155177 / 38.20230322.1.0 / x86_64
Pass pass

aarch64[edit]

User Profile AWS Virtual install Bare Metal install Raspberry Pi 4 References
dustymabe 8G RPi4
Pass pass
[1]
  1. Used the updated instructions from https://github.com/coreos/fedora-coreos-docs/pull/519
hhei
Fail fail
[1]
  1. Install failed in beaker machine using PXE as downloading signature failed, see https://github.com/coreos/coreos-installer/issues/1158
ravanelli 38.20230322.1.0/aarch64/QEMU
Pass pass

Advanced configuration[edit]

User Profile Static networking Complex partitioning Building containers Containerized service Kernel Tuning (sysctl) Modifying Kernel Arguments OS extensions References
Nemric Next 38 automatically updated from 37 : Bare Metal/x86_64
Pass pass
[1]
Pass pass
  1. Build from a containerized jenkins-agent via podman socket
brianmcarey 38.20230322.1.0/x86_64/QEMU
Pass pass
Pass pass
Pass pass
danniel 38.20230322.1.0/x86_64/QEMU
Pass pass
donaldsebleung fedora/x86_64/coreos/next (38.20230322.1.0) on QEMU/KVM
Pass pass
[1]
  1. Manual, 10.0.2.10/24, GW 10.0.2.2, DNS 10.0.2.3, can access sites such as https://github.com/DonaldKellett with curl
garrmcnu 38.20230322.1.0/x86_64/QEMU
Pass pass
hricky 38.20230322.1.0/x86_64/QEMU
Pass pass
Pass pass
Pass pass
Pass pass
Pass pass
Pass pass
Pass pass
jlebon 38.20230322.1.0/x86_64/QEMU
Pass pass
[1]
Pass pass
[2]
  1. Tested a bunch of different scenarios.
  2. Couldn't test with vim because of the split base pkg problem and the archive repo isn't yet archiving for f38 it seems. Worked with tmux.
ravanelli 38.20230322.1.0/x86_64/GCP
Pass pass
Pass pass

Really Advanced Config[edit]

User Profile Configuring SwapOnZRAM Configuring Time Zone Debugging with Toolbox Customizing NIC name Setting alternatives Node counting KDump via Ignition Nmstate References
Nemric Next 38 automatically updated from 37 : Bare Metal/x86_64
Pass pass
danniel 38.20230322.1.0/x86_64/QEMU
Pass pass
dustymabe
Pass pass
Pass pass
hricky 38.20230322.1.0/x86_64/QEMU
Pass pass
Pass pass
Pass pass
Pass pass
[1]
Pass pass
Pass pass
Pass pass
Pass pass
  1. After removing the extra single quote at the end of the Customize NIC via Udev Rules example, the snippet works as expected.
jlebon 38.20230322.1.0/x86_64/QEMU
Pass pass
Pass pass
Pass pass
[1]
  1. Tested both arming from Ignition and manually.
sayaksarkar 38.20230322.1.0/x86_64/QEMU
Pass pass

Upgrade[edit]

User Profile Switch stream Bootloader updates References
Nemric Next 38 automatically updated from 37 : Bare Metal/x86_64
Pass pass
[1]
  1. Did run the test whithout changing stream (was already on next) show results : sudo bootupctl status Component EFI Installed: grub2-efi-x64-1:2.06-29.fc36.x86_64,shim-x64-15.4-5.x86_64 Update: Available: grub2-efi-x64-1:2.06-88.fc38.x86_64,shim-x64-15.6-2.x86_64 No components are adoptable. CoreOS aleph image ID: fedora-coreos-36.20220410.1.1-metal.x86_64.raw Boot method: EFI After update and successful reboot sudo bootupctl status Component EFI Installed: grub2-efi-x64-1:2.06-88.fc38.x86_64,shim-x64-15.6-2.x86_64 Update: At latest version No components are adoptable. CoreOS aleph image ID: fedora-coreos-36.20220410.1.1-metal.x86_64.raw Boot method: EFI
brianmcarey 38.20230322.1.0/x86_64/QEMU
Pass pass
hricky 38.20230322.1.0/x86_64/QEMU
Pass pass
Pass pass
jlebon 38.20230322.1.0/x86_64/QEMU
Pass pass
[1]
  1. Tested both manual updates and via a bootupd automated systemd service.

Tutorials[edit]

User Profile Autologin Systemd unit service References
apiaseck i7-10610U, 32GB, fcos-37.20230303.3.0-qemu.x86_64.qcow2
Pass pass
[1]
Pass pass
[2]
  1. ignition-validate autologin.ign && echo 'Success!', systemctl cat serial-getty@ttyS0.service, hostnamectl -> Worked as expected. systemctl status --full zincati.service -> Worked as expected. After the `initialization complete, auto-updates logic enabled` it returned a client-side error: [ERROR zincati::cincinnati] failed to check Cincinnati for updates: client-side error
  2. Since I rebooted the laptop, an error popped up related to virbr0 not running: ERROR /usr/libexec/qemu-bridge-helper --use-vnet --br=virbr0 --fd=28: failed to communicate with bridge helper: stderr=failed to get mtu of bridge `virbr0': No such device I restarted the firewall and libvirt, and test completed successfully. $ sudo systemctl restart firewalld \ $ sudo systemctl restart libvirtd
hricky 38.20230322.1.0/x86_64/QEMU
Pass pass
Pass pass

Miscellaneous[edit]

User Profile Documentation Exploratory testing References
apiaseck i7-10610U, 32GB, fcos-37.20230110.3.1-qemu.x86_64.qcow2
Pass pass
[1]
Fail fail
[2]
Fail fail
[3]
  1. Waiting 5 minutes with the system up and running, solves the Issue related to Temporary failure in name resolution. The failed tests in relation to the Testing Fedora CoreOS updates tutorial can be ignored.
  2. The above (pt.1) refers to a [Testing Fedora CoreOS updates](https://docs.fedoraproject.org/en-US/fedora-coreos/tutorial-updates/) tutorial.
  3. After a successful boot of an older fcos instance, systemctl status --full zincati.service -> returns an error: localhost.localdomain zincati[1410]: [ERROR zincati::cincinnati] failed to check Cincinnati for updates: client-side error: error sending request for url (https://updates.coreos.fedoraproject.org/v1/graph?group=default&os_version=37.20230110.3.1&platform=): error trying to connect: dns error. rpm-ostree db diff, returns: `error: No pending or rollback deployment to diff against`
apiaseck i7-10610U, 32GB, fcos-37.20230303.3.0-qemu.x86_64.qcow2
Pass pass
[1]
Pass pass
[2]
Pass pass
[3]
  1. I went through the Launching a user-level systemd unit on boot [tutorial](https://docs.fedoraproject.org/en-US/fedora-coreos/tutorial-user-systemd-unit-on-boot/). Everything worked as expected.
  2. ignition-validate autologin.ign && echo 'Success!', systemctl cat serial-getty@ttyS0.service, hostnamectl -> Worked as expected. systemctl status --full zincati.service worked as expected. After the `initialization complete, auto-updates logic enabled` it returned a client-side error: [ERROR zincati::cincinnati] failed to check Cincinnati for updates: client-side error
  3. I went through the `SSH access and starting containers' [tutorial](https://docs.fedoraproject.org/en-US/fedora-coreos/tutorial-containers/). Everything worked as expected.