No edit summary |
|||
| Line 28: | Line 28: | ||
* ''Release blocking FCOS images must boot and install following the coreos-installer workflow'''''NEW''' | * ''Release blocking FCOS images must boot and install following the coreos-installer workflow'''''NEW''' | ||
==== Remote package sources ==== | ==== 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. | 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. | ||
{{hidden|header=FCOS remote repos|content= | {{hidden|header=FCOS remote repos|content= | ||
In FCOS, coreos-installer should be able to fetch a remote "rootfs" if needed. | 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 | ||
|headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | |headerstyle=background:#e5e5e5|fw1=normal|ta1=left}} | ||
Revision as of 08:39, 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.
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 platforms are those listed by FCOS are RPi4, Rpi3b, Allwinner, lorem ipsum.
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.
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.
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.
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.
'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.
...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.
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.
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.
- Test cases: QA:Testcase_Podman