Fedora 35 CoreOS 2021-10-11

Fedora CoreOS Test Week

Fedora CoreOS

Date	2021-10-11 to 2021-10-15
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 ...

Development - Dusty Mabe (dustymabe), Jonathan Lebon (jlebon)
Quality Assurance - Kamil Paral (kparal), Sumantro Mukherjee (sumantrom), Geoff Marr (coremodule)

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)
Test day Image

Grab images/artifacts/information for the most current next stream release (35.XZAEXVC.00) 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
bittin		pass
bittin	HP 655		fail pass pass pass pass pass pass
bittin	Virtualbox	pass pass pass pass pass pass pass pass pass pass pass pass
danniel	x86_64, virt-manager	pass	pass
donaldsebleung	FCOS 35.20211003.1.0 with QEMU/KVM on Ubuntu 20.04 host	pass
ersen	x86_64, virt-manager	pass
geraldosimiao	x86_64, virt-manager	pass
hricky	x86_64, virt-manager	pass	pass ^[1]	↑ Pentium(R) Dual-Core CPU E5200 @ 2.50GHz, 3.81G RAM
jaimelm			pass ^[1]	↑ Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz (read: Mac Pro 'trash can')
ravanelli	x86_64, macOs Big Sur, VirtualBox	pass
saqali	VirtualBox (FCOS 35.20211010.1.0, 8.6 GiB disk size)	pass ^[1]		↑ Initially tried with 8.0 GiB disk size after reading that the root filesystem needs to be 8GiB. The additional partitions created brought the root filesystem to 7.5GiB so I received a warning on SSH. After retrying with a disk size of 8.6 GiB, I didn't have these problems.

Cloud launch[edit]

User	Profile	AWS	Azure	GCP	DigitalOcean	IBM Cloud	OpenStack	Alibaba	References
akumar99	ami-08a2a4f6f7a90e59f, t2.micro, us-east-1	fail ^[1]							↑ Applied security group with all ports and IPv4s open. Unable to ping the instance. System reachability check passed but Instance status checks is stuck at initialization. ssh cannot proceed as well. Tried with the image in ap-south-1 but same results.
alciregi	Digitalocean droplet				pass ^[1]				↑ https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-digitalocean/#_launching_a_droplet - The "user data" link leads to a 404 digitalocean page
donaldsebleung	FCOS 35.20211003.1.0 with SSH key pair only on AWS web interface	fail ^[1] warn ^[2] fail ^[3]							↑ Confirmed the issue after a good night's sleep. Tested both FCOS 35.20211003.1.0 (next) and FCOS 34.20210919.3.0 (stable) with identical SSH key pair and security group. Next is unreachable via SSH (ssh timed out) and fails instance reachability check while stable is reachable via SSH and passes both checks as expected. ↑ Previous comment is incorrect as I confused Ubuntu instance IP with FCOS instance IP. However, FCOS instance is unreachable via SSH (ssh hangs indefinitely) and AWS web interface reports "1/2 checks passed" for FCOS instance; in particular, "instance reachability check failed". ↑ Attempting to run `ssh core@$PUBLIC_IP` gives "Permission denied (publickey)" error, even after allowing the instance a few minutes to stabilize. For reference, I created an Ubuntu 20.04 server instance with identical SSH key pair and security group, and was able to successfully SSH into that instance, ruling out configuration error on my part.
dustymabe	35.20211017.1.0 on ibmcloud bx2-2x8 instance					pass ^[1]			↑ Everything looked good. Will PR slight tweaks to the docs.
hhei	35.20211010.1.0 next		fail ^[1] pass ^[2]						↑ Login fcos VM, and test "modifying kernel arguments", except the `sudo rpm-ostree kargs --editor` get "No changes." issue(https ://github.com/coreos/rpm-ostree/issues/3182), other results are OK ↑ Launch fcos VM on azure and `ssh core@ipaddress` successfully, doc is good
hhei	35.20211010.1.0 next, testing CoreOS Azure and "CoreOS modifying kernel arguments"		fail ^[1] fail ^[2]						↑ Test with "CoreOS Azure", launch coreos VM on azure and can ssh successfully Test with "CoreOS modifying kernel arguments", except the `sudo rpm-ostree kargs --editor` get "No changes." issue(https://github.com/coreos/rpm-ostree/issues/3182), other results are OK ↑ 1. Test "Testcase CoreOS Azure", result is PASSED, and doc is good 2. Test "CoreOS modifying kernel arguments", except https://github.com/coreos/rpm-ostree/issues/3182, other results and doc are OK
jlebon	35.20211010.1.0						pass ^[1]		↑ Tested with and without Ignition config
jlebon	35.20211010.1.0; no Ignition config						pass
jmarrero				pass ^[1]					↑ doc update: https://github.com/coreos/fedora-coreos-docs/pull/333
miabbott								pass ^[1]	↑ Ran through the steps to use the cloud provided SSH key and Ignition workflow. Need to make some slight tweaks to the docs, but the steps work great.

aarch64[edit]

User	Profile	AWS	Virtual install	Bare Metal install	References
akumar99	ami-08a2a4f6f7a90e59f, t2.micro, us-east-1	fail ^[1]			↑ Applied security group with all ports and IPv4s open. Unable to ping the instance. System reachability check passed but Instance status checks is stuck at initialization. ssh cannot proceed as well. Tried with the image in ap-south-1 but same results.
bittin			pass
bittin	HP 655			fail pass pass pass pass pass pass
bittin	Virtualbox		pass pass pass pass pass pass pass pass pass pass pass pass
danniel	x86_64, virt-manager		pass	pass
donaldsebleung	FCOS 35.20211003.1.0 with QEMU/KVM on Ubuntu 20.04 host		pass
donaldsebleung	FCOS 35.20211003.1.0 with SSH key pair only on AWS web interface	fail ^[1] warn ^[2] fail ^[3]			↑ Confirmed the issue after a good night's sleep. Tested both FCOS 35.20211003.1.0 (next) and FCOS 34.20210919.3.0 (stable) with identical SSH key pair and security group. Next is unreachable via SSH (ssh timed out) and fails instance reachability check while stable is reachable via SSH and passes both checks as expected. ↑ Previous comment is incorrect as I confused Ubuntu instance IP with FCOS instance IP. However, FCOS instance is unreachable via SSH (ssh hangs indefinitely) and AWS web interface reports "1/2 checks passed" for FCOS instance; in particular, "instance reachability check failed". ↑ Attempting to run `ssh core@$PUBLIC_IP` gives "Permission denied (publickey)" error, even after allowing the instance a few minutes to stabilize. For reference, I created an Ubuntu 20.04 server instance with identical SSH key pair and security group, and was able to successfully SSH into that instance, ruling out configuration error on my part.
ersen	x86_64, virt-manager		pass
geraldosimiao	x86_64, virt-manager		pass
hricky	x86_64, virt-manager		pass	pass ^[1]	↑ Pentium(R) Dual-Core CPU E5200 @ 2.50GHz, 3.81G RAM
jaimelm				pass ^[1]	↑ Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz (read: Mac Pro 'trash can')
ravanelli	x86_64, macOs Big Sur, VirtualBox		pass
saqali	VirtualBox (FCOS 35.20211010.1.0, 8.6 GiB disk size)		pass ^[1]		↑ Initially tried with 8.0 GiB disk size after reading that the root filesystem needs to be 8GiB. The additional partitions created brought the root filesystem to 7.5GiB so I received a warning on SSH. After retrying with a disk size of 8.6 GiB, I didn't have these problems.

Advanced configuration[edit]

User	Profile	Static networking	Complex partitioning	Building containers	Containerized service	Kernel Tuning (sysctl)	Modifying Kernel Arguments	OS extensions	References
danniel	x86_64, virt-manager			pass	pass
donaldsebleung	FCOS 35.20211003.1.0 with QEMU/KVM on Ubuntu 20.04 host	pass ^[1]	pass ^[2] pass ^[3]	pass ^[4]	pass ^[5] pass ^[6]	pass ^[7]			↑ Configured static IP,gateway 10.0.2.100/24,10.0.2.2 with user networking and DNS server 8.8.8.8. Can successfully SSH into FCOS instance and interface details as reported by nmcli conn show ens3 match the configuration ↑ Configured LUKS device at /var/lib/data as per linked example with 16G capacity. Confirmed FCOS system partitioning matches configuration on boot ↑ Configured /var on separate partition with ext4 filesystem as per linked example. Confirmed FCOS system partitioning matches configuration ↑ All test cases (rootless podman, privileged podman, privileged docker) passed ↑ etcd etcd-member.service ↑ busybox hello.service ↑ kernel.sysrq = 0
geraldosimiao	x86_64, virt-manager			pass
hricky	x86_64, virt-manager	pass	pass	pass	pass	pass	pass	pass
mnguyen								warn ^[1]	↑ Needs update to docs. The systemd units needs a `Wants=network-online.target` also otherwise rpm-ostree can't fetch the repoxml because it can't resolve the host for the mirrors.
ravanelli	x86_64, macOs Big Sur, VirtualBox						pass

Upgrade[edit]

User	Profile	Switch stream	Bootloader updates	References
donaldsebleung	FCOS 34.20210919.3.0 with QEMU/KVM on Ubuntu 20.04 host	pass ^[1] pass ^[2] pass ^[3] pass ^[4] pass ^[5] pass		↑ Automatic bootloader update with systemd service ↑ Testcase CoreOS bootupd ↑ Manually configured busybox hello.service survived switch stream ↑ Permanent manual rollback ↑ Temporary rollback
hricky	x86_64, virt-manager	pass

Miscellaneous[edit]

User	Profile	Documentation	Exploratory testing	References

[1] Pentium(R) Dual-Core CPU E5200 @ 2.50GHz, 3.81G RAM

[2] Intel(R) Xeon(R) CPU E5-1620 v2 @ 3.70GHz (read: Mac Pro 'trash can')

[3] Initially tried with 8.0 GiB disk size after reading that the root filesystem needs to be 8GiB. The additional partitions created brought the root filesystem to 7.5GiB so I received a warning on SSH. After retrying with a disk size of 8.6 GiB, I didn't have these problems.

[4] Applied security group with all ports and IPv4s open. Unable to ping the instance. System reachability check passed but Instance status checks is stuck at initialization. ssh cannot proceed as well. Tried with the image in ap-south-1 but same results.

[5] ttps://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-digitalocean/#_launching_a_droplet - The "user data" link leads to a 404 digitalocean page

[6] Confirmed the issue after a good night's sleep. Tested both FCOS 35.20211003.1.0 (next) and FCOS 34.20210919.3.0 (stable) with identical SSH key pair and security group. Next is unreachable via SSH (ssh timed out) and fails instance reachability check while stable is reachable via SSH and passes both checks as expected.

[7] Previous comment is incorrect as I confused Ubuntu instance IP with FCOS instance IP. However, FCOS instance is unreachable via SSH (ssh hangs indefinitely) and AWS web interface reports "1/2 checks passed" for FCOS instance; in particular, "instance reachability check failed".

[8] Attempting to run ssh core@$PUBLIC_IP gives "Permission denied (publickey)" error, even after allowing the instance a few minutes to stabilize. For reference, I created an Ubuntu 20.04 server instance with identical SSH key pair and security group, and was able to successfully SSH into that instance, ruling out configuration error on my part.

[9] Everything looked good. Will PR slight tweaks to the docs.

[10] Login fcos VM, and test "modifying kernel arguments", except the sudo rpm-ostree kargs --editor get "No changes." issue(https ://github.com/coreos/rpm-ostree/issues/3182), other results are OK

[11] Launch fcos VM on azure and ssh core@ipaddress successfully, doc is good

[12] Test with "CoreOS Azure", launch coreos VM on azure and can ssh successfully Test with "CoreOS modifying kernel arguments", except the sudo rpm-ostree kargs --editor get "No changes." issue(https://github.com/coreos/rpm-ostree/issues/3182), other results are OK

[13] 1. Test "Testcase CoreOS Azure", result is PASSED, and doc is good 2. Test "CoreOS modifying kernel arguments", except https://github.com/coreos/rpm-ostree/issues/3182, other results and doc are OK

[14] Tested with and without Ignition config

[1]

[1]

[1]

[1]

[1]

[1]

[2]

[3]

[1]

[1]

[2]

[1]

[2]

[1]

[1]

[1]

[1]

[1]

[2]

[3]

[1]

[1]

[1]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[1]

[1]

[2]

[3]

[4]

[5]

Search

Test Day:Fedora 35 CoreOS 2021-10-11

Contents