From Fedora Project Wiki
 
(13 intermediate revisions by the same user not shown)
Line 15: Line 15:
==== Release-blocking images must boot ====
==== Release-blocking images must boot ====
All release-blocking images must boot in their supported configurations.
All release-blocking images must boot in their supported configurations.
[https://docs.fedoraproject.org/en-US/iot/reference-platforms/ here].|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Supported FCOS devices|content=Supported FCOS platforms are those listed by FCOS are RPi4, Rpi3b, Allwinner, lorem ipsum.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Supported FCOS devices|content=Supported FCOS platforms are those listed by FCOS are RPi4, Rpi3b, Allwinner, lorem ipsum.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Supported FCOS Platforms|content=Supported FCOS platforms are those listed by FCOS[https://docs.fedoraproject.org/en-US/fedora-coreos/platforms/#_supported_platforms here]|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Supported FCOS Platforms|content=Supported FCOS platforms are those listed by FCOS[https://docs.fedoraproject.org/en-US/fedora-coreos/platforms/#_supported_platforms here]|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
Line 27: Line 26:
* Release-blocking cloud images must allow login with the user authentication configuration requested during instance creation.
* 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.
* Release blocking IoT images must boot and be configurable by the Zezere utility.
* Release blocking FCOS images must boot and install following the coreos-installer workflow
* ''Release blocking FCOS images must boot and install following the coreos-installer workflow'''''NEW'''
{{hidden|header=Boot menu contents|content=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').|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
 
{{hidden|header=System-specific bugs|content=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.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
==== Remote package sources ====
{{hidden|header=References|content=
When using a release-blocking dedicated installer image, the installer must be able to use HTTP and HTTPS repositories as package sources. Release-blocking network install images must default to a valid publicly-accessible package source.
* [[rhbug:614488|Bugzilla: #614488]] was proposed as Alpha blocker for F14. Bug was fixed before before blocker status was confirmed or rejected.
{{hidden|header=FCOS remote repos|content=
* Proposed [https://lists.fedoraproject.org/pipermail/test/2010-July/092148.html 2010-07-16].
In FCOS, coreos-installer should be able to fetch a remote "rootfs" if needed.FCOS doesn't need any rpms to be pulled in from remote while installing
* Implemented [https://lists.fedoraproject.org/pipermail/test/2010-July/092231.html 2010-07-23].
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
* Rewritten as part of major Fedora 19 criteria revision.
 
* 'Basic graphics' mode portion split between Beta and Final [https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/6QZAKQI3MYMVF5RPUJDRZGQC6LWK2GLM/ 2019-04-02]
==== Media package source ====
* Test cases: see test cases for [[#release-blocking-images-must-boot|"Release-blocking images must boot"]]
When using a dedicated installer image that contains packages, the installer must be able to use the install medium as a package source.
{{hidden|header=FCOS Live Install|content= Fedora CoreOS Live ISO should be able to install completely offline by following [[https://docs.fedoraproject.org/en-US/fedora-coreos/bare-metal/#_installing_from_live_iso this]]
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}


{{anchor|installer-requirements}}
==== Disk selection ====
The user must be able to select which of the disks connected to the system will be affected by the installation process.
{{hidden|header=Other disks not touched|content=coreos-installer should be provide with a disk for installation and no other disk data should be affected. FCOS installer doesn't support dual boot.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
 
==== Storage interfaces ====
The installer must be able to complete an installation using any supported locally connected storage interface.
{{hidden|header=What are they?|content='fcos-installer should be able to successfully complete installation onto a locally connected storage which include PATA, SATA, NVMe, SAS, and SCSI.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
 
==== Disk layouts ====
The coreos-installer must be able to perform a successful installation on a single disk  using automatic partitioning.
{{hidden|header=Details!|content=...well, so long as the disk is big enough, of course. It must work whether the disk is formatted or not and whether or not it contains any existing data - but before Beta, it's OK if it can only install to a disk with existing data by overwriting it.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
 




==== Release-blocking images must boot ====
==== Scripted user creation ====
All release-blocking images must boot in their supported configurations.
The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account.
{{hidden|header=Supported architectures|content=Supported architectures are the Fedora [[Architectures#Primary_Architectures|primary architectures]]. All images are not necessarily expected to be available for all primary architectures.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=References|content= ignition should be able to accomplish this with the [https://docs.fedoraproject.org/en-US/fedora-coreos/authentication/ following steps]  
{{hidden|header=Supported firmware types|content=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.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Supported ARM platforms|content=Supported ARM platforms are those listed by the ARM team at [[Architectures/ARM/Supported_Platforms]].|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Supported IoT devices|content=Supported IoT platforms are those listed by the IoT team [https://docs.fedoraproject.org/en-US/iot/reference-platforms/ here].|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Supported IoT devices|content=Supported IoT platforms are those listed by the IoT team [https://docs.fedoraproject.org/en-US/iot/reference-platforms/ here].|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Supported cloud environments|content=Release-blocking cloud images must boot in the [[Infrastructure/FedoraCloud|Fedora OpenStack Cloud]] and in [https://aws.amazon.com/ec2/ Amazon EC2].|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=Supported media types|content=Release-blocking live and dedicated installer images must boot when written to a USB stick with '''at least one''' of the [[How_to_create_and_use_Live_USB|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.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=System-specific bugs|content=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.|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
{{hidden|header=References|content=
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KICRVUS3YHNTLHY47O5A2XL2C5YMCFIH/ demoting optical support 2016-12-06], [https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/HLXHEB364LOLFHB2RDX6K4DFA4VJIWMF/ implementation 2017-01-17]
Test cases:
* [[QA:Testcase_Boot_default_install]]
* [[QA:Testcase_USB_stick_Live_luc]]
* [[QA:Testcase_USB_stick_Live_litd]]
* [[QA:Testcase_USB_stick_Live_dd]]
* [[QA:Testcase_USB_stick_DVD_litd]]
* [[QA:Testcase_USB_stick_DVD_dd]]
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}


{{anchor|expected-image-boot-behavior}}
==== Guest on current stable release ====
 
The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release.
{{hidden|header=Recommended virtualization technology|content=This criterion applies only to the [[Getting_started_with_virtualization|recommended Fedora virtualization tools]] - the qemu/kvm - libvirt - virt-manager stack. Follow steps [https://docs.fedoraproject.org/en-US/fedora-coreos/provisioning-libvirt/ here] |headerstyle=background:#e5e5e5|fw1=normal|ta1=left}}


=== <span style="text-decoration:underline">Post-install requirements</span> ===
Except where otherwise specified, each of these requirements applies to all supported configurations described.
* services must start correctly
* logging must work
* SELinux must be enabled


==== Podman container runtime ====
==== Podman container runtime ====

Latest revision as of 09:02, 28 July 2022

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.

Automatic blockers

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 FCOS devices

Supported FCOS platforms are those listed by FCOS are RPi4, Rpi3b, Allwinner, lorem ipsum.

Supported FCOS Platforms

Supported FCOS platforms are those listed by FCOShere

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.
  • Release blocking FCOS images must boot and install following the coreos-installer workflowNEW

Remote package sources

When using a release-blocking dedicated installer image, the installer must be able to use HTTP and HTTPS repositories as package sources. Release-blocking network install images must default to a valid publicly-accessible package source.

FCOS remote repos

In FCOS, coreos-installer should be able to fetch a remote "rootfs" if needed.FCOS doesn't need any rpms to be pulled in from remote while installing

Media package source

When using a dedicated installer image that contains packages, the installer must be able to use the install medium as a package source.

FCOS Live Install

Fedora CoreOS Live ISO should be able to install completely offline by following [this]

Disk selection

The user must be able to select which of the disks connected to the system will be affected by the installation process.

Other disks not touched

coreos-installer should be provide with a disk for installation and no other disk data should be affected. FCOS installer doesn't support dual boot.

Storage interfaces

The installer must be able to complete an installation using any supported locally connected storage interface.

What are they?

'fcos-installer should be able to successfully complete installation onto a locally connected storage which include PATA, SATA, NVMe, SAS, and SCSI.

Disk layouts

The coreos-installer must be able to perform a successful installation on a single disk using automatic partitioning.

Details!

...well, so long as the disk is big enough, of course. It must work whether the disk is formatted or not and whether or not it contains any existing data - but before Beta, it's OK if it can only install to a disk with existing data by overwriting it.


Scripted user creation

The scripted installation mechanism must provide a working function for creating local user accounts, including the ability to specify a hashed password, and for specifying a hashed password for the root account.

References

ignition should be able to accomplish this with the following steps

Guest on current stable release

The release must install and boot successfully as a virtual guest in a situation where the virtual host is running the current stable Fedora release.

Recommended virtualization technology

This criterion applies only to the recommended Fedora virtualization tools - the qemu/kvm - libvirt - virt-manager stack. Follow steps here

Post-install requirements

Except where otherwise specified, each of these requirements applies to all supported configurations described.

  • services must start correctly
  • logging must work
  • SELinux must be enabled

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.

References