Fedora CoreOS Edition requirements
These requirements apply only to the Fedora CoreOS edition.
Correct checksums
A correct checksum must be published for each official release image.
Violations of this criterion for release-blocking images are considered "automatic blockers", they do not have to go through the review process. See QA:SOP_blocker_bug_process#Automatic_blockers for more details on the automatic blocker procedure.
Initialization requirements
Release-blocking images must boot
All release-blocking images must boot in their supported configurations.
Supported architectures are the Fedora primary architectures. All images are not necessarily expected to be available for all primary architectures.
Release-blocking images must boot from all system firmware types that are commonly found on the primary architectures. For the x86_64 architecture, UEFI with Secure Boot configured in accordance with Microsoft's Windows certification requirements is considered a 'commonly found' firmware type.
Supported ARM platforms are those listed by the ARM team at Architectures/ARM/Supported_Platforms.
Supported IoT platforms are those listed by the IoT team here.
Supported FCOS platforms are those listed by FCOS are RPi4, Rpi3b, Allwinner, lorem ipsum.
Supported FCOS platforms are those listed by FCOShere
Release-blocking cloud images must boot in the Fedora OpenStack Cloud and in Amazon EC2.
Release-blocking live and dedicated installer images must boot when written to a USB stick with at least one of the officially supported methods. Release-blocking ARM disk images must boot when written to a medium bootable by the platform under test, according to the instructions for the platform under test.
System-specific bugs don't necessarily constitute an infringement of this criterion - for instance, if the image fails to boot because of a bug in some specific system's firmware, that is unlikely to constitute a violation unless the system is an extremely popular one. See Blocker_Bug_FAQ for more discussion of this.
Expected image boot behavior
- Release-blocking dedicated installer images must boot to the expected boot menu, and then after a reasonable timeout to the installer.
- Release-blocking live images must boot to the expected boot menu, and then to a desktop or to a login prompt where it is clear how to log in to a desktop.
- Release-blocking ARM disk images must boot to the initial-setup utility.
- Release-blocking cloud images must allow login with the user authentication configuration requested during instance creation.
- Release blocking IoT images must boot and be configurable by the Zezere utility.
The boot menu for all supported installer and live images should include an entry which causes both installation and the installed system to attempt to use a generic, highly compatible video driver (such as 'vesa').
System-specific bugs don't necessarily constitute an infringement of this criterion - for instance, if the installer or desktop fails to start because of a bug in support for some specific graphics card, that is unlikely to constitute a violation. See Blocker_Bug_FAQ for more discussion of this.
- Bugzilla: #614488 was proposed as Alpha blocker for F14. Bug was fixed before before blocker status was confirmed or rejected.
- Proposed 2010-07-16.
- Implemented 2010-07-23.
- Rewritten as part of major Fedora 19 criteria revision.
- 'Basic graphics' mode portion split between Beta and Final 2019-04-02
- Test cases: see test cases for "Release-blocking images must boot"
Podman container runtime
The Podman container runtime must be present on all images and installed by default when using the ISO installer. It must be possible to deploy a container image.
- Test cases: QA:Testcase_Podman