| Username | Profile | Virtual install | Bare Metal install | Comments |
|---|---|---|---|---|
| Enter result | Enter result | |||
| azukku | [1] [2] | [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 | |||
| danniel | 38.20230322.1.0/x86_64/QEMU | |||
| donaldsebleung | fedora/x86_64/coreos/next (38.20230322.1.0) on QEMU/KVM | |||
| ersen | v38.20230417.1.0/QEMU | |||
| garrmcnu | 38.20230322.1.0/x86_64/QEMU | |||
| geraldosimiao | 38.20230322.1.0/x86_64/QEMU | |||
| hricky | 38.20230322.1.0/x86_64/QEMU | |||
| pnemade | 38.20230322.1.0/x86_64/QEMU | |||
| sayaksarkar | 38.20230322.1.0/x86_64/QEMU | |||
| vishalvvr | 38.20230322.1.0/x86_64/QEMU |
| Username | Profile | Virtual install | Bare Metal install | IBM Cloud | Comments |
|---|---|---|---|---|---|
| Enter result | Enter result | Enter result | |||
| azukku | [1] [2] | [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 | ||||
| danniel | 38.20230322.1.0/x86_64/QEMU | ||||
| donaldsebleung | fedora/x86_64/coreos/next (38.20230322.1.0) on QEMU/KVM | ||||
| ersen | v38.20230417.1.0/QEMU | ||||
| garrmcnu | 38.20230322.1.0/x86_64/QEMU | ||||
| geraldosimiao | 38.20230322.1.0/x86_64/QEMU | ||||
| hricky | 38.20230322.1.0/x86_64/QEMU | ||||
| lravicha | IBM Cloud/s390x/bz2-1x4/Fedora CoreOS 38.20230326.10.0 | [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 | [1] |
1.
IBM Cloud / s390x / bz2-1x4 / Fedora CoreOS 38.20230326.10.0
|
||
| mnguyen | bx2-2x8 | ||||
| pnemade | 38.20230322.1.0/x86_64/QEMU | ||||
| sayaksarkar | 38.20230322.1.0/x86_64/QEMU | ||||
| vishalvvr | 38.20230322.1.0/x86_64/QEMU |
| Username | Profile | AWS | Azure | GCP | DigitalOcean | VMWare | Exoscale | IBM Cloud | VirtualBox | Vultr | OpenStack | Alibaba | Comments |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | |||
| apiaseck | aws m5.large, fcos next Image: ami-05426870cdf857352, | [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 | ||||||||||||
| fifofonix | Newly provisoned 'next' nodes on vSphere 7.0.3.01200 | [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 | [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 | [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 | [1] |
1.
IBM Cloud / s390x / bz2-1x4 / Fedora CoreOS 38.20230326.10.0
|
||||||||||
| mnguyen | bx2-2x8 | ||||||||||||
| ravanelli | 38.20230322.1.0/x86_64/GCP | ||||||||||||
| ravanelli | VirtualBox 7.0.6 r155176 (Qt5.15.2) | [1] |
1.
Tested using NAT networking
|
||||||||||
| vishalvvr | VirtualBox 6.1.42 r155177 / 38.20230322.1.0 / x86_64 |
| Username | Profile | AWS | Virtual install | Bare Metal install | Raspberry Pi 4 | Comments |
|---|---|---|---|---|---|---|
| Enter result | Enter result | Enter result | Enter result | |||
| dustymabe | 8G RPi4 | [1] |
1.
Used the updated instructions from https://github.com/coreos/fedora-coreos-docs/pull/519
|
|||
| hhei | [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 |
| Username | Profile | Static networking | Complex partitioning | Building containers | Containerized service | Kernel Tuning (sysctl) | Modifying Kernel Arguments | OS extensions | Comments |
|---|---|---|---|---|---|---|---|---|---|
| Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | |||
| Nemric | Next 38 automatically updated from 37 : Bare Metal/x86_64 | [1] |
1.
Build from a containerized jenkins-agent via podman socket
|
||||||
| brianmcarey | 38.20230322.1.0/x86_64/QEMU | ||||||||
| danniel | 38.20230322.1.0/x86_64/QEMU | ||||||||
| donaldsebleung | fedora/x86_64/coreos/next (38.20230322.1.0) on QEMU/KVM | [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 | ||||||||
| hricky | 38.20230322.1.0/x86_64/QEMU | ||||||||
| jlebon | 38.20230322.1.0/x86_64/QEMU | [1] | [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 |
| Username | Profile | Configuring SwapOnZRAM | Configuring Time Zone | Debugging with Toolbox | Customizing NIC name | Setting alternatives | Node counting | KDump via Ignition | Nmstate | Comments |
|---|---|---|---|---|---|---|---|---|---|---|
| Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | Enter result | |||
| Nemric | Next 38 automatically updated from 37 : Bare Metal/x86_64 | |||||||||
| danniel | 38.20230322.1.0/x86_64/QEMU | |||||||||
| dustymabe | ||||||||||
| hricky | 38.20230322.1.0/x86_64/QEMU | [1] |
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 | [1] |
1.
Tested both arming from Ignition and manually.
|
|||||||
| sayaksarkar | 38.20230322.1.0/x86_64/QEMU |
| Username | Profile | Switch stream | Bootloader updates | Comments |
|---|---|---|---|---|
| Enter result | Enter result | |||
| Nemric | Next 38 automatically updated from 37 : Bare Metal/x86_64 | [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 | |||
| hricky | 38.20230322.1.0/x86_64/QEMU | |||
| jlebon | 38.20230322.1.0/x86_64/QEMU | [1] |
1.
Tested both manual updates and via a bootupd automated systemd service.
|
| Username | Profile | Autologin | Systemd unit service | Comments |
|---|---|---|---|---|
| Enter result | Enter result | |||
| apiaseck | i7-10610U, 32GB, fcos-37.20230303.3.0-qemu.x86_64.qcow2 | [1] | [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 |
| Username | Profile | Documentation | Exploratory testing | Comments |
|---|---|---|---|---|
| Enter result | Enter result | |||
| apiaseck | i7-10610U, 32GB, fcos-37.20230110.3.1-qemu.x86_64.qcow2 | [1] [2] [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=3... 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 | [1] [2] | [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. |