Those who wish to use the openQA automated testing system configured for Rocky Linux tests. If so, you will need a PC or server with hardware virtualisation running an up-to-date Fedora Linux.
This guide explains the use of the openQA automated testing system to test various aspects of Rocky Linux releases either at the pre-release stage or thereafter.
+
openQA is an automated test tool that makes it possible to test the whole installation process. It uses virtual machines which it sets up to reproduce the process, check the output (both serial console and GUI screen) in every step and send the necessary keystrokes and commands to proceed to the next step. openQA checks whether the system can be installed, whether it works properly, whether applications work and whether the system responds as expected to different installation options and commands.
openQA can run numerous combinations of tests for every revision of the operating system, reporting the errors detected for each combination of hardware configuration, installation options and variant of the operating system.
The web UI is a very useful feature of the openQA system since it provides an easily accessed view of the progress and details of openQA tests either on the local machine or remotely or both. It is intended to be intuitive and self-explanatory.
+
Some pages use queries to select what should be shown. The query parameters are generated on clickable links, for example starting from the index page or the group overview page clicking on single builds. On the query pages there can be UI elements to control the parameters, for example to look for older builds or show only failed jobs, or other settings. Additionally, the query parameters can be tweaked by hand if you want to provide a link to specific views.
openQA can be installed only on a Fedora (or OpenSUSE) server or workstation. The following install procedure was tested on Fedora 40 Server. You can use either a local terminal or an ssh login from another host on the lan.
+
# install Packages
+# for openqa
+sudo dnf install -y openqa openqa-httpd openqa-worker fedora-messaging python3-jsonschema
+sudo dnf install -y perl-REST-Client.noarch
+
+# and for createhdds
+sudo dnf install -y libguestfs-tools libguestfs-xfs python3-fedfind python3-libguestfs
+sudo dnf install -y libvirt libvirt-daemon-config-network libvirt-python3 virt-install withlock
+
+# configure httpd:
+cd /etc/httpd/conf.d/
+sudo cp openqa.conf.template openqa.conf
+sudo cp openqa-ssl.conf.template openqa-ssl.conf
+sudo setsebool -P httpd_can_network_connect 1
+sudo systemctl restart httpd
+
+# configure the web UI
+sudoedit /etc/openqa/openqa.ini
+[global]
+branding=plain
+download_domains = rockylinux.org
+[auth]
+method = Fake
+
+sudo dnf install postgresql-server
+sudo postgresql-setup --initdb
+
+# enable and start services
+sudo systemctl enable postgresql --now
+sudo systemctl enable httpd --now
+sudo systemctl enable openqa-gru --now
+sudo systemctl enable openqa-scheduler --now
+sudo systemctl enable openqa-websockets --now
+sudo systemctl enable openqa-webui --now
+sudo systemctl enable fm-consumer@fedora_openqa_scheduler --now
+sudo systemctl enable libvirtd --now
+sudo setsebool -P httpd_can_network_connect 1
+sudo firewall-cmd --add-service=http --permanent
+sudo firewall-cmd --reload
+sudo systemctl restart httpd
+
+# to create API key in local web interface at http://localhost
+# or on remote system http://<ip addr>
+# Click Login, then Manage API Keys, create a key and secret.
+
+# insert key and secret
+sudoedit /etc/openqa/client.conf
+
+[localhost]
+key = ...
+secret = ...
+
+# create workers
+sudo systemctl enable openqa-worker@1 --now
+# then ...@2 ...etc as desired. Look in webui workers to check shown idle.
+# as a rule of thumb, you can have about half the number of workers as cores
+
+# get Rocky tests
+cd /var/lib/openqa/tests/
+sudo git clone https://github.com/rocky-linux/os-autoinst-distri-rocky.git rocky
+sudo chown -R geekotest:geekotest rocky
+cd rocky
+
+# when working in /var/lib/openqa nearly all commands need sudo.
+
+sudo git config --global --add safe.directory /var/lib/openqa/share/tests/rocky
+
+sudo git checkout develop
+# or whichever branch has the latest updates for your tests
+
+sudo ./fifloader.py -l -c templates.fif.json
+sudo git clone https://github.com/rocky-linux/createhdds.git ~/createhdds
+sudo mkdir -p /var/lib/openqa/share/factory/hdd/fixed
+
+# will need about 200GB disk space available for ongoing tests
+cd /var/lib/openqa/factory/hdd/fixed
+
+# start a long running process that provides hdd image files for ongoing tests
+~/createhdds/createhdds.py -t -b stg all
+
+# get Rocky iso files for testing from staging repository
+sudo mkdir -p /var/lib/openqa/share/factory/iso/fixed
+cd /var/lib/openqa/factory/iso/fixed
+
+sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-boot.iso
+sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-minimal.iso
+sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-dvd.iso
+sudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/CHECKSUM
+
+sha256sum -c CHECKSUM
+
+# fix ownership, add <user> to group, reboot
+cd /var/lib/openqa/factory/
+sudo chown -R geekotest:geekotest ./
+sudo usermod -aG geekotest <user>
+sudo init 6
+
+# post tests and view progress on webui
+cd /var/lib/openqa/tests/rocky/
+sudo ./fifloader.py -c -l templates.fif.json
+sudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-minimal.iso ARCH=x86_64 DISTRI=rocky FLAVOR=minimal-iso VERSION=9.3 BUILD="$(date +%Y%m%d.%H%M%S).0"-minimal
+sudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-boot.iso ARCH=x86_64 DISTRI=rocky FLAVOR=boot-iso VERSION=9.3 BUILD="$(date +%Y%m%d.%H%M%S).0"-boot
+and for a full build (this will post 95 jobs)
+sudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-dvd.iso ARCH=x86_64 DISTRI=rocky FLAVOR=dvd-iso VERSION=9.3 BUILD="$(date +%Y%m%d.%H%M%S).0"-dvd-iso
+sudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-dvd.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=9.3 BUILD="$(date +%Y%m%d.%H%M%S).0"-universal
+
+You can watch progress of these tests on the webui on any browser on the same lan as the test host at
+
http://<ip_addr_of_test_host>/tests
+
If you click "login" in the top right corner you will be able to control tests from the webui.
+
At this point the multi-vm tests will fail or be skipped. This is because at the moment your system is configured for single vm deployment and it can be used as such. Pause your installation here if you wish to get some practice using openQA before progressing further (recommended).
+
Installation of facilities for multi-vm testing, which is substantially more complicated, will be described in this document in a later revision (watch this space).
Createhdds is used to prepare .img and .qcow2 files for some of the Rocky tests. If you ran the above procedure you will have noticed that it produces a number of files in /var/lib/openqa/factory/hdd/fixed determined by the files provided in createhdds.
Tests are normally posted using openqa-cli as you have already used above. Test parameters are listed and explained in the openQA VARIABLES definition document
One of the challenges that arises when testing an operating system, especially when doing continuous testing, is that there is always a certain combination of jobs, each one with its own settings, that needs to be run for every revision. These combinations can be different for different FLAVORs of the same revision, like running a different set of jobs for each architecture. This combinational problem can go one step further if openQA is being used for different kinds of tests, like running some simple pre-integration tests for some snapshots combined with more comprehensive post-integration tests for release candidates.
+
This section describes how an instance of openQA could be configured using the options in the admin area of the webUI to automatically create all the required jobs for each revision of your operating system that needs to be tested. If you were starting from scratch (the difficult way), you would probably go through the following order:
+
+
Define machines in 'Machines' menu
+
Define medium types (products) you have in 'Medium types' menu
+
Specify various collections of tests you want to run in the 'Test suites' menu
+
Define job groups in 'Job groups' menu for groups of tests
+
Select individual 'Job groups' and decide what combinations make sense and need to be tested
+
+
If you followed the install guide above then the cloned Rocky tests from os-autoinst-distri-rocky will have pre-configured the admin area of the webUI. You may find it useful to consult when reading the following sections.
+
Machines, mediums, test suites and job templates can all set various configuration variables. The job templates within the job groups define how the test suites, mediums and machines should be combined in various ways to produce individual 'jobs'. All the variables from the test suite, medium, machine and job template are combined and made available to the actual test code run by the 'job', along with variables specified as part of the job creation request. Certain variables also influence openQA’s and/or os-autoinst’s own behavior in terms of how it configures the environment for the job.
+
The configuration is set up from /var/lib/openqa/tests/rocky/templates.fif.json
You need to have at least one machine set up to be able to run any tests. These machines represent virtual machine types that you want to test. Realistically to make tests actually happen, you have to have a number of openQA workers connected that can fulfill these specifications.
+
+
Name User defined string - only needed for operator to identify the machine configuration.
+
Backend What backend should be used for this machine Recommended value is qemu as it is the most tested one, but other options such as kvm2usb or vbox are also possible.
+
+
Variables Most machine variables influence os-autoinst’s behavior in terms of how the test machine is set up. A few important examples:
+
+
QEMUCPU can be qemu32 or qemu64 and specifies the architecture of the virtual CPU
+
+
QEMUCPUS is an integer that specifies the number of cores you wish to be used
+
+
+
USBBOOT when set to 1 the image will be loaded through an emulated USB stick.
A medium type product in openQA is a simple description without any definite meaning. It basically consists of a name and a set of variables that define or characterise this product in os-autoinst.
+
+
+
+
Some example variables are:
+
+
ISO_MAXSIZE contains the maximum size of the product. There is a test that checks that the current size of the product is less or equal than this variable.
+
DVD if it is set to 1 this indicates that the medium is a DVD.
+
LIVECD if it is set to 1 this indicates that the medium is a live image (can be a CD or USB)
+
GNOME this variable, if it is set to 1 indicates that it is a GNOME only distribution.
A test suite consists of a name and a set of test variables that are used inside this particular test together with an optional description. The test variables can be used to parameterise the actual test code and influence the behaviour according to the settings.
+
Some sample variables are:
+
+
DESKTOP possible values are kdegnomelxdexfce or textmode. Used to indicate the desktop selected by the user during the test.
The job groups are the place where the actual test scenarios are defined by the selection of the medium type, the test suite and machine together with a priority value.
+
The priority value is used in the scheduler to choose the next job. If multiple jobs are scheduled and their requirements for running them are fulfilled the ones with a lower priority value are triggered. The id is the second sorting key of two jobs with equal requirements and same priority value the one with lower id is triggered first.
+
Job groups themselves can be created over the web UI as well as the REST API. Job groups can optionally be nested into categories. The display order of job groups and categories can be configured by drag-and-drop in the web UI.
+
The scenario definitions within the job groups can be created and configured by different means:
+
+
A simple web UI wizard which is automatically shown for job groups when a new medium is added to the job group.
+
An intuitive table within the web UI for adding additional test scenarios to existing media including the possibility to configure the priority values.
+
The scripts openQA-load-templates and openQA-dump-templates to quickly dump and load the configuration from custom plain-text dump format files using the REST API.
+
Using declarative schedule definitions in the YAML format using REST API routes or an online-editor within the web UI including a syntax checker.
Needles are very precise and the slightest deviation from the specified display will be detected. This means that every time there is a new release, very small changes occur in layout of displays resulting in many new or modified needles being required. There is always a significant amount of work needed by the Test Team to produce the automatic tests for a new version.
+
A very useful feature of the webui is the online needle editor. When a test fails for a missing needle, the needle editor can be activated by clicking the icon and a new needle can be created, usually by copying a similar needle together with the current screenshot. The needle files are saved in the /var/lib/openqa/tests/rocky/needles directory
Starter Guide and Upstream documentation are useful for reference but since they are a mixture of advice and instructions relating to openSUSE and Fedora which have substantial differences between them it is not always clear which are significant for Rocky. However, as an rpm based distribution, Rocky Linux use is loosely related to the Fedora version.
The following terms are used within the context of openQA:-
+
+
+
test module
+
+
An individual test case in a single perl module .pm file, e.g. sshxterm If not further specified a test module is denoted with its short name equivalent to the filename including the test definition. The full name is composed of the test group, which itself is formed by the top-folder of the test module file, and the short name, e.g. x11-sshxterm (for x11/sshxterm.pm)
+
+
+
+
test suite
+
+
+
A collection of test modules, e.g. textmode All test modules within one test suite are run serially
+
+
+
One run of individual test cases in a row denoted by a unique number for one instance of openQA, e.g. one installation with subsequent testing of applications within gnome
+
+
+
+
+
test run
+
+
Equivalent to job
+
+
+
test result
+
The result of one job, e.g. passed with the details of each individual test module
+
+
+
+
test step
+
+
the execution of one test module within a job
+
+
+
+
distri
+
+
A test distribution but also sometimes referring to a product (CAUTION: ambiguous, historically a "GNU/Linux distribution"), composed of multiple test modules in a folder structure that composes test suites, e.g. rocky (test distribution, short for os-autoinst-distri-rocky)
+
+
+
+
product
+
+
The main system under test (SUT) e.g. rocky also called Medium Types in the web interface of openQA
+
+
+
+
job group
+
+
Equivalent to product, used in context of the webUI
+
+
+
+
version
+
+
One version of a product, don’t confuse with build
+
+
+
+
flavor
+
+
Keyword for a specific variant of a product to distinguish differing variants, e.g. dvd-iso
+
+
+
+
arch
+
+
An architecture variant of a product, e.g. x86_64
+
+
+
+
machine
+
+
Additional variant of machine, e.g. used for 64bitbiosuefi etc.
+
+
+
+
scenario
+
+
A composition of <distri>-<version>-<flavor>-<arch>-<test_suite>@<machine> e.g. Rocky-9-dvd-x86_64-gnome@64bit
+
+
+
+
build
+
+
Different versions of a product as tested, can be considered a sub-version of version, e.g. Build1234 CAUTION: ambiguity: either with the prefix build included or not
openQA started with OS-autoinst: automated testing of Operating Systems
+The OS-autoinst project aims at providing a means to run fully automated tests, especially to run tests of basic and low-level operating system components such as bootloader, kernel, installer and upgrade, which can not easily be tested with other automated testing frameworks. However, it can just as well be used to test firefox and openoffice operation on top of a newly installed OS.
+openQA is a test-scheduler and web-front for openSUSE and Fedora using OS-autoinst as a backend.
+openQA originated at openSuse and was adopted by Fedora as the automated test system for their frequent distribution updates. Maintenance activity is fairly intense and is ongoing at various levels of users. openQA was adopted by Rocky Linux Test Team as the preferred automated testing system for the ongoing releases of it's distribution.
+openQA is free software released under the GPLv2 license.
Since Rocky Linux use of openQA is drawn from upstream Fedora and hence openSUSE this document contains many passages which are edited versions of upstream documentation and that use is hereby gratefully acknowledged. As with many open source projects, we build on previous work.
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"members/","title":"Members","text":"Role Name Email Mattermost Name IRC Name Testing Lead Chris Stackpole stack@rockylinux.org @stack Testing Team Al Bowles @raktajino raktajino Testing Team Trevor Cooper tcooper@rockylinux.org @tcooper Testing Team Lukas Magauer lukas@magauer.eu @lumarel Testing Team Alan Marshall @alangm alangm Testing Team Rich Alloway @ralloway Testing Team Anthony Navarro @anavarro10 Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This section goes over various Documentation for the Testing team. Please use the menu items to find the various pages of interest.
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This page lists all test cases in work and who is working on them...
"},{"location":"documentation/qa_test_cases/#initialization-requirements","title":"Initialization Requirements","text":"Requirement Test Case Assignee Status Release-blocking images must bootRocky Linux 8 Rocky Linux 9 QA:Testcase Boot Methods Boot ISO @tcooper template exists, openQA covered (ref) Release-blocking images must bootRocky Linux 8 Rocky Linux 9 QA:Testcase Boot Methods DVD @tcooper template exists, openQA covered (ref) Basic Graphics Mode behaviorsRocky Linux 8 QA:Testcase Basic Graphics Mode @tcooper openQA TestCase VNC Graphics Mode behaviorsRocky Linux 9 QA:Testcase VNC Graphics Mode @tcooper openQA TestCase No Broken PackagesRocky Linux 8 Rocky Linux 9 QA:Testcase Media RepoclosureQA:Testcase Media File Conflicts @tcooper manual using scripts or automated in CI Repositories Must Match UpstreamRocky Linux 8 Rocky Linux 9 QA:Testcase repocompare @tcooper manual using Skip's repocompare DebrandingRocky Linux 8 Rocky Linux 9 QA:Testcase Debranding Analysis @tcooper manual using scripts or automated in CI"},{"location":"documentation/qa_test_cases/#installer-requirements","title":"Installer Requirements","text":"Requirement Test Case Assignee Status Media Consistency Verification QA:Testcase Media USB ddQA:Testcase Boot Methods Boot ISOQA:Testcase Boot Methods DVD @raktajino Packages and Installer Sources QA:Testcase Packages and Installer Sources @raktajino Implemented in openQA, document NAS (Network Attached Storage) QA:Testcase Network Attached Storage @raktajino Installation Interfaces QA:Testcase Installation Interfaces @raktajino Implemented in openQA, document Minimal Installation QA:Testcase Minimal Installation @raktajino Implemented in openQA, document Kickstart Installation QA:Testcase Kickstart Installation @raktajino Implemented in openQA, document Disk Layouts QA:Testcase Disk Layouts @raktajino Implemented in openQA, document Firmware RAID QA:Testcase Firmware RAID @raktajino Bootloader Disk Selection QA:Testcase Bootloader Disk Selection @raktajino Storage Volume Resize QA:Testcase Storage Volume Resize @raktajino Implemented in openQA, document Update Image QA:Testcase Update Image @raktajino Implemented in openQA, document Installer Help QA:Testcase Installer Help @raktajino Implemented in openQA, document Installer Translations QA:Testcase Installer Translations @raktajino Implemented in openQA, document"},{"location":"documentation/qa_test_cases/#cloud-image-requirements","title":"Cloud Image Requirements","text":"Requirement Test Case Assignee Status Images Published to Cloud Providers QA:Testcase TBD @tbd"},{"location":"documentation/qa_test_cases/#post-installation-requirements","title":"Post-Installation Requirements","text":"Requirement Test Case Assignee Status System Services QA:Testcase System Services @lumarel manual guide documented or needs new openQA testcase Keyboard Layout QA:Testcase Keyboard Layout @lumarel implemented in openQA SELinux Errors (Server) QA:Testcase SELinux Errors on Server @lumarel implemented in openQA SELinux and Crash Notifications (Desktop Only) QA:Testcase SELinux Errors on Desktop @lumarel partly implemented in openQA Default Application Functionality (Desktop Only) QA:Testcase Application Functionality @lumarel manual guide documented Default Panel Functionality (Desktop Only) QA:Testcase GNOME UI Functionality @lumarel implemented in openQA, additionally documented for manual inspection Dual Monitor Setup (Desktop Only) QA:Testcase Multimonitor Setup @lumarel manual guide documented Artwork and Assets (Server and Desktop) QA:Testcase Artwork and Assets @lumarel implemented in openQA, additionally documented for manual inspection Packages and Module Installation QA:Testcase Basic Package installsQA:Testcase Module Streams @lumarel partly implemented in openQA, manual guide documented Identity Management (FreeIPA) QA:Testcase Identity Management @lumarel manual guide documented, PR open for openQA implementation Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
REFERENCED RELEASE CRITERIA IS OVERLY GENERAL AND UNTESTABLE
The associated release criteria, Release_Criteria#basic-graphics-mode-behaviors, for this test case is overly general and must be modified to specific enough to be testable.
Associated release criterion
This test case is associated with the Release_Criteria#basic-graphics-mode-behaviors release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case will verify that release-blocking installers function as intended using the generic video driver option (\u201cbasic graphics mode\u201d) on supported systems and classes of hardware.
Supported Systems and Hardware Classes x86_64aarch64ppc64s309x
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
"},{"location":"documentation/QA/Testcase_Basic_Graphics_Mode/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
In the installer select the appropriate option to intall in basic graphics mode.
Proceed with installation on the test system.Depending on installer choices this MAY destroy all the data on the test system.
DATA LOSS
If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Selection of basic graphics mode in the Anaconda installer is possible.
Anaconda installer presents a usable graphical intallation environment.
System under test can be installed normally.
After reboot system boots into graphical environment.
After login user is able to operate the graphical environment.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#initialization-requirements release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Prepare your system for booting the boot.iso image. This may involve writing the image to a USB key or burning it to an optical disk. Additionally, attaching the boot.iso to a virtual machine instance as a Virtual Optical Disk or mounting the boot.iso to server via baseboard management controller virtual media attach should be possible but is not expressly required.
"},{"location":"documentation/QA/Testcase_Boot_Methods_Boot_Iso/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
In the boot menu select the appropriate option to boot the installer.
Graphical boot menu is displayed for users to select install options. Navigating the menu and selecting entries must work. If no option is selected, the installer should load after a reasonable timeout.
System boots into the Anaconda installer.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#initialization-requirements release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Prepare your system for booting the DVD.iso image. This may involve writing the image to a USB key or burning it to an optical disk of sufficient capacity. Additionally, attaching the DVD.iso to a virtual machine instance as a Virtual Optical Disk or mounting the DVD.iso to server via baseboard management controller virtual media attach should be possible but is not expressly required.
"},{"location":"documentation/QA/Testcase_Boot_Methods_Dvd/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
In the boot menu select the appropriate option to boot the installer.
Graphical boot menu is displayed for users to select install options. Navigating the menu and selecting entries must work. If no option is selected, the installer should load after a reasonable timeout.
System boots into the Anaconda installer.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Bootloader_Disk_Selection/","title":"QA:Testcase Bootloader Disk Selection","text":"
Associated release criterion
This test case is associated with the Release_Criteria#Bootloader Disk Selection release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that the user is able to select an alternative disk on which to install the bootloader. It also verifies that, if the user is so inclined, they may choose not to install a bootloader at all.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
"},{"location":"documentation/QA/Testcase_Bootloader_Disk_Selection/#how-to-test","title":"How to test","text":"
In the Installation Destination spoke, select the disk(s) to install to, then click the \"Full disk summary and bootl loader...\" button at the bottom of the screen:
Click the checkbox next to the disk on which the bootloader is desired
Alternatively, uncheck the boot checkbox next to all disks to skip bootloader installation
Note that if no bootloader is installed, the system may not boot after installation is complete. This is expected.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#vnc-graphics-mode-behaviors release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Prepare your system for booting the boot.iso image. This may involve writing the image to a USB key or burning it to an optical disk. Additionally, attaching the boot.iso to a virtual machine instance as a Virtual Optical Disk or mounting the boot.iso to server via baseboard management controller virtual media attach should be possible but is not expressly required.
"},{"location":"documentation/QA/Testcase_Custom_Boot_Methods_Boot_Iso/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
In the boot menu select the appropriate option to boot the installer.
Interrupt the normal boot and edit the kernel command line.
Add appropriate/required options to the kernel command line and resume booting into the installer.
Example: For network install from an alternate repository add --inst.url=http://<server>/<path_to_BaseOS_repo> and (optionally) --inst.repo=AppStream,http://<server>/<path_to_AppStream_repo> to the kernel command line.
Example: For VNC install in Direct Mode add --inst.vnc to the kernel command line. For VNC install in Connect Mode add --inst.vnc and --inst.vncserver=<host>:<port> to the kernel command line.
Boot menu is displayed for users to select install options. Navigating the menu and selecting entries must work. Editing the boot command line must be possible. If no option is selected, the installer should load after a reasonable timeout.
System boots into the Anaconda installer and any command line options specified are utilized.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria - Debranding release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
The Rocky Linux Release Engineering Team builds and maintains tools to manage the debranding of packages received from the upstream vendor. They have published a comprehensive debranding guide and maintain a list of packages requiring debranding patches.
This testcase will verify that all packages available on released media that Rocky Linux Release Engineering has identified as requiring debranding are debranded successfully per their specification.
Obtain access to an environment with the dnf, and koji commands and access to Rocky Linux Gitlab and Rocky Linux Koji
Download the ISO to be tested to test machine.
Configure /etc/koji.conf to access the Rocky Linux Koji.
Download a recent copy the patch.yml from Rocky Linux Gitlab.
patch.yml
Packages listed in patch.yml are names of source RPMs. Binary RPMs containing content produced by building the patched source RPMs need to be validated. The easiest way to get the list of all possible binary RPMs for a particular package and arch is to ask obtain that information in koji.
"},{"location":"documentation/QA/Testcase_Debranding/#how-to-test","title":"How to test","text":"
Mount the ISO to be tested locally.
Example:
$ mount -o loop Rocky-8.5-x86_64-dvd1.iso /media\n
Determine the path(s) to the repodata directory(ies) on the ISO.
Example:
$ find /media -name repodata\n
For each package to be validated get the names of the noarch and <arch> specific packages created from it.
Example:
$ koji --quiet latest-build --arch=x86_64 dist-rocky8-compose <package>\n$ koji --quiet latest-build --arch=noarch dist-rocky8-compose <package>\n
Use dnf to obtain the paths to the binary packages requiring debranding.
Note all debranding patches will patch files directly and leave very obvious traces, some patches don't even add changelog messages to use as an indicator that the package has been patched or debranded. Sometimes the only solution is to extract the binary package and examine the contents directly to find something to test.
Packages tracked by Release Engineering as requiring debranding and published on installation media are, in fact, debranded per their specification.
Sample Output SuccessFailure
$ sudo mount -o loop Rocky-8.5-aarch64-minimal.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n$ find /media -name repodata\n/media/BaseOS/repodata\n/media/Minimal/repodata\n\n$ curl -LOR https://git.rockylinux.org/rocky/metadata/-/raw/main/patch.yml\n % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n100 3410 100 3410 0 0 20419 0 --:--:-- --:--:-- --:--:-- 20419\n\n$ yq .debrand.all[] patch.yml | column -x -c 100 -o \" \"\nabrt anaconda anaconda-user-help chrony\ncloud-init cockpit crash dhcp\ndnf firefox fwupd gcc\ngcc-toolset-9-gcc gcc-toolset-10-gcc gcc-toolset-11-gcc gcc-toolset-12-gcc\ngnome-settings-daemon grub2 httpd initial-setup\nkernel kernel-rt libdnf libreoffice\nlibreport nginx opa-ff opa-fm\nopenscap pesign PackageKit python-pip\npython3 redhat-rpm-config scap-security-guide shim\nshim-unsigned-x64 shim-unsigned-aarch64 sos subscription-manager\nsystemd thunderbird WALinuxAgent\n\n$ ./yq .debrand.r8[] patch.yml | column -x -c 100 -o \" \"\ndotnet3.0 fwupdate gnome-boxes libguestfs pcs plymouth\npython2\n\nNOTE: Only a single package will be shown in this Example.\n\n$ koji --quiet latest-build --arch=x86_64 dist-rocky8-compose sos\n\n$ koji --quiet latest-build --arch=noarch dist-rocky8-compose sos\nsos-4.1-9.el8_5.rocky.3.noarch\nsos-audit-4.1-9.el8_5.rocky.3.noarch\n\n$ dnf download --urls --repofrompath BaseOS,/media/BaseOS --repo BaseOS \\\n --repofrompath Minimal,/media/Minimal --repo Minimal \\\n sos sos-audit | grep -E \"^file\"\nfile:///media/BaseOS/Packages/s/sos-4.1-5.el8.noarch.rpm\nfile:///media/BaseOS/Packages/s/sos-audit-4.1-5.el8.noarch.rpm\n\n$ rpm -q --changelog -p /media/BaseOS/Packages/s/sos-4.1-5.el8.noarch.rpm | \\\n head | grep \"Release Engineering <releng@rockylinux.org>\" -C2\n* Mon Oct 18 2021 Release Engineering <releng@rockylinux.org> - 4.1-5\n- Remove Red Hat branding from sos\n$ echo $?\n0\n\n$ rpm -q --changelog -p /media/BaseOS/Packages/s/sos-audit-4.1-5.el8.noarch.rpm | \\\n head | grep \"Release Engineering <releng@rockylinux.org>\" -C2\n* Mon Oct 18 2021 Release Engineering <releng@rockylinux.org> - 4.1-5\n- Remove Red Hat branding from sos\n$ echo $?\n0\n\n$ umount /media\n
$ sudo mount -o loop Rocky-8.5-aarch64-minimal.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n$ find /media -name repodata\n/media/BaseOS/repodata\n/media/Minimal/repodata\n\n$ curl -LOR https://git.rockylinux.org/rocky/metadata/-/raw/main/patch.yml\n % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n100 3410 100 3410 0 0 20419 0 --:--:-- --:--:-- --:--:-- 20419\n\n$ yq .debrand.all[] patch.yml | column -x -c 100 -o \" \"\nabrt anaconda anaconda-user-help chrony\ncloud-init cockpit crash dhcp\ndnf firefox fwupd gcc\ngcc-toolset-9-gcc gcc-toolset-10-gcc gcc-toolset-11-gcc gcc-toolset-12-gcc\ngnome-settings-daemon grub2 httpd initial-setup\nkernel kernel-rt libdnf libreoffice\nlibreport nginx opa-ff opa-fm\nopenscap pesign PackageKit python-pip\npython3 redhat-rpm-config scap-security-guide shim\nshim-unsigned-x64 shim-unsigned-aarch64 sos subscription-manager\nsystemd thunderbird WALinuxAgent\n\n$ ./yq .debrand.r8[] patch.yml | column -x -c 100 -o \" \"\ndotnet3.0 fwupdate gnome-boxes libguestfs pcs plymouth\npython2\n\nNOTE: Only a single package will be shown in this Example.\n\n$ koji --quiet latest-build --arch=x86_64 dist-rocky8-compose sos\n\n$ koji --quiet latest-build --arch=noarch dist-rocky8-compose sos\nsos-4.1-9.el8_5.rocky.3.noarch\nsos-audit-4.1-9.el8_5.rocky.3.noarch\n\n$ dnf download --urls --repofrompath BaseOS,/media/BaseOS --repo BaseOS \\\n --repofrompath Minimal,/media/Minimal --repo Minimal \\\n sos sos-audit | grep -E \"^file\"\nfile:///media/BaseOS/Packages/s/sos-4.1-5.el8.noarch.rpm\nfile:///media/BaseOS/Packages/s/sos-audit-4.1-5.el8.noarch.rpm\n\n$ rpm -q --changelog -p /media/BaseOS/Packages/s/sos-4.1-5.el8.noarch.rpm | \\\n head | grep \"Release Engineering <releng@rockylinux.org>\" -C2\n$ echo $?\n1\n\n$ rpm -q --changelog -p /media/BaseOS/Packages/s/sos-audit-4.1-5.el8.noarch.rpm | \\\n head | grep \"Release Engineering <releng@rockylinux.org>\" -C2\n$ echo $?\n1\n\n$ umount /media\n
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Disk_Layouts/","title":"QA:Testcase Disk Layouts","text":"
Associated release criterion
This test case is associated with the Release_Criteria#Disk Layouts release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies successful installation to any supported partition layout using any file system or format combination.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
The installation should complete successfully and boot to the appropriate disk.
The specified filesystem type and partition scheme should be used.
If configured, software RAID should function as expected.
"},{"location":"documentation/QA/Testcase_Disk_Layouts/#testing-with-openqa","title":"Testing with openQA","text":"
The following openQA test suites satisfy this release criteria:
install_standard_partition_ext4
install_custom_gui_standard_partition_ext4
install_lvm_ext4
install_custom_gui_lvm_ext4
install_software_raid
install_custom_gui_software_raid
install_xfs
install_custom_gui_xfs
install_lvmthin
install_multi
install_multi_empty
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Firmware RAID release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
The installer must be able to detect and install to firmware RAID devices. Note that system-specific bugs do not count as blockers. It is likely that some hardware support might be broken or not available at all. DUDs (driver update disks) are not considered for this criteria.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Installation Interfaces release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that the installer can complete an installation using all Anaconda spokes.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
The installation should complete and boot successfully.
"},{"location":"documentation/QA/Testcase_Installation_Interfaces/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_arabic_language OR install_asian_language
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Installer Help release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
"},{"location":"documentation/QA/Testcase_Installer_Help/#how-to-test","title":"How to test","text":"
From the Anaconda Hub, click the Help button in the upper right hand corner.
Verify that you see the \"Customizing your Installation\" help page.
Verify that the \"Configuring language and location settings\" link displays a topically appropriate page.
Close the Help browser to return to the Anaconda Hub.
Verify that the Localization help page displays for the Keyboard, Language Support, and Time & Date spokes:
Select the spoke, then click the Help button.
Verify that you see the \"Configuring localization options\" page containing a functioning link to the \"Configuring keyboard, language, and time and date settings\" page.
Close the Help browser (and click Done if necessary) to return to the Anaconda Hub.
Verify that the Help button in the Installation Source spoke displays the \"Configuring installation source\" page.
Verify that the Help button in the Software Selection spoke displays the \"Configuring software selection\" page.
Verify that the Help button in the Installation Destination spoke displays the \"Configuring storage devices\" page.
Verify that the Help button in the Network & Host Name spoke displays the \"Configuring network and host name options\" page.
Verify that the Help button in the Root Password spoke displays the \"Configuring a root password\" page.
Verify that the Help button in the User Creation spoke displays the \"Creating a user account\" page.
All links should work and display relevant content.
"},{"location":"documentation/QA/Testcase_Installer_Help/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
anaconda_help
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Installer Translations release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
All spokes should display at least some of the content in the selected language.
It is expected to still see some content displayed in Latin characters even if a language that does not use Latin characters is selected.
"},{"location":"documentation/QA/Testcase_Installer_Translations/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_asian_language
install_arabic_language
install_cyrillic_language
install_european_language
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Kickstart Installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that installations via both local and remote Kickstart configuration files are successful.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
Hit the Tab key to edit the boot command
Provide a local Kickstart file by supplying the GRUB boot option inst.ks=file:/path/to/local.ks or a remote Kickstart file by supplying the GRUB boot option inst.ks=https://git.resf.org/testing/createhdds/raw/branch/rocky/server.ks.
"},{"location":"documentation/QA/Testcase_Kickstart_Installation/#how-to-test","title":"How to test","text":"
The installation should complete and boot successfully, automatically populating the options specified in the Kickstart file.
"},{"location":"documentation/QA/Testcase_Kickstart_Installation/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_kickstart_nfs
server_realmd_join_kickstart
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Media_File_Conflicts/","title":"QA:Testcase Media File Conflicts","text":"
Associated release criterion
This test case is associated with the Release_Criteria#no-broken-packages release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This testcase will verify that the offline repository included on release blocking images will not contain any file conflicts between packages without explicit Conflicts: tag in the package metadata.
The potential_conflict.py script does not report any packages with non-declared conflicts.
Sample Output SuccessFailure
$ sudo mount -o loop Rocky-8.5-aarch64-minimal.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n$ python3 /vagrant/scripts/potential_conflict.py \\\n --repofrompath BaseOS,/media/BaseOS --repoid BaseOS \\\n --repofrompath Minimal,/media/Minimal --repoid Minimal\n\nAdded BaseOS repo from /media/BaseOS\nAdded Minimal repo from /media/Minimal\nGetting complete filelist for:\nfile:///media/BaseOS\nfile:///media/Minimal\n168374 files found.\n\nLooking for duplicated filenames:\n524 duplicates found.\n\nDoing more advanced checks to see if these are real conflicts:\n 10% complete ( 52/ 524, 1139/sec), 0 found - eta 0:00:00\n 35% complete ( 182/ 524, 1146/sec), 0 found - eta 0:00:00\n 45% complete ( 234/ 524, 1818/sec), 0 found - eta 0:00:00\n 50% complete ( 260/ 524, 592673/sec), 0 found - eta 0:00:00\n 55% complete ( 286/ 524, 778942/sec), 0 found - eta 0:00:00\n 60% complete ( 312/ 524, 801852/sec), 0 found - eta 0:00:00\n 79% complete ( 416/ 524, 234/sec), 0 found - eta 0:00:00\n 84% complete ( 442/ 524, 902/sec), 0 found - eta 0:00:00\n 89% complete ( 468/ 524, 935/sec), 0 found - eta 0:00:00\n 94% complete ( 494/ 524, 1616/sec), 0 found - eta 0:00:00\n 99% complete ( 520/ 524, 1114/sec), 0 found - eta 0:00:00\n\n0 file conflicts found.\n0 package conflicts found.\n\n== Package conflicts ==\n\n== File conflicts, listed by conflicting packages ==\n\n$ sudo umount /media\n
$ sudo mount -o loop Rocky-8.5-x86_64-dvd1.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n\n$ python3 /vagrant/scripts/potential_conflict.py \\\n --repofrompath AppStream,/media/AppStream --repoid AppStream \\\n --repofrompath BaseOS,/media/BaseOS --repoid BaseOS\n\n Added AppStream repo from /media/AppStream\n Added BaseOS repo from /media/BaseOS\n Getting complete filelist for:\n file:///media/AppStream\n file:///media/BaseOS\n 851967 files found.\n\n Looking for duplicated filenames:\n 101865 duplicates found.\n\n Doing more advanced checks to see if these are real conflicts:\n 5% complete ( 5093/101865, 8713/sec), 0 found - eta 0:00:11\n 10% complete ( 10186/101865, 1787281/sec), 0 found - eta 0:00:05\n 15% complete ( 15279/101865, 2223312/sec), 0 found - eta 0:00:03\n 20% complete ( 20372/101865, 23614/sec), 0 found - eta 0:00:03\n 25% complete ( 25465/101865, 57188/sec), 0 found - eta 0:00:02\n 30% complete ( 30558/101865, 3831/sec), 0 found - eta 0:00:05\n 35% complete ( 35651/101865, 48455/sec), 0 found - eta 0:00:04\n 40% complete ( 40744/101865, 32067/sec), 0 found - eta 0:00:03\n 45% complete ( 45837/101865, 2136586/sec), 0 found - eta 0:00:03\n 50% complete ( 50930/101865, 72529/sec), 0 found - eta 0:00:02\n 55% complete ( 56023/101865, 176294/sec), 0 found - eta 0:00:02\n 60% complete ( 61116/101865, 68622/sec), 1 found - eta 0:00:01\n 65% complete ( 66209/101865, 155133/sec), 1 found - eta 0:00:01\n 70% complete ( 71302/101865, 13874/sec), 1 found - eta 0:00:01\n 75% complete ( 76395/101865, 10835/sec), 1 found - eta 0:00:01\n 80% complete ( 81488/101865, 27477/sec), 1 found - eta 0:00:00\n 85% complete ( 86581/101865, 9075/sec), 1 found - eta 0:00:00\n 90% complete ( 91674/101865, 14807/sec), 1 found - eta 0:00:00\n 95% complete ( 96767/101865, 197437/sec), 1 found - eta 0:00:00\n 100% complete (101860/101865, 38727/sec), 1 found - eta 0:00:00\n\n 1 file conflicts found.\n 11 package conflicts found.\n\n == Package conflicts ==\n mariadb-server-utils-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-server-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n python3-mod_wsgi-4.6.4-4.el8.x86_64\n python38-mod_wsgi-4.6.8-3.module+el8.4.0+570+c2eaf144.x86_64\n python39-mod_wsgi-4.7.1-4.module+el8.4.0+574+843c4898.x86_64\n\n libcmpiCppImpl0-2.0.3-15.el8.i686\n tog-pegasus-libs-2:2.14.1-46.el8.i686\n\n mariadb-connector-c-devel-3.1.11-2.el8_3.i686\n mariadb-connector-c-devel-3.1.11-2.el8_3.x86_64\n mariadb-devel-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-devel-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-server-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-server-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-test-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-test-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-connector-c-devel-3.1.11-2.el8_3.i686\n mariadb-connector-c-devel-3.1.11-2.el8_3.x86_64\n mysql-devel-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-devel-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-devel-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n libcmpiCppImpl0-2.0.3-15.el8.x86_64\n tog-pegasus-libs-2:2.14.1-46.el8.x86_64\n\n libev-libevent-devel-4.24-6.el8.i686\n libev-libevent-devel-4.24-6.el8.x86_64\n libevent-devel-2.1.8-5.el8.i686\n libevent-devel-2.1.8-5.el8.x86_64\n\n\n == File conflicts, listed by conflicting packages ==\n mariadb-server-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-test-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n /usr/bin/mysqld_safe\n\n$ sudo umount /media\n
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Media_Repoclosure/","title":"QA:Testcase Media Repoclosure","text":"
Associated release criterion
This test case is associated with the Release_Criteria#no-broken-packages release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
NOTE: In this example the content of the Rocky-8.5-x86_64-minimal.iso was copied to /tmp then the BaseOS repository was modified to remove the setup-2.12.2-6.el8.noarch.rpm package and the repository metadata was regenerated.
[vagrant@localhost ~]$ dnf --refresh repoclosure \\\n --repofrompath BaseOS,/tmp/media/BaseOS --repo BaseOS \\\n --repofrompath Minimal,/tmp/media/Minimal --repo Minimal\nAdded BaseOS repo from /tmp/media/BaseOS\nAdded Minimal repo from /tmp/media/Minimal\nBaseOS 3.7 MB/s | 3.8 kB 00:00\nMinimal 3.7 MB/s | 3.8 kB 00:00\npackage: basesystem-11-5.el8.noarch from BaseOS\n unresolved deps:\n setup\npackage: dump-1:0.4-0.36.b46.el8.x86_64 from BaseOS\n unresolved deps:\n setup\npackage: filesystem-3.8-6.el8.x86_64 from BaseOS\n unresolved deps:\n setup\npackage: initscripts-10.00.15-1.el8.x86_64 from BaseOS\n unresolved deps:\n setup\npackage: rpcbind-1.2.5-8.el8.x86_64 from BaseOS\n unresolved deps:\n setup\npackage: shadow-utils-2:4.6-14.el8.x86_64 from BaseOS\n unresolved deps:\n setup\nError: Repoclosure ended with unresolved dependencies.\n
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Media_USB_dd/","title":"QA:Testcase Media USB dd","text":"
Associated release criterion
This test case is associated with the Release_Criteria#initialization-requirements release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This verifies that Rocky Linux ISO image can be written to USB media using dd command, and the resulting USB media successfully boots to the Anaconda Installer.
DATA LOSS
Any data on the USB stick used for this test is likely to be destroyed. Please do not use a stick whose contents you need to keep.
Provide a USB media device that is larger than the ISO image you wish to test and that it can be completely erased.
Provide a Linux (or other *nix system) that has the dd command available and an unoccupied USB port.
Download the Rocky Linux ISO image you wish to test onto the test system.
Example command:curl -LOR https://dl.rockylinux.org/pub/rocky/8/isos/x86_64/Rocky-x86_64-boot.iso
Download the CHECKSUM file that goes with the Rocky Linux ISO image that you wish to test.
Example command:curl -LOR https://dl.rockylinux.org/pub/rocky/8/isos/x86_64/CHECKSUM
Download the CHECKSUM.sig file that does with the CHECKSUM file.
Example command:curl -LOR https://dl.rockylinux.org/pub/rocky/8/isos/x86_64/CHECKSUM.sig
Download the Rocky Release Engineering GPG key.
Example command:curl -LOR https://dl.rockylinux.org/pub/rocky/RPM-GPG-KEY-rockyofficial
"},{"location":"documentation/QA/Testcase_Media_USB_dd/#how-to-test","title":"How to test","text":"
Import the Rocky Release Engineering GPG key.
Example command:gpg --import RPM-GPG-KEY-rockyofficial
Verify the signature of the CHECKSUM file.
Example command:gpg --verify-file CHECKSUM.sig
Verify the CHECKSUM of the Rocky Linux ISO...
Example command:shasum -a 256 --ignore-missing -c CHECKSUM
Write the Rocky Linux ISO to the USB media using dd...
Example command:dd if=Rocky-8.5-x86_64-boot.iso of=/dev/sdX bs=16M status=progress oflag=direct...where you replace sdX with the device identifier of your USB media.This will destroy all data on the disk.
Boot the test system with the USB media.
In the boot menu select the appropriate option to boot the installer.
[OPTIONAL] Proceed with installation on the test system.Depending on installer choices this MAY destroy all the data on the test system.
The Rocky Linux ISO is written to the USB stick without errors.
The USB stick boots without errors.
The Anaconda Installer starts without errors.
DATA LOSS
If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
[OPTIONALLY] 6. The installation finishes successfully and, if the minimal or DVD ISO were used, the package repository on the USB stick (not a network based repository) was used for the installation.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Minimal Installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that a networked minimal installation is able to install the 'Minimal' package set. The installation should not require use of local packages to complete.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
The installation should complete and boot successfully.
"},{"location":"documentation/QA/Testcase_Minimal_Installation/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_minimal
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Network Attached Storage release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
"},{"location":"documentation/QA/Testcase_Network_Attached_Storage/#how-to-test","title":"How to test","text":""},{"location":"documentation/QA/Testcase_Network_Attached_Storage/#nfs","title":"NFS","text":"
install nfs-utils sudo mount -t nfs nfs-server:/nfs/path /mnt then a created a file echo 1 > /mnt/1 verified it and permissions ls /mnt; cat /mnt/1 then deleted it rm /mnt/1 then unmounted sudo umount /mnt
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Packages_Installer_Sources/","title":"QA:Testcase Packages and Installer Sources","text":"
Associated release criterion
This test case is associated with the Release_Criteria#Packages and Installer Sources release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that the installer can successfully install any of the supported package sets via any of the supported installer sources.
The following package sets are supported for installs from local media:
server
minimal
The following package sets are only available from remote sources and require a network connection:
workstation
graphical-server
virtualization-host
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
The installation should complete and boot successfully.
If a graphical package set was specified, the system should boot to a graphical login screen.
"},{"location":"documentation/QA/Testcase_Packages_Installer_Sources/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria, provided they pass the _do_install_reboot module at a minimum:
install_packageset_server
install_packageset_minimal
install_packageset_workstation
install_packageset_graphical-server
install_packageset_virtualization-host
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Packages_No_Insights/","title":"QA:Testcase Packages No Insights","text":"
Associated release criterion
This test case is associated with the Release_Criteria#repositories-must-match-upstream release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
insights-client is not declared to be installed by default.
Sample Output SuccessFailure
UPDATE SAMPLE
NOTE: This example needs to be refreshed when the 8.6 ISO has been produced. As seen in the Failure section below the Rocky-8.5-x86_64-dvd1.iso includes the insights-client as part of the base group. The package should be included on the DVD ISO but should not be installed automatically.
$ sudo mount -o loop Rocky-8.5-x86_64-dvd1.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n$ dnf --refresh --repofrompath BaseOS,/media/BaseOS --repo BaseOS --repofrompath AppStream,/media/AppStream --repo AppStream search insights-client\nAdded BaseOS repo from /media/BaseOS\nAdded AppStream repo from /media/AppStream\nBaseOS 3.8 MB/s | 3.9 kB 00:00\nAppStream 4.2 MB/s | 4.3 kB 00:00\n================================= Name Exactly Matched: insights-client ==================================\ninsights-client.noarch : Uploads Insights information to Red Hat on a periodic basis\n\n$ find /media -name \"*comps*.xml\" -exec grep -H \"insights-client\" '{}' \\;\n/media/AppStream/repodata/a6742e1300e1c786af91656b152d3b98bb7aff598e650509381417970e1f1b7e-comps-AppStream.x86_64.xml: <packagereq type=\"default\">insights-client</packagereq>\n/media/AppStream/repodata/a6742e1300e1c786af91656b152d3b98bb7aff598e650509381417970e1f1b7e-comps-AppStream.x86_64.xml: <packagereq type=\"default\">insights-client</packagereq>\n\n$ dnf --refresh --repofrompath BaseOS,/media/BaseOS --repo BaseOS --repofrompath AppStream,/media/AppStream --repo AppStream groupinfo base | grep -E \":|insights\"\nBaseOS 3.8 MB/s | 3.9 kB 00:00\nAppStream 4.2 MB/s | 4.3 kB 00:00\nGroup: Base\n Description: The standard installation of Rocky Linux.\n Mandatory Packages:\n Default Packages:\n insights-client\n Optional Packages:\n\n$ sudo umount /media\n
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Packages_No_RHSM/","title":"QA:Testcase Packages No RHSM","text":"
Associated release criterion
This test case is associated with the Release_Criteria#repositories-must-match-upstream release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#default-application-functionality-desktop-only release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
REFERENCED RELEASE CRITERIA IS OVERLY GENERAL AND UNTESTABLE
The associated release criteria, Release_Criteria#default-application-functionality-desktop-only, for this test case is overly general and must be modified to specific enough to be testable.
Make sure that the individual applications behave as they should.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Post_Artwork_and_Assets/","title":"QA:Testcase Artwork and Assets","text":"
Release relevance
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#artwork-and-assets-server-and-desktop release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
There are several brand artworks and assets throughout the whole OS, this testcase will take care of checking, that these are actually in place, and don't produce any UI errors. This is exclusively for installations with the default desktop environment GDM and GNOME.
Acquire access to either a baremetal machine or a VM host, to install a new machine
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
"},{"location":"documentation/QA/Testcase_Post_Artwork_and_Assets/#how-to-test","title":"How to test","text":"
While booting the image check, that the correct logo is visible in the loading screen before Anaconda comes up
Look at the Anaconda images in the rocky-logos repo and check if all assets are correctly applied in Anaconda (they will generally be visible right away while going through the install process)
Install the system with either the Workstation install set or Graphical Server
While the OS does its first boot, check that the correct logo is visible in the loading screen before the boot login screen shows up
Check the logo and background of the boot login screen
After the login check the desktop background and further all available options in the settings menu for the desktop background
Lock the screen and check the background visible in the flyover
At last check the logo and background of the login screen
The tests during the process could be successfully finished.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
REFERENCED RELEASE CRITERIA IS OVERLY GENERAL AND UNTESTABLE
The associated release criteria, Release_Criteria#default-panel-functionality-desktop-only, for this test case is overly general and must be modified to specific enough to be testable.
Associated release criterion
This test case is associated with the Release_Criteria#default-panel-functionality-desktop-only release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
After the login you should have landed on the desktop with the background and the top bar of GNOME visible
Clicking the the Activities button in the upper right should bring up the overview
Further there should be the favourite applications ribbon on the left
And after clicking the 9-dot-icon all applications should appear
Back on the desktop check the function of the system and clock panel on the upper right and middle
It is also a good measure to do some more basic clicking through the GNOME UI, like opening applications, interacting with the application headerbar, moving applications to different desktops or changing settings in the System settings.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#packages-and-module-installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Setting up a IdM system (FreeIPA) and using it's functionality leverages not also a lot of the packages in the official repos, it also tests quite a lot of used functions a corporate environment. This installatation will host it's own dns server for more generic testing without relying on the individual infrastructure of the environment.
A freshly provisioned system (no other functions are allowed on this system except running the IdM services)
IPv4 network with unmanaged domain name (installer will check for dns servers) and unmanaged reverse dns network (in my case here 10.30.30.0/24 and ipa1.network)
In the case of this writeup the external dns server has the domain example.com, this has to have a entry for r8-ipa1-dev.example.com (this could also be replaced by a entry in the /etc/hosts file if no external dns server should be involved)
After installation all services should be available and work correctly.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#keyboard-layout release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
As there are a lot of different keyboard layouts available, it is necessary to test if the keyboard functionality works without any issues throughout the system.
Obtain access to a few different system configurations, especially with and without UI, and not to forget with disk encryption.
Acquire access to either a baremetal machine or a VM host, to install a new machine
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
"},{"location":"documentation/QA/Testcase_Post_Keyboard_Layout/#how-to-test","title":"How to test","text":""},{"location":"documentation/QA/Testcase_Post_Keyboard_Layout/#installer","title":"Installer","text":"
Bootup the installer
Choose a language
Make sure that the keyboard layout got chosen correctly corresponding to the language setting
Change the keyboard layout if needed to test
Enter text all over Anaconda to make sure the keyboard layout works correctly with the chosen keyboard layout
The tests during the process could be successfully finished.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#packages-and-module-installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
For this tests you will need to install every module stream on its own, so it's the best to setup a new system which gets snapshoted after the initial setup. After that it can be rolled back for every module install.
It's enough to setup a system with the Minimal Install group.
"},{"location":"documentation/QA/Testcase_Post_Module_Streams/#how-to-test","title":"How to test","text":"
Login to the machine
Get a list of all module streams and compare it to the stream list from RHEL and to the source in Git source repo
The easiest way to test all streams is to install the package groups in the individual streams, i.e. for postgresql:
All module streams should be available and there shouldn't be any errors while installing any of the package groups of the individual streams. (some of the installs will show warnings though because they are incompatible with other streams)
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#dual-monitor-setup-desktop-only release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
You will need either a machine which can be reinstalled with multiple screens, or a virtualization software which is capable of providing multiple screens (like VMware Workstation (Pro or Player) or VMware Fusion, but there is also a hack for VMware ESXi)
"},{"location":"documentation/QA/Testcase_Post_Multimonitor_Setup/#how-to-test","title":"How to test","text":"
Run installer with multiple screens connected and install with either the Workstation or Graphical Server group
There shouldn't be any graphical glitches, or scaling issues through the install and the usage.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#packages-and-module-installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
REFERENCED RELEASE CRITERIA IS OVERLY GENERAL AND UNTESTABLE
The associated release criteria, Release_Criteria#packages-and-module-installation, for this test case is overly general and must be modified to specific enough to be testable.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Post_SELinux_Errors_Desktop/","title":"QA:Testcase SELinux Errors on Desktop clients","text":"
Release relevance
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#selinux-and-crash-notifications-desktop-only release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Basically running a Workstation or Graphical Server install for a longer amount of time, while using it and then checking if there were any SELinux audit messages.
Open the SETroubleshoot Application and invoke the error summarization.
There must not be shown any errors / denials
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Post_SELinux_Errors_Server/","title":"QA:Testcase SELinux Errors on Server installations","text":"
Release relevance
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#selinux-errors-server release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Install sealert with dnf install setroubleshoot-server
Run sealert -a /var/log/audit/audit.log
There must not be shown any errors / denials
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Post_System_Services/","title":"QA:Testcase System Services","text":"
Release relevance
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#system-services release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
The tests during the process could be successfully finished.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Repo_Compare/","title":"QA:Testcase Media Repo Compare","text":"
Associated release criterion
This test case is associated with the Release_Criteria#repositories-must-match-upstream release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Rocky Linux repositories should match, as closely as possible, upstream repositories.
The content of Rocky Linux packages should match, as closely as possible, upstream repositories.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Storage Volume Resize release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that the installer will successfully resize or delete and overwrite existing partitions on storage volumes.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
"},{"location":"documentation/QA/Testcase_Storage_Volume_Resize/#how-to-test","title":"How to test","text":""},{"location":"documentation/QA/Testcase_Storage_Volume_Resize/#resize","title":"Resize","text":"
From the Installation Destination spoke, in the Storage Configuration section, select the Custom radio button, then click Done.
Expand the list of available partitions by clicking the black arrow to the left of the release version and architecture.
Select the partition you wish to resize. Be sure to uncheck the Reformat checkbox if you wish to resize without reformatting the partition.
Click the Update Settings button to save your settings.
Click the + button to create a new partition off of the existing partition. Provide a mount point and desired capacity, then click Add Mount Point.
Repeat as necessary for additional partitions, or click Done to return to the Anaconda main hub.
From the Installation Destination spoke, in the Storage Configuration section, select the Automatic radio button, then click Done.
You should be presented with an \"Installation Options\" dialog, indicating the amount of disk space that is available for use and available to reclaim.
Click the Reclaim Space button.
Select a partition, then click the Delete button to delete the partition and reclaim the space.
Alternatively, click the Delete All button to delete all existing partitions.
When you have finished, click the Reclaim Space button to reclaim available free space.
The installation should complete and boot successfully.
Resized partitions should correctly reflect the desired size. This may be verified using the lsblk command.
Deleted partitions should no longer exist.
"},{"location":"documentation/QA/Testcase_Storage_Volume_Resize/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_delete_partial
install_delete_pata
install_resize_lvm
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#TBD release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Update Image release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that an update image can be loaded into Anaconda and applied during the install process.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Within the Installation Destination spoke, the selected install disk should have a pink background
FAILPASS
If you cannot verify visually, check for the existence of /tmp/updates, which should contain updated source files if the update was successfully applied. Note that if the update image doesn't actually contain any source files, this directory will not be created.
"},{"location":"documentation/QA/Testcase_Update_Image/#testing-with-openqa","title":"Testing with openQA","text":"
The following openQA test suites satisfy this release criteria:
Red Hat Debug Boot Options Fedora QA:Testcase Anaconda updates.img via URL Fedora QA:Testcase Anaconda updates.img via local media
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#vnc-graphics-mode-behaviors release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case will verify that release-blocking installers function as intended using the VNC installation method on supported systems and classes of hardware.
Supported Systems and Hardware Classes x86_64aarch64ppc64s309x
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Obtain access to remote system with a VNC client installed to use for VNC connection.
Suggested VNC Clients
Both tigervnc and vinagre are VNC clients provided in Rocky Linux but any VNC client may be used.
"},{"location":"documentation/QA/Testcase_VNC_Graphics_Mode/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Custom Boot Methods Boot ISO
Interrupt the kernel boot and specify the appropriate VNC installation option on the boot command line.
Proceed with installation on the test system.Depending on installer choices this MAY destroy all the data on the test system.
Depending on the choice or direct or connect mode connect inbound to the system under test or wait for it to connect to your listening VNC client.
DATA LOSS
If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Connection to (with direct mode) or from (in connect mode) to the Anaconda installer using VNC is possible.
Anaconda installer presents a usable graphical intallation environment.
System under test can be installed normally.
After reboot system boots into graphical environment.
After login user is able to operate the graphical environment.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/dev_guides/commit_signing/","title":"Creating your primary keypair","text":"
Initiate the keypair generation wizard
gpg --full-generate-key --expert\n
Select option (9) ECC and ECC for the key type
Select option (1) Curve 25519 for the elliptic curve
Set a validity period of your choice, ideally less than 1 year
Specify real name and email address to associate with this keypair. The email address must match your verified Github email address or be set to your-github-username@users.noreply.github.com.
Type a passphrase (twice)
"},{"location":"documentation/dev_guides/commit_signing/#create-a-signing-keypair","title":"Create a signing keypair","text":"
"},{"location":"documentation/dev_guides/commit_signing/#remove-the-primary-keypair-from-your-keyring","title":"Remove the primary keypair from your keyring","text":"
"},{"location":"documentation/dev_guides/commit_signing/#renew-an-expired-or-expiring-keypair","title":"Renew an expired or expiring keypair","text":"
gpg --edit-key my@email.addr\n[select a key]\ngpg> expire\n[specify an expiration]\ngpg> save\n
"},{"location":"documentation/dev_guides/commit_signing/#create-a-single-signed-git-commit","title":"Create a single signed git commit","text":"
git commit -S -m \"my awesome signed commit\"\n
"},{"location":"documentation/dev_guides/commit_signing/#configure-git-to-always-sign-commits-with-a-specified-key","title":"Configure git to always sign commits with a specified key","text":"
$ gpg --list-secret-keys --keyid-format=long # grab the fingerprint from the 'sec' line\ngit config [--global] commit.gpgsign true\ngit config [--global] user.signingkey DEADB33FBAD1D3A\n
"},{"location":"documentation/dev_guides/commit_signing/#configure-vscode-to-sign-commits","title":"Configure VSCode to sign commits","text":"
# User or workspace setting\n\"git.enableCommitSigning\": true\n
"},{"location":"documentation/dev_guides/commit_signing/#upload-your-public-key-to-a-keyserver","title":"Upload your public key to a keyserver","text":"
OpenPGP Best Practices Github: Signing Commits Braincoke's Log: Create a GPG Key Creating the Perfect GPG Keypair Digital Neanderthal: Generate GPG Keys With Curve Ed25519
To complete any of the examples below you will need access to a system providing the openQA client. Typically that will be a Fedora based system/container with the openqa-client package and it's (~239) dependencies installed.
"},{"location":"documentation/dev_guides/openqa_access/#access-requirement","title":"Access Requirement","text":""},{"location":"documentation/dev_guides/openqa_access/#api-get-access","title":"API GET access","text":"
The Rocky Linux openQA system allows unrestricted public access via it's web interface or using the openqa-client for GET operations against the API.
"},{"location":"documentation/dev_guides/openqa_access/#api-post-access","title":"API POST access","text":"
In order to use the openQA client to interact with the Rocky Linux openQA system for POST operations the following are required:
an account in good standing in the Rocky Linux Account Services system,
authorization for API POST access from the Rocky Linux Testing Team, and
an openQA API key generated on the Rocky Linux openQA system.
"},{"location":"documentation/dev_guides/openqa_access/#configuring-your-openqa-client","title":"Configuring your openqa client","text":"
Per the openqa client command help you can configure your client to use your API key in a number of ways.
The following example shows how to configure your client by the most common method used. It's possible to configure multiple openqa client API keys in this way.
"},{"location":"documentation/dev_guides/openqa_access/#testing-your-openqa-client-installation","title":"Testing your openqa client installation","text":"
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/dev_guides/openqa_cli_post_examples/","title":"openqa-cli POST Examples","text":"
This page will provide a brief overview of some basic openqa-cliPOST examples.
A basic POST can be used for any of the default test suites for the various Rocky Linux media that are made available. The following examples show some of these standard POSTs that are commonly used by our team and will be used to demonstrate how some minor variations.
This first POST is the most basic, simply providing the minimal set of variables required to trigger the standard test suite for the Rocky Linux 9.1 boot ISO on openqa workers for the x86_64 architecture. All tests of the test suite are predetermined and configure on the openQA server. Since the boot ISO doesn't contain any packages this test suite is effectively a network install from standard Rocky Linux repository servers and/or mirrors.
$ openqa-cli api -X POST isos ISO=Rocky-9.1-x86_64-boot.iso ARCH=x86_64 \\\n DISTRI=rocky FLAVOR=boot-iso VERSION=9.1 CURRREL=9 BUILD=20230409-Rocky-9.1-x86_64.0\n
This POST demonstrates how a different media type, in this case the minimal ISO, for an alternate Rocky Linux version, in this case Rocky Linux 8.7, can be triggered. As can be seen by this and the previous POST the BUILD variable will typically be designate the date, version and architecture of the test suite. Since the minimal ISO contains all packages required to conduct a minimal install of Rocky Linux that is the behavior of this test suite.
$ openqa-cli api -X POST isos ISO=Rocky-8.7-x86_64-minimal.iso ARCH=x86_64 \\\n DISTRI=rocky FLAVOR=minimal-iso VERSION=8.7 CURRREL=8 BUILD=20230409-Rocky-8.7-x86_64.0\n
This POST demonstrates specification of the final normal media type, the dvd ISO, along with what is called a FLAVOR, in this case package-set for the x86_64 architecture and Rocky Linux 9.1. Since the dvd ISO contains all of the packages available at release of a specific version or Rocky Linux the package-set test suite will test installation of all primary installation types of Rocky Linux not included in the minimal-iso test suite above.
$ openqa-cli api -X POST isos ISO=Rocky-9.1-20221214.1-x86_64-dvd.iso ARCH=x86_64 \\\n DISTRI=rocky FLAVOR=package-set VERSION=9.1 CURRREL=9 BUILD=20230409-Rocky-9.1-x86_64.0\n
These three test suites provide for the minimal testing of all ISOs produced for a given release of Rocky Linux.
In addition to the Basic POSTs described above there are additional default test suites that use the dvd ISO media and include substantially more test cases. Those include:
installing in graphical, text and serial console
installation for standard BIOS and UEFI
validation of the Anaconda help system
disk layout variations including LVM, RAID, partition shrink and/or grow, iSCSI and LUKS
PXE installation from various network sources
installation in various languages
Standard POSTs for these test suites is very similar to the basic POSTs above and are shown below...
$ openqa-cli api -X POST isos ISO=Rocky-9.1-20221214.1-x86_64-dvd.iso ARCH=x86_64 \\\n DISTRI=rocky FLAVOR=universal VERSION=9.1 CURRREL=9 BUILD=20230409-Rocky-9.1-x86_64.0\n
"},{"location":"documentation/dev_guides/openqa_cli_post_examples/#collection-of-test-suites-by-build","title":"Collection of test suites by BUILD","text":"
A feature of openQA is that for a given job group test suites which use the same BUILD identifier are collected into a single view in the web UI.
Thus, the examples show above which all use BUILD=20230409-Rocky-9.1-x86_64.0 are all shown in a single view. Additionally, that view is accessible via a predictable URI, for example https://openqa.rockylinux.org/tests/overview?build=20230409-Rocky-9.1-x86_64.0 as shown below...
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This page will provide a brief overview of basic and advanced job cloning using the openqa-clone-custom-git-refspec command.
At a high level openqa-clone-custom-git-refspec can be viewed as a mechanism to test PRs for openQA tests directly in a Rocky Linux openQA instance with making changes to the default configuration. As such, it can support testing of PRs that change test code and needles as long as changes to templates.fif.json are not also required. A combination of openqa-clone-custom-git-refspec and openqa-clone-job (which is actually used by openqa-clone-custom-git-refspec under the hood) can be used for some cases where POST variables are pre-defined in templates.fif.json.
The following example demonstrates the testing of an open Github pull request in the Rocky Linux openQA production system. The PR only changes test code and does not supply updated needles for the test.
NOTE: The Github CLI tool (gh) is used to display PR information statically in this guide.
\u279c os-autoinst-distri-rocky git:(develop) gh pr view 168\nSerial console install #168\nMerged \u2022 AlanMarshall wants to merge 1 commit into develop from serial_console \u2022 about 27 days ago\n+5 -2 \u2022 No checks\nReviewers: akatch (Approved), tcooper (Approved), lumarel (Requested)\nLabels: priority: medium, type: bug, test suite\n\n\n Network is enabled by default at v9 so requires conditional code to handle multiple versions.\n Tested for 9.1, 8.7 & 8.8:\n\n openqa-cli api -X POST isos ISO=Rocky-9.1-20221214.1-x86_64-dvd.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal\n VERSION=9.1 BUILD=-\"$(date +%Y%m%d.%H%M%S).0\"-9.1-20221214.1-universal TEST=install_serial_console\n openqa-cli api -X POST isos ISO=Rocky-8.7-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=8.7 BUILD=-\n \"$(date +%Y%m%d.%H%M%S).0\"-8.7-20221110-universal TEST=install_serial_console\n openqa-cli api -X POST isos ISO=Rocky-8.8-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=8.8 BUILD=-\n \"$(date +%Y%m%d.%H%M%S).0\"-8.8-lookahead-universal TEST=install_serial_console\n\n Result: Tests pass.\n Also confirm that all main hub check boxes are checked and user test created prior to start of installation.\n Fixes Issue #102\n\nView this pull request on GitHub: https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/168\n
Above is the information provided in the original PR and it includes tests performed in Alan's openQA development system. We can rerun failing tests in the Rocky Linux openQA system after identifying an appropriate job ID for each Rocky Linux version we are testing. For this example the openQA WebUI was used to find appropriate test IDs to clone.
"},{"location":"documentation/dev_guides/openqa_clone_custom_git_refspec_examples/#run-openqa-clone-custom-git-refspec-in-verbose-dry-run-mode","title":"Run openqa-clone-custom-git-refspec in --verbose --dry-run mode","text":"
In practice it is useful to run openqa-clone-custom-git-refspec in --verbose and --dry-run mode to observe it's behavior even for the Basic cases...
What can be seen from the complete --dry-run output for openqa-clone-custom-git-refspec is that both the job to be cloned and the PR to be used are inspected and a openqa-clone-job command is generated to be submitted to the openQA system the job is being cloned on.
Without using --dry-run the final openqa-clone-job command shown above will be run causing the job of interest to be cloned with additional POST variables that will cause the repository/branch referenced in the PR to be cloned into the test directory with important files referenced in the cloned job.
"},{"location":"documentation/dev_guides/openqa_clone_custom_git_refspec_examples/#run-openqa-clone-custom-git-refspec-without-verbose-dry-run-mode","title":"Run openqa-clone-custom-git-refspec without --verbose --dry-run mode...","text":"
The following example demonstrates the testing of an open Github pull request in the Rocky Linux openQA production system. The PR changes test code and supplies updated needles for the test.
\u279c os-autoinst-distri-rocky git:(nazunalika/develop) gh pr view 162\n\nAnaconda text install #162\nOpen \u2022 AlanMarshall wants to merge 2 commits into develop from anaconda-txt \u2022 about 1 day ago\n+30 -5 \u2022 No checks\nReviewers: akatch (Approved), lumarel (Requested), tcooper (Requested)\nLabels: priority: medium, type: bug, test suite\n\n\n Added new needle for text install.\n Deleted redundant code.\n Tested for 9.1, 8.7 & 8.8:\n\n openqa-cli api -X POST isos ISO=Rocky-9.1-20221214.1-x86_64-dvd.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal\n VERSION=9.1 BUILD=-\"$(date +%Y%m%d.%H%M%S).0\"-9.1-20221214.1-universal TEST=install_anaconda_text\n openqa-cli api -X POST isos ISO=Rocky-8.7-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=8.7 BUILD=-\n \"$(date +%Y%m%d.%H%M%S).0\"-8.7-20221110-universal TEST=install_anaconda_text\n openqa-cli api -X POST isos ISO=Rocky-8.8-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=8.8 BUILD=-\n \"$(date +%Y%m%d.%H%M%S).0\"-8.8-lookahead-universal TEST=install_anaconda_text\n\n Result: Pass\n Fixes Issue #145\n\n\nakatch approved (Member) \u2022 18h \u2022 Newest comment\n\n All indicated tests pass.\n\n\nView this pull request on GitHub: https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162\n
"},{"location":"documentation/dev_guides/openqa_clone_custom_git_refspec_examples/#run-openqa-clone-custom-git-refspec-in-verbose-dry-run-mode_1","title":"Run openqa-clone-custom-git-refspec in --verbose --dry-run mode","text":"
$ openqa-clone-custom-git-refspec --verbose --dry-run https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162 https://openqa.rockylinux.org/tests/13371\n+ shift\n+ true\n+ case \"$1\" in\n+ dry_run=true\n+ shift\n+ true\n+ case \"$1\" in\n+ shift\n+ break\n+ job_list=https://openqa.rockylinux.org/tests/13371\n+ [[ -z '' ]]\n+ first_arg=https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162\n+ [[ https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162 == *\\p\\u\\l\\l* ]]\n+ pr_url=https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162\n+ target_repo_part=https://github.com/rocky-linux/os-autoinst-distri-rocky\n\n\n...<snip>...\n\n++ jq -r '.NEEDLES_DIR | select (.!=null)'\n+ old_needledir=\n+ local needles_dir=\n+ needles_dir=rocky/needles\n+ local repo_branch=AlanMarshall/os-autoinst-distri-rocky#anaconda-txt\n+ local test_suffix=@AlanMarshall/os-autoinst-distri-rocky#anaconda-txt\n+ local build=AlanMarshall/os-autoinst-distri-rocky#162\n+ local casedir=https://github.com/AlanMarshall/os-autoinst-distri-rocky.git#anaconda-txt\n+ local GROUP=0\n+ local dry_run=true\n+ local scriptdir\n++ dirname /usr/bin/openqa-clone-custom-git-refspec\n+ scriptdir=/usr/bin\n+ local 'cmd=true /usr/bin/openqa-clone-job --skip-chained-deps --parental-inheritance --within-instance \"https://openqa.rockylinux.org\" \"13371\" _GROUP=\"0\" TEST+=\"@AlanMarshall/os-autoinst-distri-rocky#anaconda-txt\" BUILD=\"AlanMarshall/os-autoinst-distri-rocky#162\" CASEDIR=\"https://github.com/AlanMarshall/os-autoinst-distri-rocky.git#anaconda-txt\" PRODUCTDIR=\"os-autoinst-distri-rocky\" NEEDLES_DIR=\"rocky/needles\"'\n+ [[ 0 -ne 0 ]]\n+ [[ -n '' ]]\n+ eval 'true /usr/bin/openqa-clone-job --skip-chained-deps --parental-inheritance --within-instance \"https://openqa.rockylinux.org\" \"13371\" _GROUP=\"0\" TEST+=\"@AlanMarshall/os-autoinst-distri-rocky#anaconda-txt\" BUILD=\"AlanMarshall/os-autoinst-distri-rocky#162\" CASEDIR=\"https://github.com/AlanMarshall/os-autoinst-distri-rocky.git#anaconda-txt\" PRODUCTDIR=\"os-autoinst-distri-rocky\" NEEDLES_DIR=\"rocky/needles\"'\n++ true /usr/bin/openqa-clone-job --skip-chained-deps --parental-inheritance --within-instance https://openqa.rockylinux.org 13371 _GROUP=0 TEST+=@AlanMarshall/os-autoinst-distri-rocky#anaconda-txt BUILD=AlanMarshall/os-autoinst-distri-rocky#162 CASEDIR=https://github.com/AlanMarshall/os-autoinst-distri-rocky.git#anaconda-txt PRODUCTDIR=os-autoinst-distri-rocky NEEDLES_DIR=rocky/needles\n
This PR provides updated needles and the default behavior of openqa-clone-custom-git-refspec is to not provide an alternate location for NEEDLES. The --verbose --dry-run output needs to be modified to ensure the needles provided in the PR are used in the test.
"},{"location":"documentation/dev_guides/openqa_clone_custom_git_refspec_examples/#modify-verbose-dry-run-output-to-point-to-needles-in-the-pr","title":"Modify --verbose --dry-run output to point to needles in the PR...","text":"
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
To complete any of the examples please complete the API POST Access steps outlined in the openQA - Access document.
"},{"location":"documentation/dev_guides/openqa_clone_job_examples/#basic-openqa-clone-job","title":"Basic openqa-clone-job","text":""},{"location":"documentation/dev_guides/openqa_clone_job_examples/#querying-openqa-for-a-specific-test-or-job","title":"Querying openQA for a specific test or job","text":"
First you might want to query the Rocky Linux openQA system for the latest job ID for a specific job or test. The openQA client, hereafter refered to as openqa-cli will allow you to quickly do that via the API. Here is an example...
You can, of course, perform more elaborate operations while cloneing a job either from your local instance or from the production instance. Typically, this might be done to modify some of the job POST variables in the cloned job while keeping all other variables unchanged.
"},{"location":"documentation/dev_guides/openqa_clone_job_examples/#changing-variable-during-clone","title":"Changing variable during clone","text":"
Here is an example where the ISO is changed in the cloned job...
$ openqa-clone-job --from https://openqa.rockylinux.org --skip-download 22735 ISO=Rocky-9.1-x86_64-dvd.iso\nCloning children of rocky-9.1-dvd-iso-x86_64-Build20230423-Rocky-9.1-x86_64.0-install_default_upload@64bit\nCreated job #24: rocky-9.1-dvd-iso-x86_64-Build20230423-Rocky-9.1-x86_64.0-install_default_upload@64bit -> http://localhost/t24\n
"},{"location":"documentation/dev_guides/openqa_clone_job_examples/#difference-between-basic-and-advanced-openqa-clone-job","title":"Difference between Basic and Advanced openqa-clone-job","text":"
You should notice that the only substantive difference between the two cloned jobs is the ISO that is used to run the install_default_upload test...
$ openqa-cli api jobs/23 | jq '.job.settings.ISO'\n\"Rocky-9.1-20221214.1-x86_64-dvd.iso\"\n\n$ openqa-cli api jobs/24 | jq '.job.settings.ISO'\n\"Rocky-9.1-x86_64-dvd.iso\"\n
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/dev_guides/wiki_development_boxes/","title":"How to create a live system to work on the documentation","text":"
There are several ways how to setup your development environment, here are the currently used once by the testing team:
For now here is the link to Trevor's vagrant box setup, this might be merged here in the future!
"},{"location":"documentation/dev_guides/wiki_development_boxes/#manual-setup-for-wsl-and-toolbox","title":"Manual setup for WSL and toolbox","text":""},{"location":"documentation/dev_guides/wiki_development_boxes/#wsl-specific","title":"WSL specific","text":"
Create a WSL machine like described here, make sure to give it a name like rocky-wiki.
Make sure you have toolbox installed on your system
Create a toolbox toolbox create rocky-wiki (on Rocky Linux 8 and 9 machines this will create either a Rocky Linux 8 or 9 toolbox container)
"},{"location":"documentation/dev_guides/wiki_development_boxes/#container-setup-for-both","title":"Container setup for both","text":"
Run dnf -y update to update the system
Run dnf -y install git python39-pip to install Python 3.9 and pip (Python 3.9 is default for Rocky Linux 9, the package is called python3-pip there)
Run python3.9 -m pip install -U pip to update pip
Clone the repo git clone <path-to-git-project>
And get into the folder of the repo cd <git-project-name>
Sometimes you will need to switch the branch here
Install all the requirements of the repo python3.9 -m pip install -r requirements.txt
If you just want to look at the output run mkdocs serve 2>&1 | tee ./mkdocs.serve.log
To develop then, the easiest way is to use VS Code with the Remote - WSL, where you have to open the repo in the container (click on the Remote symbol on the lower left, 'Open folder in WSL...').
For toolbox just place the repo inside your user profile and you will be able to access it with VS Code inside and outside of the toolbox container.
And finally run mkdocs serve 2>&1 | tee ./mkdocs.serve.log in the terminal of this VS Code session. Then you are ready to start changing stuff!
From the root of this repository on a machine with Docker installed, run
docker-compose up\n
When the container finishes starting up, you can access the documentation in your web browser at http://localhost:8000.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Release Requirements documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This section goes over guidelines that the Testing team has set out for anything related to the infrastructure used for testing Rocky Linux.
All guidelines are listed on the left side of this page.
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"guidelines/release_criteria/release_criteria/","title":"Rocky Linux Release Status","text":"
The QA and Testing efforts during releases are tracked in online shared documents. After release the status track and go/no-go documents are published here.
Rocky Linux Version Release Criteria QA and Testing Status QA and Testing GO / NO-GO Summary Official Release Date Rocky Linux 8.5 not available not available not available NOVEMBER 15, 2021 Rocky Linux 8.6 AVAILABLE AVAILABLE AVAILABLE MAY 16, 2022 Rocky Linux 9.0 AVAILABLE AVAILABLE AVAILABLE TBD Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"guidelines/release_criteria/r8/8.6_qa_testing_go_no_go/","title":"Rocky Linux 8.6 QA and Testing : GO / NO GO Status","text":"
This document summarizes the GO / NO GO Status for Release of Rocky Linux 8.6 from perspective of the QA / Testing efforts. It is based largely on the Release Criteria (https://wiki.rockylinux.org/team/testing/release_criteria/) as was started as an import of that document. If there are differences between the official Release Critieria document and this document the official Release Criteria document will override and this document shall be updated.
As a reminder, the objective of a release (major or minor) is to provide a solid Enterprise Linux release that is suitable to: - Meet the needs of end users - Meet the needs of enterprises big or small
This document will record a summary of all QA and Testing results for Rocky Linux 8.6 release. It is only a record of success and/or failure. Solution discussion should take place elsewhere.
Please include PASS, FAIL, NOTABUG, INVESTIGATE or UPSTREAM as appropriate in all entries.
Please only provide brief summary. Details should go to Rocky Pastebin, links here is OK.
Especially for an negative result please leave your MM @handle so we can talk to you to get resolution.
If the item you are reported is related to a QA:Testcase please mention it. If it should be a QA:Testcase, even if it's not a current requirement, suggest a title and create an issue in the wiki repository so we can add it.
errors in all tests in openQA - INVESTIGATE - see openQA section below.
INVESTIGATE whether kdump issue affects qcows with encrypted partitions in createhdds. These are pre-reqs for openQA multi-machine tests. NOTE: This is addressed below in section - @tcooper
KDE and XFCE Life images are broken - INVESTIGATE - @label
Anaconda error when specific steps get executed in the right order (configure network -> disable kdump -> select some os install group -> configure default storage -> configure the storage a second time, but this time with encryption enabled, confirmed via several openqa test suites and manual installation on ESXi) - retested in RC1_2 - UPSTREAM - @lumarel
Issue repeated on RHEL8.6 - @atomicturtle
Issue reported to RH https://bugzilla.redhat.com/show_bug.cgi?id=2085321 - @stack
Minimal: Selecting a SCAP profile with dependencies not available (aide, etc), selecting Ignore dependency during installation will crash anaconda at the final oscap check. NOTABUG, this is for documentation - @atomicturtle
Minimal ISO: is missing the source for rsyslog again, and somehow also doesn't pull it in when installing, which means it is missing it after the install (doesn't happen for boot ISO and dvd1 ISO) - NOTABUG (per @label) - @lumarel
Minimal ISO: if the server base environment is installed with the minimal iso and cockpit is enabled after the installation, the SELinux submenu shows an error \"semanage: command not found\" (doesn't happen with boot/dvd-iso) - also marked as expected - NOTABUG (per @label) - @lumarel
"},{"location":"guidelines/release_criteria/r8/8.6_qa_testing_summary/#manual-success-reported-in-mm","title":"Manual success reported in MM","text":"
minimal install from minimal ISO fine - PASS - @Luna Jernberg
workstation (x86_64) install with applications fine - retested in RC1_2 - PASS - @lumarel
all repos are available with the exact naming as they are in the rocky-repos package (nfv needs fix for that) - retested in RC1_2 - PASS - @lumarel
packer build for 8.6 worked flawlessly - retested by @neil in RC1_2 - PASS - @gmazrael
security profiles look good in anaconda UI - PASS - @atomicturtle (need openQA testing)
minimal and dvd recognized as Rocky Linux 8 in KVM - PASS - @atomicturtle
CIS profiles confirmed good in lvl1/2 in anaconda - PASS - @atomicturtle
DISA profiles confirmed good in anaconda - PASS - @atomicturtle
DVD: libvirt correctly boots when Rocky Linux 8 profile is selected - PASS - @atomicturtle
SELinux checks on Server (x86_64) (letting it run for an hour and run sealert -a /var/log/audit/audit.log) - everything okay - retested in RC1_2 - PASS - @lumarel
SELinux checks on Desktop (x86_64) (start the GNOME SETroubleshooter after some minutes of running) - everything okay - retested in RC1_2 - PASS - @lumarel
DVD: Anaconda manual network configuration, and PCI-DSS SCAP profile selected confirmed good - PASS - @atomicturtle
QA:Testcase_Mediacheck - PASS for all x86_64 ISOs - @tcooper
QA:Testcase_Mediacheck - PASS for all aarch64 ISOs - @tcooper
QA:Testcase Media Repoclosure - PASS for minimal & dvd1 for x86_64 & aarch64 (confirms RelEng results) - @tcooper
QA:Testcase Media File Conflicts - PASS for minimal for x86_64 & aarch64 (0 file conflicts found and 0 package conflicts found) - @tcooper
QA:Testcase Basic Graphics Mode - PASS - verified manually for Rocky-8.6-x86_64-dvd1.iso in VirtualBox on macOS X - @tcooper
DVD: Anaconda install with 3rd party repo, encrypted filesystem, HIPAA SCAP profile selected, confirmed good - PASS - @atomicturtle
Upgrade tests on several test machines from 8.5 to 8.6, no issues no SELinux alerts - PASS - @lumarel
All module streams except perl:5.32 and log4j:2 correctly have the dependencies set and packages look to be built correctly - PASS - @lumarel
log4j module stream was broken, (should be able to hook against java-8 and 11) - got fixed now in RC1_2 - PASS - @lumarel
Anything perl 5.32 (module stream) was broken - got fixed in RC1_2 - PASS - @nazunalika
Greenbone appliance installation test (https://rpa.st/DQNA) - PASS - @atomicturtle
QA:Testcase Debranding for RC2 content from koji (srpms, kernel-rt and pcs are not all on the dvd1) - 46/47 PASS , 1 FALSE PASS - https://rpa.st/raw/QK3A - @tcooper
QA:Testcase Media Consistency Verification (not written yet) for all RC2 ISOs x86_64, aarch64 - PASS - @tcooper
QA:Testcase Media File Conflicts - EXPECTED(per @label) for Rocky-8.6-x86_64-dvd1.iso (4 file conflicts found and 13 package conflicts found, these appear to be same as 8.5 conflict between mariadb and mysql packages/files, full results - https://rpa.st/raw/ZWPQ) - @tcooper
QA:Testcase Media File Conflicts - EXPECTED(per @label) for Rocky-8.6-aarch64-dvd1.iso (modular dependency problems, 3 file conflicts found 4 package conflicts found, full results - https://rpa.st/raw/KOFQ) - @tcooper
QA:Testcase Media File Conflicts for both x86_64 (https://rpa.st/raw/NLGA) and aarch64 (https://rpa.st/raw/4SFQ) are essentially unchanged and remain - EXPECTED(per @label) with RC1_2 ISOs. - @tcooper
OpenQA tests @lumarel - there are errors from the test cases, but everything image and repo related looks good - PASS - @lumarel
the dvd1 iso of aarch64 doesn't show an workstation base environment - it doesn't have an workstation environment - PASS - @lumarel
Installs of aarch64 systems of all 3 isos look good and installs with all base environments work as expected from these - PASS - @lumarel
Live Image Workstation and Workstation Lite looks good - PASS - @lumarel
QA:Testcase Boot Methods Boot Iso - PASS - @neil
QA:Testcase Boot Methods DVD - PASS - @neil
QA: Testcase boot/install minimal x86_64 over DVD/Bluray (burned with fedora mediawriter) on G752 ASUS laptop - PASS - @atomicturtle
Container images for x86_64 and aarch64 work as expected in Docker, Podman and WSL - PASS - @lumarel
QA: Testcase Update Image - PASS - @raktajino (manually checked against Fedora's testcase (https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_URL), needles also still match in openQA)
Upgrade F35 -> F36 needs postgresql-setup --upgrade to convert openqa databse to new format - @alangm
Per discussion in Testing Team meeting we have 4-8 (ish) issues to fix in openQA (needles and code) to be able to complete all tests. @lumarel has created issues our openQA repo (https://github.com/rocky-linux/os-autoinst-distri-rocky) and we'll pick up and resolve ASAP.
"},{"location":"guidelines/release_criteria/r8/8.6_qa_testing_summary/#createhdds-kickstart-file-test-summary","title":"createhdds kickstart file test summary","text":"
Test method: Used packer to build VM. Booted VM. Verified root login. Shutdown VM.
UEFI Testing:
desktop.ks - PASS - Note: resulting image asks for EULA acceptance when booted due to firstboot --enable (unsure if that is desired behavior)
desktopencrypt.ks - PASS - Note: resulting image asks for EULA acceptance when booted due to firstboot --enable (unsure if that is desired behavior)
minimal-uefi.ks - PASS
server.ks - PASS
support.ks - PASS
BIOS Testing:
desktop.ks - PASS - Note: resulting image asks for EULA acceptance when booted due to firstboot --enable (unsure if that is desired behavior)
desktopencrypt.ks - PASS - Note: resulting image asks for EULA acceptance when booted due to firstboot --enable (unsure if that is desired behavior)
minimal.ks - PASS
server.ks - PASS
support.ks - PASS
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/","title":"Rocky Linux 8 Final Release Objectives","text":"
The objective of a release (major or minor) is to provide a solid Enterprise Linux release that is suitable to:
Meet the needs of end users
Meet the needs of enterprises big or small
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#rocky-linux-8-final-release-requirements","title":"Rocky Linux 8 Final Release Requirements","text":"
In order for Rocky Linux to be released to the general public, a compose must be able to meet all the following criteria as provided in this document. This is allows the decision process to be straightforward and as clear as possible. This document only contains \u201chard requirement\u201d items. Optional/nice to have items are not to be included in this list.
There may cases where a requirement cannot be met but only in particular configurations. In these types of cases, the Release Engineering Team should use their judgement to determine whether or not the issue should be considered to block the release. They should consider the number of users likely to be affected by said issue, the severity of the case, if the issue can be avoided with ease (by both informed and uninformed users), and if the problem exists upstream in the current Red Hat Enterprise Linux that the release is based on.
Release-blocking Server
...means bugs as it pertains to server functionality can be considered to block a release. This applies to any packages that provide a service such as httpd, nginx, etc. All architectures apply.
Release-blocking Desktop
...means bugs as it pertains to desktop functionality (GNOME) can be considered to block a release. This applies to both x86_64 and aarch64. Additional desktops (as provided by EPEL or a SIG) are not considered blockers.
Release-blocking Image
...means bugs as it pertains to the images built that can block a release. This applies to the DVD, minimal, and boot images on all architectures.
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#initialization-requirements","title":"Initialization Requirements","text":""},{"location":"guidelines/release_criteria/r8/8_release_criteria/#release-blocking-images-must-boot","title":"Release-blocking images must boot","text":"
Release-blocking installer images must boot when written to optical media or USB flash drive of appropriate sizes (if applicable) via officially supported methods. It is not the testing team\u2019s responsibility to test optical media, but they can and report back. If a bug is found, it is considered a blocker.
Optical Media Requirements
Release-blocking images must boot when written to optical media of an appropriate size. Current size requirements are: boot.iso = 789M, minimal.iso = 2.0G and dvd.iso = 10G.
Officially supported USB flash drive writing methods
The following methods of writing USB flash drives are officially support: dd The following methods of writing USB flash drives are not supported: rufus
The generic video driver option (\u201cbasic graphics mode\u201d) on all release-blocking installers must function as intended. This means launching the installer or desktop and attempting to use a generic driver. There must be no bugs that prevent the installer from being reached in this configuration on all systems and classes of hardware supported by the enterprise linux kernel.
Critical errors, such as undeclared conflicts, unresolved dependencies, or modules relying on packages from another stream will be considered an automatic blocker. There are potential exceptions to this (eg, freeradius cannot be installed on an older perl stream, this is a known issue upstream).
References
Test cases:
QA:Testcase Media Repoclosure
QA:Testcase Media File Conflicts
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#repositories-must-match-upstream","title":"Repositories Must Match Upstream","text":"
Repositories and the packages within them should match upstream as closely as possible. Notable exceptions would be kmods, kpatch, or what is deemed as \u201cspyware\u201d like insights. Packages that are available from upstream should not have hard requirements on RHSM and packages that have it default built in should be patched out.
This means that the installer\u2019s mechanism for verifying the install medium is intact and must complete successfully, with the assumption that the medium was correctly written. It should return a failure message if this not the case.
References
Test cases:
QA:Testcase Media USB dd
QA:Testcase Boot Methods Boot ISO
QA:Testcase Boot Methods DVD
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#packages-and-installer-sources","title":"Packages and Installer Sources","text":"
The installer must be able to use all supported local/remote packages and installer sources.
The installer must be able to create and install to any workable partition layout using any file system or format combination offered or supported by the installer. File systems that are not supported by the EL kernel is not tested here (this means btrfs, zfs, both of wish are not supported).
The installer must be able to detect and install to firmware RAID devices. Note that system-specific bugs do not count as blockers. It is likely that some hardware support might be broken or not available at all. DUDs (driver update disks) are not considered for this criteria.
References
Test cases:
QA:Testcase Firmware RAID
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#bootloader-disk-selection","title":"Bootloader Disk Selection","text":"
The installer must allow the user to choose which disk the bootloader will be installed to or, if the user so chooses, not to install a bootloader.
Any installer mechanism for resizing storage volumes must correctly attempt the requested operation. This means that if the installer offers a way to resize storage volumes, then it must use the correct resizing tool with the correct parameters. However, it does not require the installer to disallow resizing of unformatted or volumes with an unknown filesystem type.
The installer must be able to use an installer update image retrieved from removable media or a remote package source. This includes DUDs (driver update disks).
The installer must correctly display all complete translations that are available for use.
References
Test cases:
QA:Testcase Installer Translations
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#cloud-image-requirements","title":"Cloud Image Requirements","text":""},{"location":"guidelines/release_criteria/r8/8_release_criteria/#images-published-to-cloud-providers","title":"Images Published to Cloud Providers","text":"
Release-blocking cloud disk images must be published to appropriate cloud providers (such as Amazon) and they must successfully boot. This also applies to KVM based instances, such as x86 and aarch64 systems.
All system services present after installation must start properly, with the exception of services that require hardware which is not present. Examples of such services would be:
Computers using two monitors, the graphical output is correctly shown on both monitors.
References
Test cases:
QA:Testcase Multimonitor Setup
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#artwork-and-assets-server-and-desktop","title":"Artwork and Assets (Server and Desktop)","text":"
Proposed final artwork (such as wallpapers and other assets) must be included. A wallpaper from this package should show up as a default for GDM and GNOME.
References
Test cases:
QA:Testcase Artwork and Assets
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#packages-and-module-installation","title":"Packages and Module Installation","text":"
Packages (non-module) should be able to be installed without conflicts or dependent on repositories outside of Rocky Linux.
Default modules (as listed in dnf module list) should be installed without requiring them to be enabled.
Module streams should be able to be switched and those packages should be able to be installed without errors or unresolved dependencies.
References
Test cases:
QA:Testcase Basic Package installs
QA:Testcase Module Streams
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#identity-management-server-setup","title":"Identity Management Server Setup","text":"
It should be possible to setup a IdM server (FreeIPA), use it's functionality and connect clients.
References
Test cases
QA:Testcase Identity Management
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Release Requirements documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"guidelines/release_criteria/r9/9.0_qa_testing_go_no_go/","title":"Rocky Linux 9 QA and Testing : GO / NO GO Status","text":"
This document summarizes the GO / NO GO Status for Release of Rocky Linux 9.0 from perspective of the QA / Testing efforts. It is based largely on the Release Criteria (https://wiki.rockylinux.org/team/testing/release_criteria/) as was started as an import of that document. If there are differences between the official Release Critieria document and this document the official Release Criteria document will override and this document shall be updated.
As a reminder, the objective of a release (major or minor) is to provide a solid Enterprise Linux release that is suitable to: - Meet the needs of end users - Meet the needs of enterprises big or small
Artwork and Assets (Server and Desktop) - PASS - (@lumarel, semi-automatic, openQA)
Packages and Module Installation - PASS - (@lumarel, semi-automatic, openQA)
"},{"location":"guidelines/release_criteria/r9/9.0_qa_testing_summary/","title":"Rocky Linux 9 QA and Testing Summary","text":"
Last updated:"},{"location":"guidelines/release_criteria/r9/9.0_qa_testing_summary/#scope","title":"Scope","text":"
This document will record a summary of all QA and Testing results for Rocky Linux {{ no such element: dict object[9] }} release. It is only a record of success and/or failure. Solution discussion should take place elsewhere.
Please include PASS, FAIL, NOTABUG, INVESTIGATE or UPSTREAM as appropriate in all entries.
Please only provide brief summary. Details should go to Rocky Pastebin, links here is OK.
Please leave your MM @handle on all items you have done or are working on so we can talk to you to get resolution.
If the item you have reported is related to a QA:Testcase please mention it.
If you think the item you have reported should be a QA:Testcase, even if it's not a current requirement, suggest a title and create an issue in the wiki repository so we can add it.
This is a list of items that are being INVESTIGATEd further before being assigned a PASS, FAIL, NOTABUG or UPSTREAM status. PLEASE add your MM handle if you are working on this item to minimize duplication of work. More than one handle is allowed but please communicate.
This is a list of items that have been verified to be replicated UPSTREAM in RHEL {{ no such element: dict object[9] }} and/or are described clearly in the RHEL 9 Release Notes.
This is a list of items that have been verified to FAIL the QA:Testcase. In addition to recording who did the test please indicate if the item is BLOCKING release or not.
RC1 - The blue side banner background at the left side of the Anaconda installer display is not displaying correctly in virt-viewer. [minor BUG] - @alangm
RC1 - QA: Testcase Boot Methods Boot Iso - [PASS] - @alangm - minimal system, graphical server & basic workstation - nothing to report except as above ^^^
RC1 - Minimal install on QEMU/KVM passing - [PASS] - @boris - reboot takes slightly longer on the first reboot
RC1 - Repo Health Check - [PASS] - @lumarel - sqlite database files for repo metadata is missing up to now, which will hinder some applications from syncing the sources - are implemented
RC1 - Repo Health Check - [PASS] - @lumarel - metadata signing not implemented up to now - looks to be implemented as well now
RC1 - Repo Health Check - [PASS] - @lumarel - Repos look good now excl. BaseOS of aarch64, ppc64le, s390x, where the boot image is missing, which is referenced in the .treeinfo
RC1 - Redesign looks to be broken (Post-Install error, effects some of the install groups) - [PASS] - @lumarel
RC1 - Workstation install with known pesign bug - [PASS] - @alangm - error window \"Exit Installer\" button froze Anaconda instead of exit so had to initiate shutdown from cockpit - @lumarel - fixed!
RC1 - Building packages with mock - [PASS] - @hbjy - building works with the mock config from sokels' repo (will be upstreamed for release)
RC1 - Install apache + mariadb-server - [PASS] - @sspencerwire - mariadb-secure-installation works, nextcloud install on top as well
RC1 - Install works on macOS M1 - [PASS] - @netwaze, @gardo984, @jordan_c
RC1 - Install on baremetal went well - [PASS] - @alangm - on a Dell T630
RC1 - Install went well - [PASS] - @kars88 - there was some flickering during the install
RC1.1 dvd - STIG security - [PASS] - @atomicturtle - packages were not complete in RC1 dvd, but are now in RC1.1
RC1.1 - Basic installs work - [PASS] - @mkahric - Virtualbox on Windows (UEFI w/o SB), Workstation Player on Windows (UEFI w/ SB), Hyper-V (UEFI w/ SB)
RC1.1 - docker installation with ansible works - [PASS] - @gardo984
RC1 - Repo Health Check - [PASS] - @lumarel - all repos (x86_64, aarch64, ppc64le, s390x) look good now, all metadata is healthy and all package checksums match
RC1.1 - QA:Testcase Artwork and Assets - [PASS] - @lumarel - no issues found
RC1.1 - QA:Testcase GNOME UI Functionality - [PASS] - @lumarel - everything behaves as it should
RC1.1 - QA:Testcase SELinux Errors on Desktop - [PASS] - @lumarel - After an hour of usage no errors
RC1.1 - QA:Testcase Keyboard Layout - [PASS] - @lumarel - OpenQA tests and manual tests show normal behavior
RC1.1 - QA:Testcase SELinux Errors on Server - [PASS] - @lumarel - after more than an hour of runtime with several installs and application setups (missing, Katello bootstrap, which once brought some SELinux errors)
RC1.1 - QA:Testcase System Services - [PASS] - @lumarel - no errors
RC1.1 - QA: Testcase Installation Interfaces - [PASS] - @raktajino - failures on the Welcome Tour screen because we haven't handled it yet. Everything else seems good.
RC1.1 - QA:Testcase Installer Help - [PASS] - @raktajino - no errors
RC1.1 - QA: Testcase Disk Layouts - [PASS] - @raktajino - Assorted post-install failures due to either mismatch between console login and GUI login or unhandled Welcome Tour.
RC1.1 - QA: Testcase Kickstart Installation - [PASS] - @raktajino - Executed manually with virt-install. Nothing to report.
RC1.1 - QA: Testcase Update Image - [PASS] - @raktajino - failure on _console_wait_login as the GUI login screen is displayed. Update image is applied as expected.
QA:Testcase Basic install boot final ISO - [PASS] - @lumarel
QA:Testcase Basic install minimal final ISO - [PASS] - @lumarel
QA:Testcase Basic installs dvd final ISO - [PASS] - @lumarel - install of every base environment + custom operating system with all options enabled
OpenQA tests with final ISOs - [PASS] - @lumarel - boot-iso 2/2 | minimal-iso 2/2 | minimal 22/26 (failing are all false-positive) | server 21/26 (failing are all false-positive) | package-set 5/5 | workstation 17/26 (failing are all false-positive) | graphical-server 17/26 (failing are all false-positive) | universal 34/43 (failing are all false-positive)
QA:Testcase Module Streams - @lumarel - 9.0 currently does not have any Stream metadata and only the base Streams
Repo Health Check - @lumarel - yumrepofs is not sending content lengths, which make syncing with Katello impossible
Missing package in package group additional-devel - @stack - dnf -y group install additional-devel: No match for group package \"hmaccalc\" - this is an old EL bug
Hosting a nfs server in macOS, and using that in Virtualbox for OpenQA shares is a pain - @tcooper
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/","title":"Rocky Linux 9 Final Release Objectives","text":"
The objective of a release (major or minor) is to provide a solid Enterprise Linux release that is suitable to:
Meet the needs of end users
Meet the needs of enterprises big or small
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#rocky-linux-9-final-release-requirements","title":"Rocky Linux 9 Final Release Requirements","text":"
In order for Rocky Linux to be released to the general public, a compose must be able to meet all the following criteria as provided in this document. This is allows the decision process to be straightforward and as clear as possible. This document only contains \u201chard requirement\u201d items. Optional/nice to have items are not to be included in this list.
There may cases where a requirement cannot be met but only in particular configurations. In these types of cases, the Release Engineering Team should use their judgement to determine whether or not the issue should be considered to block the release. They should consider the number of users likely to be affected by said issue, the severity of the case, if the issue can be avoided with ease (by both informed and uninformed users), and if the problem exists upstream in the current Red Hat Enterprise Linux that the release is based on.
Release-blocking Server
...means bugs as it pertains to server functionality can be considered to block a release. This applies to any packages that provide a service such as httpd, nginx, etc. All architectures apply.
Release-blocking Desktop
...means bugs as it pertains to desktop functionality (GNOME) can be considered to block a release. This applies to both x86_64 and aarch64. Additional desktops (as provided by EPEL or a SIG) are not considered blockers.
Release-blocking Image
...means bugs as it pertains to the images built that can block a release. This applies to the DVD, minimal, and boot images on all architectures.
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#initialization-requirements","title":"Initialization Requirements","text":""},{"location":"guidelines/release_criteria/r9/9_release_criteria/#release-blocking-images-must-boot","title":"Release-blocking images must boot","text":"
Release-blocking installer images must boot when written to optical media or USB flash drive of appropriate sizes (if applicable) via officially supported methods. It is not the testing team\u2019s responsibility to test optical media, but they can and report back. If a bug is found, it is considered a blocker.
Optical Media Requirements
Release-blocking images must boot when written to optical media of an appropriate size. Current size requirements are: boot.iso = 789M, minimal.iso = 2.0G and dvd.iso = 10G.
Officially supported USB flash drive writing methods
The following methods of writing USB flash drives are officially support: dd The following methods of writing USB flash drives are not supported: rufus
The VNC installation option on all release-blocking installers must function as intended. This means launching the installer or desktop and connecting with VNC to complete the installation. There must be no bugs that prevent the installer from being reached in this configuration on all systems and classes of hardware supported by the enterprise linux kernel.
Critical errors, such as undeclared conflicts, unresolved dependencies, or modules relying on packages from another stream will be considered an automatic blocker. There are potential exceptions to this (eg, freeradius cannot be installed on an older perl stream, this is a known issue upstream).
References
Test cases:
QA:Testcase Media Repoclosure
QA:Testcase Media File Conflicts
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#repositories-must-match-upstream","title":"Repositories Must Match Upstream","text":"
Repositories and the packages within them should match upstream as closely as possible. Notable exceptions would be kmods, kpatch, or what is deemed as \u201cspyware\u201d like insights. Packages that are available from upstream should not have hard requirements on RHSM and packages that have it default built in should be patched out.
This means that the installer\u2019s mechanism for verifying the install medium is intact and must complete successfully, with the assumption that the medium was correctly written. It should return a failure message if this not the case.
References
Test cases:
QA:Testcase Media USB dd
QA:Testcase Boot Methods Boot ISO
QA:Testcase Boot Methods DVD
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#packages-and-installer-sources","title":"Packages and Installer Sources","text":"
The installer must be able to use all supported local/remote packages and installer sources.
The installer must be able to create and install to any workable partition layout using any file system or format combination offered or supported by the installer. File systems that are not supported by the EL kernel is not tested here (this means btrfs, zfs, both of wish are not supported).
The installer must be able to detect and install to firmware RAID devices. Note that system-specific bugs do not count as blockers. It is likely that some hardware support might be broken or not available at all. DUDs (driver update disks) are not considered for this criteria.
References
Test cases:
QA:Testcase Firmware RAID
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#bootloader-disk-selection","title":"Bootloader Disk Selection","text":"
The installer must allow the user to choose which disk the bootloader will be installed to or, if the user so chooses, not to install a bootloader.
Any installer mechanism for resizing storage volumes must correctly attempt the requested operation. This means that if the installer offers a way to resize storage volumes, then it must use the correct resizing tool with the correct parameters. However, it does not require the installer to disallow resizing of unformatted or volumes with an unknown filesystem type.
The installer must be able to use an installer update image retrieved from removable media or a remote package source. This includes DUDs (driver update disks).
The installer must correctly display all complete translations that are available for use.
References
Test cases:
QA:Testcase Installer Translations
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#cloud-image-requirements","title":"Cloud Image Requirements","text":""},{"location":"guidelines/release_criteria/r9/9_release_criteria/#images-published-to-cloud-providers","title":"Images Published to Cloud Providers","text":"
Release-blocking cloud disk images must be published to appropriate cloud providers (such as Amazon) and they must successfully boot. This also applies to KVM based instances, such as x86 and aarch64 systems.
All system services present after installation must start properly, with the exception of services that require hardware which is not present. Examples of such services would be:
Computers using two monitors, the graphical output is correctly shown on both monitors.
References
Test cases:
QA:Testcase Multimonitor Setup
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#artwork-and-assets-server-and-desktop","title":"Artwork and Assets (Server and Desktop)","text":"
Proposed final artwork (such as wallpapers and other assets) must be included. A wallpaper from this package should show up as a default for GDM and GNOME.
References
Test cases:
QA:Testcase Artwork and Assets
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#packages-and-module-installation","title":"Packages and Module Installation","text":"
Packages (non-module) should be able to be installed without conflicts or dependent on repositories outside of Rocky Linux.
Default modules (as listed in dnf module list) should be installed without requiring them to be enabled.
Module streams should be able to be switched and those packages should be able to be installed without errors or unresolved dependencies.
References
Test cases:
QA:Testcase Basic Package installs
QA:Testcase Module Streams
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#identity-management-server-setup","title":"Identity Management Server Setup","text":"
It should be possible to setup a IdM server (FreeIPA), use it's functionality and connect clients.
References
Test cases
QA:Testcase Identity Management
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Release Requirements documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"include/contacts_top/","title":"Contacts top","text":""},{"location":"include/contacts_top/#contact-information","title":"Contact Information","text":"Owner Testing Team Email Contact testing@rockylinux.org Mattermost Contacts @stack, @tcooper Mattermost Channels ~Testing"},{"location":"include/content_bottom/","title":"Content bottom","text":"Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"include/members_full/","title":"Members full","text":"Role Name Email Mattermost Name IRC Name Testing Lead Chris Stackpole stack@rockylinux.org @stack Testing Team Al Bowles @raktajino raktajino Testing Team Trevor Cooper tcooper@rockylinux.org @tcooper Testing Team Lukas Magauer lukas@magauer.eu @lumarel Testing Team Alan Marshall @alangm alangm Testing Team Rich Alloway @ralloway Testing Team Anthony Navarro @anavarro10"},{"location":"include/members_no_role/","title":"Members no role","text":"
| Name | Email | Mattermost Name | IRC Name |\n| --------------- | ----------------------- | ------------------ | --------- |\n| Chris Stackpole | stack@rockylinux.org | @stack | |\n| Al Bowles | | @raktajino | raktajino |\n| Trevor Cooper | tcooper@rockylinux.org | @tcooper | |\n| Lukas Magauer | lukas@magauer.eu | @lumarel | |\n| Alan Marshall | | @alangm | alangm |\n| Rich Alloway | | @ralloway | |\n| Anthony Navarro | | @anavarro10 | |\n
"},{"location":"include/qa_content_example_only/","title":"Qa content example only","text":"
CONTENT EXAMPLE ONLY
Content on this page may be copy-pasta from Fedora Quality Assurance documents and needs to be replaced and/or reviewed before publishing for applicability for Rocky Linux.
"},{"location":"include/qa_data_loss_warning/","title":"Qa data loss warning","text":"
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
"},{"location":"include/qa_setup_boot_to_media/","title":"Qa setup boot to media","text":"
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
"},{"location":"include/qa_testcase_bottom/","title":"Qa testcase bottom","text":"Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"include/qa_testcase_supported_systems/","title":"Qa testcase supported systems","text":"Supported Systems and Hardware Classes x86_64aarch64ppc64s309x
TBD
TBD
TBD
TBD
"},{"location":"include/rc_content_bottom/","title":"Rc content bottom","text":"Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Release Requirements documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"include/rc_content_example_only/","title":"Rc content example only","text":"
CONTENT EXAMPLE ONLY
Content on this page may be copied from Fedora Release Requirements documentation and needs to be replaced and/or reviewed before publishing for applicability for Rocky Linux.
This section goes over the various SOP's for the Testing Team. Please use the menu items to find the various pages of interest.
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This SOP covers how the Rocky Linux Testing Team handles requests for Operator access to the openQA system.
"},{"location":"sop/openqa_sop_operator_access/#contact-information","title":"Contact Information","text":"Owner Testing Team Email Contact testing@rockylinux.org Mattermost Contacts @stack, @tcooper Mattermost Channels ~Testing"},{"location":"sop/openqa_sop_operator_access/#responding-to-an-openqa-operator-access-request","title":"Responding to an openQA Operator Access Request","text":"
TODO
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This SOP covers how the Rocky Linux Testing Team handles requests for Operator access removal on the openQA system.
"},{"location":"sop/openqa_sop_operator_removal/#contact-information","title":"Contact Information","text":"Owner Testing Team Email Contact testing@rockylinux.org Mattermost Contacts @stack, @tcooper Mattermost Channels ~Testing"},{"location":"sop/openqa_sop_operator_removal/#responding-to-an-openqa-operator-access-removal","title":"Responding to an openQA Operator Access Removal","text":"
TODO
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"sop/openqa_sop_system_upgrades/","title":"SOP: openQA - System Upgrades","text":"
This SOP details the necessary steps for performing a system upgrade on an openQA host.
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
To identify which packages may need updates, visit the appropriate RepoCompare page, focusing on the SRPM Repo Comparison page for each version. Packages where the Rocky version is lower than the RHEL version likely require an update - you can do a manual comparison to be sure.
"},{"location":"sop/sop_repocompare/#comparing-a-package","title":"Comparing a package","text":"
If the Name/Epoch/Version/Release (NEVR) for the RHEL package is newer than the one for the Rocky package, the package requires an update. In this situation, there will also likely be a newer entry in the changelog for the RHEL package, as shown below:
./manual_compare.sh 9 AppStream golang\nRocky Linux 9.2 golang 1.19.9 2.el9_2 * Tue May 23 2023 Alejandro S\u00e1ez <asm@redhat.com> - 1.19.9-2\nRed Hat golang 1.19.10 1.el9_2 * Tue Jun 06 2023 David Benoit <dbenoit@redhat.com> - 1.19.10-1\n
Notice that the Red Hat golang package has a higher version than the Rocky Linux 9.2 package. It also has a newer entry in its changelog.
Some packages are not considered relevant for repocompare purposes. These include:
rhc\nshim-unsigned\n# Any package that exists in RHEL but not in Rocky (denoted by **DOES NOT EXIST** in the Rocky column on the repocompare website)\n
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"}]}
\ No newline at end of file
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"]},"docs":[{"location":"","title":"Testing Team Wiki","text":""},{"location":"#links","title":"Links","text":"
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"members/","title":"Members","text":"Role Name Email Mattermost Name IRC Name Testing Lead Chris Stackpole stack@rockylinux.org @stack Testing Team Al Bowles @raktajino raktajino Testing Team Trevor Cooper tcooper@rockylinux.org @tcooper Testing Team Lukas Magauer lukas@magauer.eu @lumarel Testing Team Alan Marshall @alangm alangm Testing Team Rich Alloway @ralloway Testing Team Anthony Navarro @anavarro10 Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This section goes over various Documentation for the Testing team. Please use the menu items to find the various pages of interest.
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This page lists all test cases in work and who is working on them...
"},{"location":"documentation/qa_test_cases/#initialization-requirements","title":"Initialization Requirements","text":"Requirement Test Case Assignee Status Release-blocking images must bootRocky Linux 8 Rocky Linux 9 QA:Testcase Boot Methods Boot ISO @tcooper template exists, openQA covered (ref) Release-blocking images must bootRocky Linux 8 Rocky Linux 9 QA:Testcase Boot Methods DVD @tcooper template exists, openQA covered (ref) Basic Graphics Mode behaviorsRocky Linux 8 QA:Testcase Basic Graphics Mode @tcooper openQA TestCase VNC Graphics Mode behaviorsRocky Linux 9 QA:Testcase VNC Graphics Mode @tcooper openQA TestCase No Broken PackagesRocky Linux 8 Rocky Linux 9 QA:Testcase Media RepoclosureQA:Testcase Media File Conflicts @tcooper manual using scripts or automated in CI Repositories Must Match UpstreamRocky Linux 8 Rocky Linux 9 QA:Testcase repocompare @tcooper manual using Skip's repocompare DebrandingRocky Linux 8 Rocky Linux 9 QA:Testcase Debranding Analysis @tcooper manual using scripts or automated in CI"},{"location":"documentation/qa_test_cases/#installer-requirements","title":"Installer Requirements","text":"Requirement Test Case Assignee Status Media Consistency Verification QA:Testcase Media USB ddQA:Testcase Boot Methods Boot ISOQA:Testcase Boot Methods DVD @raktajino Packages and Installer Sources QA:Testcase Packages and Installer Sources @raktajino Implemented in openQA, document NAS (Network Attached Storage) QA:Testcase Network Attached Storage @raktajino Installation Interfaces QA:Testcase Installation Interfaces @raktajino Implemented in openQA, document Minimal Installation QA:Testcase Minimal Installation @raktajino Implemented in openQA, document Kickstart Installation QA:Testcase Kickstart Installation @raktajino Implemented in openQA, document Disk Layouts QA:Testcase Disk Layouts @raktajino Implemented in openQA, document Firmware RAID QA:Testcase Firmware RAID @raktajino Bootloader Disk Selection QA:Testcase Bootloader Disk Selection @raktajino Storage Volume Resize QA:Testcase Storage Volume Resize @raktajino Implemented in openQA, document Update Image QA:Testcase Update Image @raktajino Implemented in openQA, document Installer Help QA:Testcase Installer Help @raktajino Implemented in openQA, document Installer Translations QA:Testcase Installer Translations @raktajino Implemented in openQA, document"},{"location":"documentation/qa_test_cases/#cloud-image-requirements","title":"Cloud Image Requirements","text":"Requirement Test Case Assignee Status Images Published to Cloud Providers QA:Testcase TBD @tbd"},{"location":"documentation/qa_test_cases/#post-installation-requirements","title":"Post-Installation Requirements","text":"Requirement Test Case Assignee Status System Services QA:Testcase System Services @lumarel manual guide documented or needs new openQA testcase Keyboard Layout QA:Testcase Keyboard Layout @lumarel implemented in openQA SELinux Errors (Server) QA:Testcase SELinux Errors on Server @lumarel implemented in openQA SELinux and Crash Notifications (Desktop Only) QA:Testcase SELinux Errors on Desktop @lumarel partly implemented in openQA Default Application Functionality (Desktop Only) QA:Testcase Application Functionality @lumarel manual guide documented Default Panel Functionality (Desktop Only) QA:Testcase GNOME UI Functionality @lumarel implemented in openQA, additionally documented for manual inspection Dual Monitor Setup (Desktop Only) QA:Testcase Multimonitor Setup @lumarel manual guide documented Artwork and Assets (Server and Desktop) QA:Testcase Artwork and Assets @lumarel implemented in openQA, additionally documented for manual inspection Packages and Module Installation QA:Testcase Basic Package installsQA:Testcase Module Streams @lumarel partly implemented in openQA, manual guide documented Identity Management (FreeIPA) QA:Testcase Identity Management @lumarel manual guide documented, PR open for openQA implementation Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
REFERENCED RELEASE CRITERIA IS OVERLY GENERAL AND UNTESTABLE
The associated release criteria, Release_Criteria#basic-graphics-mode-behaviors, for this test case is overly general and must be modified to specific enough to be testable.
Associated release criterion
This test case is associated with the Release_Criteria#basic-graphics-mode-behaviors release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case will verify that release-blocking installers function as intended using the generic video driver option (\u201cbasic graphics mode\u201d) on supported systems and classes of hardware.
Supported Systems and Hardware Classes x86_64aarch64ppc64s309x
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
"},{"location":"documentation/QA/Testcase_Basic_Graphics_Mode/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
In the installer select the appropriate option to intall in basic graphics mode.
Proceed with installation on the test system.Depending on installer choices this MAY destroy all the data on the test system.
DATA LOSS
If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Selection of basic graphics mode in the Anaconda installer is possible.
Anaconda installer presents a usable graphical intallation environment.
System under test can be installed normally.
After reboot system boots into graphical environment.
After login user is able to operate the graphical environment.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#initialization-requirements release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Prepare your system for booting the boot.iso image. This may involve writing the image to a USB key or burning it to an optical disk. Additionally, attaching the boot.iso to a virtual machine instance as a Virtual Optical Disk or mounting the boot.iso to server via baseboard management controller virtual media attach should be possible but is not expressly required.
"},{"location":"documentation/QA/Testcase_Boot_Methods_Boot_Iso/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
In the boot menu select the appropriate option to boot the installer.
Graphical boot menu is displayed for users to select install options. Navigating the menu and selecting entries must work. If no option is selected, the installer should load after a reasonable timeout.
System boots into the Anaconda installer.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#initialization-requirements release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Prepare your system for booting the DVD.iso image. This may involve writing the image to a USB key or burning it to an optical disk of sufficient capacity. Additionally, attaching the DVD.iso to a virtual machine instance as a Virtual Optical Disk or mounting the DVD.iso to server via baseboard management controller virtual media attach should be possible but is not expressly required.
"},{"location":"documentation/QA/Testcase_Boot_Methods_Dvd/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
In the boot menu select the appropriate option to boot the installer.
Graphical boot menu is displayed for users to select install options. Navigating the menu and selecting entries must work. If no option is selected, the installer should load after a reasonable timeout.
System boots into the Anaconda installer.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Bootloader_Disk_Selection/","title":"QA:Testcase Bootloader Disk Selection","text":"
Associated release criterion
This test case is associated with the Release_Criteria#Bootloader Disk Selection release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that the user is able to select an alternative disk on which to install the bootloader. It also verifies that, if the user is so inclined, they may choose not to install a bootloader at all.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
"},{"location":"documentation/QA/Testcase_Bootloader_Disk_Selection/#how-to-test","title":"How to test","text":"
In the Installation Destination spoke, select the disk(s) to install to, then click the \"Full disk summary and bootl loader...\" button at the bottom of the screen:
Click the checkbox next to the disk on which the bootloader is desired
Alternatively, uncheck the boot checkbox next to all disks to skip bootloader installation
Note that if no bootloader is installed, the system may not boot after installation is complete. This is expected.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#vnc-graphics-mode-behaviors release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Prepare your system for booting the boot.iso image. This may involve writing the image to a USB key or burning it to an optical disk. Additionally, attaching the boot.iso to a virtual machine instance as a Virtual Optical Disk or mounting the boot.iso to server via baseboard management controller virtual media attach should be possible but is not expressly required.
"},{"location":"documentation/QA/Testcase_Custom_Boot_Methods_Boot_Iso/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
In the boot menu select the appropriate option to boot the installer.
Interrupt the normal boot and edit the kernel command line.
Add appropriate/required options to the kernel command line and resume booting into the installer.
Example: For network install from an alternate repository add --inst.url=http://<server>/<path_to_BaseOS_repo> and (optionally) --inst.repo=AppStream,http://<server>/<path_to_AppStream_repo> to the kernel command line.
Example: For VNC install in Direct Mode add --inst.vnc to the kernel command line. For VNC install in Connect Mode add --inst.vnc and --inst.vncserver=<host>:<port> to the kernel command line.
Boot menu is displayed for users to select install options. Navigating the menu and selecting entries must work. Editing the boot command line must be possible. If no option is selected, the installer should load after a reasonable timeout.
System boots into the Anaconda installer and any command line options specified are utilized.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria - Debranding release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
The Rocky Linux Release Engineering Team builds and maintains tools to manage the debranding of packages received from the upstream vendor. They have published a comprehensive debranding guide and maintain a list of packages requiring debranding patches.
This testcase will verify that all packages available on released media that Rocky Linux Release Engineering has identified as requiring debranding are debranded successfully per their specification.
Obtain access to an environment with the dnf, and koji commands and access to Rocky Linux Gitlab and Rocky Linux Koji
Download the ISO to be tested to test machine.
Configure /etc/koji.conf to access the Rocky Linux Koji.
Download a recent copy the patch.yml from Rocky Linux Gitlab.
patch.yml
Packages listed in patch.yml are names of source RPMs. Binary RPMs containing content produced by building the patched source RPMs need to be validated. The easiest way to get the list of all possible binary RPMs for a particular package and arch is to ask obtain that information in koji.
"},{"location":"documentation/QA/Testcase_Debranding/#how-to-test","title":"How to test","text":"
Mount the ISO to be tested locally.
Example:
$ mount -o loop Rocky-8.5-x86_64-dvd1.iso /media\n
Determine the path(s) to the repodata directory(ies) on the ISO.
Example:
$ find /media -name repodata\n
For each package to be validated get the names of the noarch and <arch> specific packages created from it.
Example:
$ koji --quiet latest-build --arch=x86_64 dist-rocky8-compose <package>\n$ koji --quiet latest-build --arch=noarch dist-rocky8-compose <package>\n
Use dnf to obtain the paths to the binary packages requiring debranding.
Note all debranding patches will patch files directly and leave very obvious traces, some patches don't even add changelog messages to use as an indicator that the package has been patched or debranded. Sometimes the only solution is to extract the binary package and examine the contents directly to find something to test.
Packages tracked by Release Engineering as requiring debranding and published on installation media are, in fact, debranded per their specification.
Sample Output SuccessFailure
$ sudo mount -o loop Rocky-8.5-aarch64-minimal.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n$ find /media -name repodata\n/media/BaseOS/repodata\n/media/Minimal/repodata\n\n$ curl -LOR https://git.rockylinux.org/rocky/metadata/-/raw/main/patch.yml\n % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n100 3410 100 3410 0 0 20419 0 --:--:-- --:--:-- --:--:-- 20419\n\n$ yq .debrand.all[] patch.yml | column -x -c 100 -o \" \"\nabrt anaconda anaconda-user-help chrony\ncloud-init cockpit crash dhcp\ndnf firefox fwupd gcc\ngcc-toolset-9-gcc gcc-toolset-10-gcc gcc-toolset-11-gcc gcc-toolset-12-gcc\ngnome-settings-daemon grub2 httpd initial-setup\nkernel kernel-rt libdnf libreoffice\nlibreport nginx opa-ff opa-fm\nopenscap pesign PackageKit python-pip\npython3 redhat-rpm-config scap-security-guide shim\nshim-unsigned-x64 shim-unsigned-aarch64 sos subscription-manager\nsystemd thunderbird WALinuxAgent\n\n$ ./yq .debrand.r8[] patch.yml | column -x -c 100 -o \" \"\ndotnet3.0 fwupdate gnome-boxes libguestfs pcs plymouth\npython2\n\nNOTE: Only a single package will be shown in this Example.\n\n$ koji --quiet latest-build --arch=x86_64 dist-rocky8-compose sos\n\n$ koji --quiet latest-build --arch=noarch dist-rocky8-compose sos\nsos-4.1-9.el8_5.rocky.3.noarch\nsos-audit-4.1-9.el8_5.rocky.3.noarch\n\n$ dnf download --urls --repofrompath BaseOS,/media/BaseOS --repo BaseOS \\\n --repofrompath Minimal,/media/Minimal --repo Minimal \\\n sos sos-audit | grep -E \"^file\"\nfile:///media/BaseOS/Packages/s/sos-4.1-5.el8.noarch.rpm\nfile:///media/BaseOS/Packages/s/sos-audit-4.1-5.el8.noarch.rpm\n\n$ rpm -q --changelog -p /media/BaseOS/Packages/s/sos-4.1-5.el8.noarch.rpm | \\\n head | grep \"Release Engineering <releng@rockylinux.org>\" -C2\n* Mon Oct 18 2021 Release Engineering <releng@rockylinux.org> - 4.1-5\n- Remove Red Hat branding from sos\n$ echo $?\n0\n\n$ rpm -q --changelog -p /media/BaseOS/Packages/s/sos-audit-4.1-5.el8.noarch.rpm | \\\n head | grep \"Release Engineering <releng@rockylinux.org>\" -C2\n* Mon Oct 18 2021 Release Engineering <releng@rockylinux.org> - 4.1-5\n- Remove Red Hat branding from sos\n$ echo $?\n0\n\n$ umount /media\n
$ sudo mount -o loop Rocky-8.5-aarch64-minimal.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n$ find /media -name repodata\n/media/BaseOS/repodata\n/media/Minimal/repodata\n\n$ curl -LOR https://git.rockylinux.org/rocky/metadata/-/raw/main/patch.yml\n % Total % Received % Xferd Average Speed Time Time Time Current\n Dload Upload Total Spent Left Speed\n100 3410 100 3410 0 0 20419 0 --:--:-- --:--:-- --:--:-- 20419\n\n$ yq .debrand.all[] patch.yml | column -x -c 100 -o \" \"\nabrt anaconda anaconda-user-help chrony\ncloud-init cockpit crash dhcp\ndnf firefox fwupd gcc\ngcc-toolset-9-gcc gcc-toolset-10-gcc gcc-toolset-11-gcc gcc-toolset-12-gcc\ngnome-settings-daemon grub2 httpd initial-setup\nkernel kernel-rt libdnf libreoffice\nlibreport nginx opa-ff opa-fm\nopenscap pesign PackageKit python-pip\npython3 redhat-rpm-config scap-security-guide shim\nshim-unsigned-x64 shim-unsigned-aarch64 sos subscription-manager\nsystemd thunderbird WALinuxAgent\n\n$ ./yq .debrand.r8[] patch.yml | column -x -c 100 -o \" \"\ndotnet3.0 fwupdate gnome-boxes libguestfs pcs plymouth\npython2\n\nNOTE: Only a single package will be shown in this Example.\n\n$ koji --quiet latest-build --arch=x86_64 dist-rocky8-compose sos\n\n$ koji --quiet latest-build --arch=noarch dist-rocky8-compose sos\nsos-4.1-9.el8_5.rocky.3.noarch\nsos-audit-4.1-9.el8_5.rocky.3.noarch\n\n$ dnf download --urls --repofrompath BaseOS,/media/BaseOS --repo BaseOS \\\n --repofrompath Minimal,/media/Minimal --repo Minimal \\\n sos sos-audit | grep -E \"^file\"\nfile:///media/BaseOS/Packages/s/sos-4.1-5.el8.noarch.rpm\nfile:///media/BaseOS/Packages/s/sos-audit-4.1-5.el8.noarch.rpm\n\n$ rpm -q --changelog -p /media/BaseOS/Packages/s/sos-4.1-5.el8.noarch.rpm | \\\n head | grep \"Release Engineering <releng@rockylinux.org>\" -C2\n$ echo $?\n1\n\n$ rpm -q --changelog -p /media/BaseOS/Packages/s/sos-audit-4.1-5.el8.noarch.rpm | \\\n head | grep \"Release Engineering <releng@rockylinux.org>\" -C2\n$ echo $?\n1\n\n$ umount /media\n
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Disk_Layouts/","title":"QA:Testcase Disk Layouts","text":"
Associated release criterion
This test case is associated with the Release_Criteria#Disk Layouts release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies successful installation to any supported partition layout using any file system or format combination.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
The installation should complete successfully and boot to the appropriate disk.
The specified filesystem type and partition scheme should be used.
If configured, software RAID should function as expected.
"},{"location":"documentation/QA/Testcase_Disk_Layouts/#testing-with-openqa","title":"Testing with openQA","text":"
The following openQA test suites satisfy this release criteria:
install_standard_partition_ext4
install_custom_gui_standard_partition_ext4
install_lvm_ext4
install_custom_gui_lvm_ext4
install_software_raid
install_custom_gui_software_raid
install_xfs
install_custom_gui_xfs
install_lvmthin
install_multi
install_multi_empty
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Firmware RAID release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
The installer must be able to detect and install to firmware RAID devices. Note that system-specific bugs do not count as blockers. It is likely that some hardware support might be broken or not available at all. DUDs (driver update disks) are not considered for this criteria.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Installation Interfaces release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that the installer can complete an installation using all Anaconda spokes.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
The installation should complete and boot successfully.
"},{"location":"documentation/QA/Testcase_Installation_Interfaces/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_arabic_language OR install_asian_language
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Installer Help release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
"},{"location":"documentation/QA/Testcase_Installer_Help/#how-to-test","title":"How to test","text":"
From the Anaconda Hub, click the Help button in the upper right hand corner.
Verify that you see the \"Customizing your Installation\" help page.
Verify that the \"Configuring language and location settings\" link displays a topically appropriate page.
Close the Help browser to return to the Anaconda Hub.
Verify that the Localization help page displays for the Keyboard, Language Support, and Time & Date spokes:
Select the spoke, then click the Help button.
Verify that you see the \"Configuring localization options\" page containing a functioning link to the \"Configuring keyboard, language, and time and date settings\" page.
Close the Help browser (and click Done if necessary) to return to the Anaconda Hub.
Verify that the Help button in the Installation Source spoke displays the \"Configuring installation source\" page.
Verify that the Help button in the Software Selection spoke displays the \"Configuring software selection\" page.
Verify that the Help button in the Installation Destination spoke displays the \"Configuring storage devices\" page.
Verify that the Help button in the Network & Host Name spoke displays the \"Configuring network and host name options\" page.
Verify that the Help button in the Root Password spoke displays the \"Configuring a root password\" page.
Verify that the Help button in the User Creation spoke displays the \"Creating a user account\" page.
All links should work and display relevant content.
"},{"location":"documentation/QA/Testcase_Installer_Help/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
anaconda_help
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Installer Translations release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
All spokes should display at least some of the content in the selected language.
It is expected to still see some content displayed in Latin characters even if a language that does not use Latin characters is selected.
"},{"location":"documentation/QA/Testcase_Installer_Translations/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_asian_language
install_arabic_language
install_cyrillic_language
install_european_language
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Kickstart Installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that installations via both local and remote Kickstart configuration files are successful.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
Hit the Tab key to edit the boot command
Provide a local Kickstart file by supplying the GRUB boot option inst.ks=file:/path/to/local.ks or a remote Kickstart file by supplying the GRUB boot option inst.ks=https://git.resf.org/testing/createhdds/raw/branch/rocky/server.ks.
"},{"location":"documentation/QA/Testcase_Kickstart_Installation/#how-to-test","title":"How to test","text":"
The installation should complete and boot successfully, automatically populating the options specified in the Kickstart file.
"},{"location":"documentation/QA/Testcase_Kickstart_Installation/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_kickstart_nfs
server_realmd_join_kickstart
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Media_File_Conflicts/","title":"QA:Testcase Media File Conflicts","text":"
Associated release criterion
This test case is associated with the Release_Criteria#no-broken-packages release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This testcase will verify that the offline repository included on release blocking images will not contain any file conflicts between packages without explicit Conflicts: tag in the package metadata.
The potential_conflict.py script does not report any packages with non-declared conflicts.
Sample Output SuccessFailure
$ sudo mount -o loop Rocky-8.5-aarch64-minimal.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n$ python3 /vagrant/scripts/potential_conflict.py \\\n --repofrompath BaseOS,/media/BaseOS --repoid BaseOS \\\n --repofrompath Minimal,/media/Minimal --repoid Minimal\n\nAdded BaseOS repo from /media/BaseOS\nAdded Minimal repo from /media/Minimal\nGetting complete filelist for:\nfile:///media/BaseOS\nfile:///media/Minimal\n168374 files found.\n\nLooking for duplicated filenames:\n524 duplicates found.\n\nDoing more advanced checks to see if these are real conflicts:\n 10% complete ( 52/ 524, 1139/sec), 0 found - eta 0:00:00\n 35% complete ( 182/ 524, 1146/sec), 0 found - eta 0:00:00\n 45% complete ( 234/ 524, 1818/sec), 0 found - eta 0:00:00\n 50% complete ( 260/ 524, 592673/sec), 0 found - eta 0:00:00\n 55% complete ( 286/ 524, 778942/sec), 0 found - eta 0:00:00\n 60% complete ( 312/ 524, 801852/sec), 0 found - eta 0:00:00\n 79% complete ( 416/ 524, 234/sec), 0 found - eta 0:00:00\n 84% complete ( 442/ 524, 902/sec), 0 found - eta 0:00:00\n 89% complete ( 468/ 524, 935/sec), 0 found - eta 0:00:00\n 94% complete ( 494/ 524, 1616/sec), 0 found - eta 0:00:00\n 99% complete ( 520/ 524, 1114/sec), 0 found - eta 0:00:00\n\n0 file conflicts found.\n0 package conflicts found.\n\n== Package conflicts ==\n\n== File conflicts, listed by conflicting packages ==\n\n$ sudo umount /media\n
$ sudo mount -o loop Rocky-8.5-x86_64-dvd1.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n\n$ python3 /vagrant/scripts/potential_conflict.py \\\n --repofrompath AppStream,/media/AppStream --repoid AppStream \\\n --repofrompath BaseOS,/media/BaseOS --repoid BaseOS\n\n Added AppStream repo from /media/AppStream\n Added BaseOS repo from /media/BaseOS\n Getting complete filelist for:\n file:///media/AppStream\n file:///media/BaseOS\n 851967 files found.\n\n Looking for duplicated filenames:\n 101865 duplicates found.\n\n Doing more advanced checks to see if these are real conflicts:\n 5% complete ( 5093/101865, 8713/sec), 0 found - eta 0:00:11\n 10% complete ( 10186/101865, 1787281/sec), 0 found - eta 0:00:05\n 15% complete ( 15279/101865, 2223312/sec), 0 found - eta 0:00:03\n 20% complete ( 20372/101865, 23614/sec), 0 found - eta 0:00:03\n 25% complete ( 25465/101865, 57188/sec), 0 found - eta 0:00:02\n 30% complete ( 30558/101865, 3831/sec), 0 found - eta 0:00:05\n 35% complete ( 35651/101865, 48455/sec), 0 found - eta 0:00:04\n 40% complete ( 40744/101865, 32067/sec), 0 found - eta 0:00:03\n 45% complete ( 45837/101865, 2136586/sec), 0 found - eta 0:00:03\n 50% complete ( 50930/101865, 72529/sec), 0 found - eta 0:00:02\n 55% complete ( 56023/101865, 176294/sec), 0 found - eta 0:00:02\n 60% complete ( 61116/101865, 68622/sec), 1 found - eta 0:00:01\n 65% complete ( 66209/101865, 155133/sec), 1 found - eta 0:00:01\n 70% complete ( 71302/101865, 13874/sec), 1 found - eta 0:00:01\n 75% complete ( 76395/101865, 10835/sec), 1 found - eta 0:00:01\n 80% complete ( 81488/101865, 27477/sec), 1 found - eta 0:00:00\n 85% complete ( 86581/101865, 9075/sec), 1 found - eta 0:00:00\n 90% complete ( 91674/101865, 14807/sec), 1 found - eta 0:00:00\n 95% complete ( 96767/101865, 197437/sec), 1 found - eta 0:00:00\n 100% complete (101860/101865, 38727/sec), 1 found - eta 0:00:00\n\n 1 file conflicts found.\n 11 package conflicts found.\n\n == Package conflicts ==\n mariadb-server-utils-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-server-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n python3-mod_wsgi-4.6.4-4.el8.x86_64\n python38-mod_wsgi-4.6.8-3.module+el8.4.0+570+c2eaf144.x86_64\n python39-mod_wsgi-4.7.1-4.module+el8.4.0+574+843c4898.x86_64\n\n libcmpiCppImpl0-2.0.3-15.el8.i686\n tog-pegasus-libs-2:2.14.1-46.el8.i686\n\n mariadb-connector-c-devel-3.1.11-2.el8_3.i686\n mariadb-connector-c-devel-3.1.11-2.el8_3.x86_64\n mariadb-devel-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-devel-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-server-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-server-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-test-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-test-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-connector-c-devel-3.1.11-2.el8_3.i686\n mariadb-connector-c-devel-3.1.11-2.el8_3.x86_64\n mysql-devel-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-devel-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-devel-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n mariadb-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n\n libcmpiCppImpl0-2.0.3-15.el8.x86_64\n tog-pegasus-libs-2:2.14.1-46.el8.x86_64\n\n libev-libevent-devel-4.24-6.el8.i686\n libev-libevent-devel-4.24-6.el8.x86_64\n libevent-devel-2.1.8-5.el8.i686\n libevent-devel-2.1.8-5.el8.x86_64\n\n\n == File conflicts, listed by conflicting packages ==\n mariadb-server-3:10.3.28-1.module+el8.4.0+427+adf35707.x86_64\n mysql-test-8.0.26-1.module+el8.4.0+652+6de068a7.x86_64\n /usr/bin/mysqld_safe\n\n$ sudo umount /media\n
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Media_Repoclosure/","title":"QA:Testcase Media Repoclosure","text":"
Associated release criterion
This test case is associated with the Release_Criteria#no-broken-packages release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
NOTE: In this example the content of the Rocky-8.5-x86_64-minimal.iso was copied to /tmp then the BaseOS repository was modified to remove the setup-2.12.2-6.el8.noarch.rpm package and the repository metadata was regenerated.
[vagrant@localhost ~]$ dnf --refresh repoclosure \\\n --repofrompath BaseOS,/tmp/media/BaseOS --repo BaseOS \\\n --repofrompath Minimal,/tmp/media/Minimal --repo Minimal\nAdded BaseOS repo from /tmp/media/BaseOS\nAdded Minimal repo from /tmp/media/Minimal\nBaseOS 3.7 MB/s | 3.8 kB 00:00\nMinimal 3.7 MB/s | 3.8 kB 00:00\npackage: basesystem-11-5.el8.noarch from BaseOS\n unresolved deps:\n setup\npackage: dump-1:0.4-0.36.b46.el8.x86_64 from BaseOS\n unresolved deps:\n setup\npackage: filesystem-3.8-6.el8.x86_64 from BaseOS\n unresolved deps:\n setup\npackage: initscripts-10.00.15-1.el8.x86_64 from BaseOS\n unresolved deps:\n setup\npackage: rpcbind-1.2.5-8.el8.x86_64 from BaseOS\n unresolved deps:\n setup\npackage: shadow-utils-2:4.6-14.el8.x86_64 from BaseOS\n unresolved deps:\n setup\nError: Repoclosure ended with unresolved dependencies.\n
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Media_USB_dd/","title":"QA:Testcase Media USB dd","text":"
Associated release criterion
This test case is associated with the Release_Criteria#initialization-requirements release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This verifies that Rocky Linux ISO image can be written to USB media using dd command, and the resulting USB media successfully boots to the Anaconda Installer.
DATA LOSS
Any data on the USB stick used for this test is likely to be destroyed. Please do not use a stick whose contents you need to keep.
Provide a USB media device that is larger than the ISO image you wish to test and that it can be completely erased.
Provide a Linux (or other *nix system) that has the dd command available and an unoccupied USB port.
Download the Rocky Linux ISO image you wish to test onto the test system.
Example command:curl -LOR https://dl.rockylinux.org/pub/rocky/8/isos/x86_64/Rocky-x86_64-boot.iso
Download the CHECKSUM file that goes with the Rocky Linux ISO image that you wish to test.
Example command:curl -LOR https://dl.rockylinux.org/pub/rocky/8/isos/x86_64/CHECKSUM
Download the CHECKSUM.sig file that does with the CHECKSUM file.
Example command:curl -LOR https://dl.rockylinux.org/pub/rocky/8/isos/x86_64/CHECKSUM.sig
Download the Rocky Release Engineering GPG key.
Example command:curl -LOR https://dl.rockylinux.org/pub/rocky/RPM-GPG-KEY-rockyofficial
"},{"location":"documentation/QA/Testcase_Media_USB_dd/#how-to-test","title":"How to test","text":"
Import the Rocky Release Engineering GPG key.
Example command:gpg --import RPM-GPG-KEY-rockyofficial
Verify the signature of the CHECKSUM file.
Example command:gpg --verify-file CHECKSUM.sig
Verify the CHECKSUM of the Rocky Linux ISO...
Example command:shasum -a 256 --ignore-missing -c CHECKSUM
Write the Rocky Linux ISO to the USB media using dd...
Example command:dd if=Rocky-8.5-x86_64-boot.iso of=/dev/sdX bs=16M status=progress oflag=direct...where you replace sdX with the device identifier of your USB media.This will destroy all data on the disk.
Boot the test system with the USB media.
In the boot menu select the appropriate option to boot the installer.
[OPTIONAL] Proceed with installation on the test system.Depending on installer choices this MAY destroy all the data on the test system.
The Rocky Linux ISO is written to the USB stick without errors.
The USB stick boots without errors.
The Anaconda Installer starts without errors.
DATA LOSS
If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
[OPTIONALLY] 6. The installation finishes successfully and, if the minimal or DVD ISO were used, the package repository on the USB stick (not a network based repository) was used for the installation.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Minimal Installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that a networked minimal installation is able to install the 'Minimal' package set. The installation should not require use of local packages to complete.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
The installation should complete and boot successfully.
"},{"location":"documentation/QA/Testcase_Minimal_Installation/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_minimal
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Network Attached Storage release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
"},{"location":"documentation/QA/Testcase_Network_Attached_Storage/#how-to-test","title":"How to test","text":""},{"location":"documentation/QA/Testcase_Network_Attached_Storage/#nfs","title":"NFS","text":"
install nfs-utils sudo mount -t nfs nfs-server:/nfs/path /mnt then a created a file echo 1 > /mnt/1 verified it and permissions ls /mnt; cat /mnt/1 then deleted it rm /mnt/1 then unmounted sudo umount /mnt
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Packages_Installer_Sources/","title":"QA:Testcase Packages and Installer Sources","text":"
Associated release criterion
This test case is associated with the Release_Criteria#Packages and Installer Sources release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that the installer can successfully install any of the supported package sets via any of the supported installer sources.
The following package sets are supported for installs from local media:
server
minimal
The following package sets are only available from remote sources and require a network connection:
workstation
graphical-server
virtualization-host
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
The installation should complete and boot successfully.
If a graphical package set was specified, the system should boot to a graphical login screen.
"},{"location":"documentation/QA/Testcase_Packages_Installer_Sources/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria, provided they pass the _do_install_reboot module at a minimum:
install_packageset_server
install_packageset_minimal
install_packageset_workstation
install_packageset_graphical-server
install_packageset_virtualization-host
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Packages_No_Insights/","title":"QA:Testcase Packages No Insights","text":"
Associated release criterion
This test case is associated with the Release_Criteria#repositories-must-match-upstream release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
insights-client is not declared to be installed by default.
Sample Output SuccessFailure
UPDATE SAMPLE
NOTE: This example needs to be refreshed when the 8.6 ISO has been produced. As seen in the Failure section below the Rocky-8.5-x86_64-dvd1.iso includes the insights-client as part of the base group. The package should be included on the DVD ISO but should not be installed automatically.
$ sudo mount -o loop Rocky-8.5-x86_64-dvd1.iso /media\nmount: /media: WARNING: device write-protected, mounted read-only.\n\n$ dnf --refresh --repofrompath BaseOS,/media/BaseOS --repo BaseOS --repofrompath AppStream,/media/AppStream --repo AppStream search insights-client\nAdded BaseOS repo from /media/BaseOS\nAdded AppStream repo from /media/AppStream\nBaseOS 3.8 MB/s | 3.9 kB 00:00\nAppStream 4.2 MB/s | 4.3 kB 00:00\n================================= Name Exactly Matched: insights-client ==================================\ninsights-client.noarch : Uploads Insights information to Red Hat on a periodic basis\n\n$ find /media -name \"*comps*.xml\" -exec grep -H \"insights-client\" '{}' \\;\n/media/AppStream/repodata/a6742e1300e1c786af91656b152d3b98bb7aff598e650509381417970e1f1b7e-comps-AppStream.x86_64.xml: <packagereq type=\"default\">insights-client</packagereq>\n/media/AppStream/repodata/a6742e1300e1c786af91656b152d3b98bb7aff598e650509381417970e1f1b7e-comps-AppStream.x86_64.xml: <packagereq type=\"default\">insights-client</packagereq>\n\n$ dnf --refresh --repofrompath BaseOS,/media/BaseOS --repo BaseOS --repofrompath AppStream,/media/AppStream --repo AppStream groupinfo base | grep -E \":|insights\"\nBaseOS 3.8 MB/s | 3.9 kB 00:00\nAppStream 4.2 MB/s | 4.3 kB 00:00\nGroup: Base\n Description: The standard installation of Rocky Linux.\n Mandatory Packages:\n Default Packages:\n insights-client\n Optional Packages:\n\n$ sudo umount /media\n
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Packages_No_RHSM/","title":"QA:Testcase Packages No RHSM","text":"
Associated release criterion
This test case is associated with the Release_Criteria#repositories-must-match-upstream release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#default-application-functionality-desktop-only release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
REFERENCED RELEASE CRITERIA IS OVERLY GENERAL AND UNTESTABLE
The associated release criteria, Release_Criteria#default-application-functionality-desktop-only, for this test case is overly general and must be modified to specific enough to be testable.
Make sure that the individual applications behave as they should.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Post_Artwork_and_Assets/","title":"QA:Testcase Artwork and Assets","text":"
Release relevance
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#artwork-and-assets-server-and-desktop release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
There are several brand artworks and assets throughout the whole OS, this testcase will take care of checking, that these are actually in place, and don't produce any UI errors. This is exclusively for installations with the default desktop environment GDM and GNOME.
Acquire access to either a baremetal machine or a VM host, to install a new machine
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
"},{"location":"documentation/QA/Testcase_Post_Artwork_and_Assets/#how-to-test","title":"How to test","text":"
While booting the image check, that the correct logo is visible in the loading screen before Anaconda comes up
Look at the Anaconda images in the rocky-logos repo and check if all assets are correctly applied in Anaconda (they will generally be visible right away while going through the install process)
Install the system with either the Workstation install set or Graphical Server
While the OS does its first boot, check that the correct logo is visible in the loading screen before the boot login screen shows up
Check the logo and background of the boot login screen
After the login check the desktop background and further all available options in the settings menu for the desktop background
Lock the screen and check the background visible in the flyover
At last check the logo and background of the login screen
The tests during the process could be successfully finished.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
REFERENCED RELEASE CRITERIA IS OVERLY GENERAL AND UNTESTABLE
The associated release criteria, Release_Criteria#default-panel-functionality-desktop-only, for this test case is overly general and must be modified to specific enough to be testable.
Associated release criterion
This test case is associated with the Release_Criteria#default-panel-functionality-desktop-only release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
After the login you should have landed on the desktop with the background and the top bar of GNOME visible
Clicking the the Activities button in the upper right should bring up the overview
Further there should be the favourite applications ribbon on the left
And after clicking the 9-dot-icon all applications should appear
Back on the desktop check the function of the system and clock panel on the upper right and middle
It is also a good measure to do some more basic clicking through the GNOME UI, like opening applications, interacting with the application headerbar, moving applications to different desktops or changing settings in the System settings.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#packages-and-module-installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Setting up a IdM system (FreeIPA) and using it's functionality leverages not also a lot of the packages in the official repos, it also tests quite a lot of used functions a corporate environment. This installatation will host it's own dns server for more generic testing without relying on the individual infrastructure of the environment.
A freshly provisioned system (no other functions are allowed on this system except running the IdM services)
IPv4 network with unmanaged domain name (installer will check for dns servers) and unmanaged reverse dns network (in my case here 10.30.30.0/24 and ipa1.network)
In the case of this writeup the external dns server has the domain example.com, this has to have a entry for r8-ipa1-dev.example.com (this could also be replaced by a entry in the /etc/hosts file if no external dns server should be involved)
After installation all services should be available and work correctly.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#keyboard-layout release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
As there are a lot of different keyboard layouts available, it is necessary to test if the keyboard functionality works without any issues throughout the system.
Obtain access to a few different system configurations, especially with and without UI, and not to forget with disk encryption.
Acquire access to either a baremetal machine or a VM host, to install a new machine
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
"},{"location":"documentation/QA/Testcase_Post_Keyboard_Layout/#how-to-test","title":"How to test","text":""},{"location":"documentation/QA/Testcase_Post_Keyboard_Layout/#installer","title":"Installer","text":"
Bootup the installer
Choose a language
Make sure that the keyboard layout got chosen correctly corresponding to the language setting
Change the keyboard layout if needed to test
Enter text all over Anaconda to make sure the keyboard layout works correctly with the chosen keyboard layout
The tests during the process could be successfully finished.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#packages-and-module-installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
For this tests you will need to install every module stream on its own, so it's the best to setup a new system which gets snapshoted after the initial setup. After that it can be rolled back for every module install.
It's enough to setup a system with the Minimal Install group.
"},{"location":"documentation/QA/Testcase_Post_Module_Streams/#how-to-test","title":"How to test","text":"
Login to the machine
Get a list of all module streams and compare it to the stream list from RHEL and to the source in Git source repo
The easiest way to test all streams is to install the package groups in the individual streams, i.e. for postgresql:
All module streams should be available and there shouldn't be any errors while installing any of the package groups of the individual streams. (some of the installs will show warnings though because they are incompatible with other streams)
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#dual-monitor-setup-desktop-only release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
You will need either a machine which can be reinstalled with multiple screens, or a virtualization software which is capable of providing multiple screens (like VMware Workstation (Pro or Player) or VMware Fusion, but there is also a hack for VMware ESXi)
"},{"location":"documentation/QA/Testcase_Post_Multimonitor_Setup/#how-to-test","title":"How to test","text":"
Run installer with multiple screens connected and install with either the Workstation or Graphical Server group
There shouldn't be any graphical glitches, or scaling issues through the install and the usage.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#packages-and-module-installation release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
REFERENCED RELEASE CRITERIA IS OVERLY GENERAL AND UNTESTABLE
The associated release criteria, Release_Criteria#packages-and-module-installation, for this test case is overly general and must be modified to specific enough to be testable.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Post_SELinux_Errors_Desktop/","title":"QA:Testcase SELinux Errors on Desktop clients","text":"
Release relevance
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#selinux-and-crash-notifications-desktop-only release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Basically running a Workstation or Graphical Server install for a longer amount of time, while using it and then checking if there were any SELinux audit messages.
Open the SETroubleshoot Application and invoke the error summarization.
There must not be shown any errors / denials
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Post_SELinux_Errors_Server/","title":"QA:Testcase SELinux Errors on Server installations","text":"
Release relevance
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#selinux-errors-server release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Install sealert with dnf install setroubleshoot-server
Run sealert -a /var/log/audit/audit.log
There must not be shown any errors / denials
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Post_System_Services/","title":"QA:Testcase System Services","text":"
Release relevance
This Testcase applies the following versions of Rocky Linux: 8, 9
Associated release criterion
This test case is associated with the Release_Criteria#system-services release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
The tests during the process could be successfully finished.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/QA/Testcase_Repo_Compare/","title":"QA:Testcase Media Repo Compare","text":"
Associated release criterion
This test case is associated with the Release_Criteria#repositories-must-match-upstream release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Rocky Linux repositories should match, as closely as possible, upstream repositories.
The content of Rocky Linux packages should match, as closely as possible, upstream repositories.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Storage Volume Resize release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that the installer will successfully resize or delete and overwrite existing partitions on storage volumes.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
"},{"location":"documentation/QA/Testcase_Storage_Volume_Resize/#how-to-test","title":"How to test","text":""},{"location":"documentation/QA/Testcase_Storage_Volume_Resize/#resize","title":"Resize","text":"
From the Installation Destination spoke, in the Storage Configuration section, select the Custom radio button, then click Done.
Expand the list of available partitions by clicking the black arrow to the left of the release version and architecture.
Select the partition you wish to resize. Be sure to uncheck the Reformat checkbox if you wish to resize without reformatting the partition.
Click the Update Settings button to save your settings.
Click the + button to create a new partition off of the existing partition. Provide a mount point and desired capacity, then click Add Mount Point.
Repeat as necessary for additional partitions, or click Done to return to the Anaconda main hub.
From the Installation Destination spoke, in the Storage Configuration section, select the Automatic radio button, then click Done.
You should be presented with an \"Installation Options\" dialog, indicating the amount of disk space that is available for use and available to reclaim.
Click the Reclaim Space button.
Select a partition, then click the Delete button to delete the partition and reclaim the space.
Alternatively, click the Delete All button to delete all existing partitions.
When you have finished, click the Reclaim Space button to reclaim available free space.
The installation should complete and boot successfully.
Resized partitions should correctly reflect the desired size. This may be verified using the lsblk command.
Deleted partitions should no longer exist.
"},{"location":"documentation/QA/Testcase_Storage_Volume_Resize/#testing-in-openqa","title":"Testing in openQA","text":"
The following openQA test suites satisfy this release criteria:
install_delete_partial
install_delete_pata
install_resize_lvm
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#TBD release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#Update Image release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case verifies that an update image can be loaded into Anaconda and applied during the install process.
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Within the Installation Destination spoke, the selected install disk should have a pink background
FAILPASS
If you cannot verify visually, check for the existence of /tmp/updates, which should contain updated source files if the update was successfully applied. Note that if the update image doesn't actually contain any source files, this directory will not be created.
"},{"location":"documentation/QA/Testcase_Update_Image/#testing-with-openqa","title":"Testing with openQA","text":"
The following openQA test suites satisfy this release criteria:
Red Hat Debug Boot Options Fedora QA:Testcase Anaconda updates.img via URL Fedora QA:Testcase Anaconda updates.img via local media
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This test case is associated with the Release_Criteria#vnc-graphics-mode-behaviors release criterion. If you are doing release validation testing, a failure of this test case may be a breach of that release criterion.
This test case will verify that release-blocking installers function as intended using the VNC installation method on supported systems and classes of hardware.
Supported Systems and Hardware Classes x86_64aarch64ppc64s309x
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Obtain access to remote system with a VNC client installed to use for VNC connection.
Suggested VNC Clients
Both tigervnc and vinagre are VNC clients provided in Rocky Linux but any VNC client may be used.
"},{"location":"documentation/QA/Testcase_VNC_Graphics_Mode/#how-to-test","title":"How to test","text":"
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Custom Boot Methods Boot ISO
Interrupt the kernel boot and specify the appropriate VNC installation option on the boot command line.
Proceed with installation on the test system.Depending on installer choices this MAY destroy all the data on the test system.
Depending on the choice or direct or connect mode connect inbound to the system under test or wait for it to connect to your listening VNC client.
DATA LOSS
If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
Connection to (with direct mode) or from (in connect mode) to the Anaconda installer using VNC is possible.
Anaconda installer presents a usable graphical intallation environment.
System under test can be installed normally.
After reboot system boots into graphical environment.
After login user is able to operate the graphical environment.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/dev_guides/commit_signing/","title":"Creating your primary keypair","text":"
Initiate the keypair generation wizard
gpg --full-generate-key --expert\n
Select option (9) ECC and ECC for the key type
Select option (1) Curve 25519 for the elliptic curve
Set a validity period of your choice, ideally less than 1 year
Specify real name and email address to associate with this keypair. The email address must match your verified Github email address or be set to your-github-username@users.noreply.github.com.
Type a passphrase (twice)
"},{"location":"documentation/dev_guides/commit_signing/#create-a-signing-keypair","title":"Create a signing keypair","text":"
"},{"location":"documentation/dev_guides/commit_signing/#remove-the-primary-keypair-from-your-keyring","title":"Remove the primary keypair from your keyring","text":"
"},{"location":"documentation/dev_guides/commit_signing/#renew-an-expired-or-expiring-keypair","title":"Renew an expired or expiring keypair","text":"
gpg --edit-key my@email.addr\n[select a key]\ngpg> expire\n[specify an expiration]\ngpg> save\n
"},{"location":"documentation/dev_guides/commit_signing/#create-a-single-signed-git-commit","title":"Create a single signed git commit","text":"
git commit -S -m \"my awesome signed commit\"\n
"},{"location":"documentation/dev_guides/commit_signing/#configure-git-to-always-sign-commits-with-a-specified-key","title":"Configure git to always sign commits with a specified key","text":"
$ gpg --list-secret-keys --keyid-format=long # grab the fingerprint from the 'sec' line\ngit config [--global] commit.gpgsign true\ngit config [--global] user.signingkey DEADB33FBAD1D3A\n
"},{"location":"documentation/dev_guides/commit_signing/#configure-vscode-to-sign-commits","title":"Configure VSCode to sign commits","text":"
# User or workspace setting\n\"git.enableCommitSigning\": true\n
"},{"location":"documentation/dev_guides/commit_signing/#upload-your-public-key-to-a-keyserver","title":"Upload your public key to a keyserver","text":"
OpenPGP Best Practices Github: Signing Commits Braincoke's Log: Create a GPG Key Creating the Perfect GPG Keypair Digital Neanderthal: Generate GPG Keys With Curve Ed25519
To complete any of the examples below you will need access to a system providing the openQA client. Typically that will be a Fedora based system/container with the openqa-client package and it's (~239) dependencies installed.
"},{"location":"documentation/dev_guides/openqa_access/#access-requirement","title":"Access Requirement","text":""},{"location":"documentation/dev_guides/openqa_access/#api-get-access","title":"API GET access","text":"
The Rocky Linux openQA system allows unrestricted public access via it's web interface or using the openqa-client for GET operations against the API.
"},{"location":"documentation/dev_guides/openqa_access/#api-post-access","title":"API POST access","text":"
In order to use the openQA client to interact with the Rocky Linux openQA system for POST operations the following are required:
an account in good standing in the Rocky Linux Account Services system,
authorization for API POST access from the Rocky Linux Testing Team, and
an openQA API key generated on the Rocky Linux openQA system.
"},{"location":"documentation/dev_guides/openqa_access/#configuring-your-openqa-client","title":"Configuring your openqa client","text":"
Per the openqa client command help you can configure your client to use your API key in a number of ways.
The following example shows how to configure your client by the most common method used. It's possible to configure multiple openqa client API keys in this way.
"},{"location":"documentation/dev_guides/openqa_access/#testing-your-openqa-client-installation","title":"Testing your openqa client installation","text":"
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/dev_guides/openqa_cli_post_examples/","title":"openqa-cli POST Examples","text":"
This page will provide a brief overview of some basic openqa-cliPOST examples.
A basic POST can be used for any of the default test suites for the various Rocky Linux media that are made available. The following examples show some of these standard POSTs that are commonly used by our team and will be used to demonstrate how some minor variations.
This first POST is the most basic, simply providing the minimal set of variables required to trigger the standard test suite for the Rocky Linux 9.1 boot ISO on openqa workers for the x86_64 architecture. All tests of the test suite are predetermined and configure on the openQA server. Since the boot ISO doesn't contain any packages this test suite is effectively a network install from standard Rocky Linux repository servers and/or mirrors.
$ openqa-cli api -X POST isos ISO=Rocky-9.1-x86_64-boot.iso ARCH=x86_64 \\\n DISTRI=rocky FLAVOR=boot-iso VERSION=9.1 CURRREL=9 BUILD=20230409-Rocky-9.1-x86_64.0\n
This POST demonstrates how a different media type, in this case the minimal ISO, for an alternate Rocky Linux version, in this case Rocky Linux 8.7, can be triggered. As can be seen by this and the previous POST the BUILD variable will typically be designate the date, version and architecture of the test suite. Since the minimal ISO contains all packages required to conduct a minimal install of Rocky Linux that is the behavior of this test suite.
$ openqa-cli api -X POST isos ISO=Rocky-8.7-x86_64-minimal.iso ARCH=x86_64 \\\n DISTRI=rocky FLAVOR=minimal-iso VERSION=8.7 CURRREL=8 BUILD=20230409-Rocky-8.7-x86_64.0\n
This POST demonstrates specification of the final normal media type, the dvd ISO, along with what is called a FLAVOR, in this case package-set for the x86_64 architecture and Rocky Linux 9.1. Since the dvd ISO contains all of the packages available at release of a specific version or Rocky Linux the package-set test suite will test installation of all primary installation types of Rocky Linux not included in the minimal-iso test suite above.
$ openqa-cli api -X POST isos ISO=Rocky-9.1-20221214.1-x86_64-dvd.iso ARCH=x86_64 \\\n DISTRI=rocky FLAVOR=package-set VERSION=9.1 CURRREL=9 BUILD=20230409-Rocky-9.1-x86_64.0\n
These three test suites provide for the minimal testing of all ISOs produced for a given release of Rocky Linux.
In addition to the Basic POSTs described above there are additional default test suites that use the dvd ISO media and include substantially more test cases. Those include:
installing in graphical, text and serial console
installation for standard BIOS and UEFI
validation of the Anaconda help system
disk layout variations including LVM, RAID, partition shrink and/or grow, iSCSI and LUKS
PXE installation from various network sources
installation in various languages
Standard POSTs for these test suites is very similar to the basic POSTs above and are shown below...
$ openqa-cli api -X POST isos ISO=Rocky-9.1-20221214.1-x86_64-dvd.iso ARCH=x86_64 \\\n DISTRI=rocky FLAVOR=universal VERSION=9.1 CURRREL=9 BUILD=20230409-Rocky-9.1-x86_64.0\n
"},{"location":"documentation/dev_guides/openqa_cli_post_examples/#collection-of-test-suites-by-build","title":"Collection of test suites by BUILD","text":"
A feature of openQA is that for a given job group test suites which use the same BUILD identifier are collected into a single view in the web UI.
Thus, the examples show above which all use BUILD=20230409-Rocky-9.1-x86_64.0 are all shown in a single view. Additionally, that view is accessible via a predictable URI, for example https://openqa.rockylinux.org/tests/overview?build=20230409-Rocky-9.1-x86_64.0 as shown below...
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This page will provide a brief overview of basic and advanced job cloning using the openqa-clone-custom-git-refspec command.
At a high level openqa-clone-custom-git-refspec can be viewed as a mechanism to test PRs for openQA tests directly in a Rocky Linux openQA instance with making changes to the default configuration. As such, it can support testing of PRs that change test code and needles as long as changes to templates.fif.json are not also required. A combination of openqa-clone-custom-git-refspec and openqa-clone-job (which is actually used by openqa-clone-custom-git-refspec under the hood) can be used for some cases where POST variables are pre-defined in templates.fif.json.
The following example demonstrates the testing of an open Github pull request in the Rocky Linux openQA production system. The PR only changes test code and does not supply updated needles for the test.
NOTE: The Github CLI tool (gh) is used to display PR information statically in this guide.
\u279c os-autoinst-distri-rocky git:(develop) gh pr view 168\nSerial console install #168\nMerged \u2022 AlanMarshall wants to merge 1 commit into develop from serial_console \u2022 about 27 days ago\n+5 -2 \u2022 No checks\nReviewers: akatch (Approved), tcooper (Approved), lumarel (Requested)\nLabels: priority: medium, type: bug, test suite\n\n\n Network is enabled by default at v9 so requires conditional code to handle multiple versions.\n Tested for 9.1, 8.7 & 8.8:\n\n openqa-cli api -X POST isos ISO=Rocky-9.1-20221214.1-x86_64-dvd.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal\n VERSION=9.1 BUILD=-\"$(date +%Y%m%d.%H%M%S).0\"-9.1-20221214.1-universal TEST=install_serial_console\n openqa-cli api -X POST isos ISO=Rocky-8.7-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=8.7 BUILD=-\n \"$(date +%Y%m%d.%H%M%S).0\"-8.7-20221110-universal TEST=install_serial_console\n openqa-cli api -X POST isos ISO=Rocky-8.8-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=8.8 BUILD=-\n \"$(date +%Y%m%d.%H%M%S).0\"-8.8-lookahead-universal TEST=install_serial_console\n\n Result: Tests pass.\n Also confirm that all main hub check boxes are checked and user test created prior to start of installation.\n Fixes Issue #102\n\nView this pull request on GitHub: https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/168\n
Above is the information provided in the original PR and it includes tests performed in Alan's openQA development system. We can rerun failing tests in the Rocky Linux openQA system after identifying an appropriate job ID for each Rocky Linux version we are testing. For this example the openQA WebUI was used to find appropriate test IDs to clone.
"},{"location":"documentation/dev_guides/openqa_clone_custom_git_refspec_examples/#run-openqa-clone-custom-git-refspec-in-verbose-dry-run-mode","title":"Run openqa-clone-custom-git-refspec in --verbose --dry-run mode","text":"
In practice it is useful to run openqa-clone-custom-git-refspec in --verbose and --dry-run mode to observe it's behavior even for the Basic cases...
What can be seen from the complete --dry-run output for openqa-clone-custom-git-refspec is that both the job to be cloned and the PR to be used are inspected and a openqa-clone-job command is generated to be submitted to the openQA system the job is being cloned on.
Without using --dry-run the final openqa-clone-job command shown above will be run causing the job of interest to be cloned with additional POST variables that will cause the repository/branch referenced in the PR to be cloned into the test directory with important files referenced in the cloned job.
"},{"location":"documentation/dev_guides/openqa_clone_custom_git_refspec_examples/#run-openqa-clone-custom-git-refspec-without-verbose-dry-run-mode","title":"Run openqa-clone-custom-git-refspec without --verbose --dry-run mode...","text":"
The following example demonstrates the testing of an open Github pull request in the Rocky Linux openQA production system. The PR changes test code and supplies updated needles for the test.
\u279c os-autoinst-distri-rocky git:(nazunalika/develop) gh pr view 162\n\nAnaconda text install #162\nOpen \u2022 AlanMarshall wants to merge 2 commits into develop from anaconda-txt \u2022 about 1 day ago\n+30 -5 \u2022 No checks\nReviewers: akatch (Approved), lumarel (Requested), tcooper (Requested)\nLabels: priority: medium, type: bug, test suite\n\n\n Added new needle for text install.\n Deleted redundant code.\n Tested for 9.1, 8.7 & 8.8:\n\n openqa-cli api -X POST isos ISO=Rocky-9.1-20221214.1-x86_64-dvd.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal\n VERSION=9.1 BUILD=-\"$(date +%Y%m%d.%H%M%S).0\"-9.1-20221214.1-universal TEST=install_anaconda_text\n openqa-cli api -X POST isos ISO=Rocky-8.7-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=8.7 BUILD=-\n \"$(date +%Y%m%d.%H%M%S).0\"-8.7-20221110-universal TEST=install_anaconda_text\n openqa-cli api -X POST isos ISO=Rocky-8.8-x86_64-dvd1.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=8.8 BUILD=-\n \"$(date +%Y%m%d.%H%M%S).0\"-8.8-lookahead-universal TEST=install_anaconda_text\n\n Result: Pass\n Fixes Issue #145\n\n\nakatch approved (Member) \u2022 18h \u2022 Newest comment\n\n All indicated tests pass.\n\n\nView this pull request on GitHub: https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162\n
"},{"location":"documentation/dev_guides/openqa_clone_custom_git_refspec_examples/#run-openqa-clone-custom-git-refspec-in-verbose-dry-run-mode_1","title":"Run openqa-clone-custom-git-refspec in --verbose --dry-run mode","text":"
$ openqa-clone-custom-git-refspec --verbose --dry-run https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162 https://openqa.rockylinux.org/tests/13371\n+ shift\n+ true\n+ case \"$1\" in\n+ dry_run=true\n+ shift\n+ true\n+ case \"$1\" in\n+ shift\n+ break\n+ job_list=https://openqa.rockylinux.org/tests/13371\n+ [[ -z '' ]]\n+ first_arg=https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162\n+ [[ https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162 == *\\p\\u\\l\\l* ]]\n+ pr_url=https://github.com/rocky-linux/os-autoinst-distri-rocky/pull/162\n+ target_repo_part=https://github.com/rocky-linux/os-autoinst-distri-rocky\n\n\n...<snip>...\n\n++ jq -r '.NEEDLES_DIR | select (.!=null)'\n+ old_needledir=\n+ local needles_dir=\n+ needles_dir=rocky/needles\n+ local repo_branch=AlanMarshall/os-autoinst-distri-rocky#anaconda-txt\n+ local test_suffix=@AlanMarshall/os-autoinst-distri-rocky#anaconda-txt\n+ local build=AlanMarshall/os-autoinst-distri-rocky#162\n+ local casedir=https://github.com/AlanMarshall/os-autoinst-distri-rocky.git#anaconda-txt\n+ local GROUP=0\n+ local dry_run=true\n+ local scriptdir\n++ dirname /usr/bin/openqa-clone-custom-git-refspec\n+ scriptdir=/usr/bin\n+ local 'cmd=true /usr/bin/openqa-clone-job --skip-chained-deps --parental-inheritance --within-instance \"https://openqa.rockylinux.org\" \"13371\" _GROUP=\"0\" TEST+=\"@AlanMarshall/os-autoinst-distri-rocky#anaconda-txt\" BUILD=\"AlanMarshall/os-autoinst-distri-rocky#162\" CASEDIR=\"https://github.com/AlanMarshall/os-autoinst-distri-rocky.git#anaconda-txt\" PRODUCTDIR=\"os-autoinst-distri-rocky\" NEEDLES_DIR=\"rocky/needles\"'\n+ [[ 0 -ne 0 ]]\n+ [[ -n '' ]]\n+ eval 'true /usr/bin/openqa-clone-job --skip-chained-deps --parental-inheritance --within-instance \"https://openqa.rockylinux.org\" \"13371\" _GROUP=\"0\" TEST+=\"@AlanMarshall/os-autoinst-distri-rocky#anaconda-txt\" BUILD=\"AlanMarshall/os-autoinst-distri-rocky#162\" CASEDIR=\"https://github.com/AlanMarshall/os-autoinst-distri-rocky.git#anaconda-txt\" PRODUCTDIR=\"os-autoinst-distri-rocky\" NEEDLES_DIR=\"rocky/needles\"'\n++ true /usr/bin/openqa-clone-job --skip-chained-deps --parental-inheritance --within-instance https://openqa.rockylinux.org 13371 _GROUP=0 TEST+=@AlanMarshall/os-autoinst-distri-rocky#anaconda-txt BUILD=AlanMarshall/os-autoinst-distri-rocky#162 CASEDIR=https://github.com/AlanMarshall/os-autoinst-distri-rocky.git#anaconda-txt PRODUCTDIR=os-autoinst-distri-rocky NEEDLES_DIR=rocky/needles\n
This PR provides updated needles and the default behavior of openqa-clone-custom-git-refspec is to not provide an alternate location for NEEDLES. The --verbose --dry-run output needs to be modified to ensure the needles provided in the PR are used in the test.
"},{"location":"documentation/dev_guides/openqa_clone_custom_git_refspec_examples/#modify-verbose-dry-run-output-to-point-to-needles-in-the-pr","title":"Modify --verbose --dry-run output to point to needles in the PR...","text":"
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
To complete any of the examples please complete the API POST Access steps outlined in the openQA - Access document.
"},{"location":"documentation/dev_guides/openqa_clone_job_examples/#basic-openqa-clone-job","title":"Basic openqa-clone-job","text":""},{"location":"documentation/dev_guides/openqa_clone_job_examples/#querying-openqa-for-a-specific-test-or-job","title":"Querying openQA for a specific test or job","text":"
First you might want to query the Rocky Linux openQA system for the latest job ID for a specific job or test. The openQA client, hereafter refered to as openqa-cli will allow you to quickly do that via the API. Here is an example...
You can, of course, perform more elaborate operations while cloneing a job either from your local instance or from the production instance. Typically, this might be done to modify some of the job POST variables in the cloned job while keeping all other variables unchanged.
"},{"location":"documentation/dev_guides/openqa_clone_job_examples/#changing-variable-during-clone","title":"Changing variable during clone","text":"
Here is an example where the ISO is changed in the cloned job...
$ openqa-clone-job --from https://openqa.rockylinux.org --skip-download 22735 ISO=Rocky-9.1-x86_64-dvd.iso\nCloning children of rocky-9.1-dvd-iso-x86_64-Build20230423-Rocky-9.1-x86_64.0-install_default_upload@64bit\nCreated job #24: rocky-9.1-dvd-iso-x86_64-Build20230423-Rocky-9.1-x86_64.0-install_default_upload@64bit -> http://localhost/t24\n
"},{"location":"documentation/dev_guides/openqa_clone_job_examples/#difference-between-basic-and-advanced-openqa-clone-job","title":"Difference between Basic and Advanced openqa-clone-job","text":"
You should notice that the only substantive difference between the two cloned jobs is the ISO that is used to run the install_default_upload test...
$ openqa-cli api jobs/23 | jq '.job.settings.ISO'\n\"Rocky-9.1-20221214.1-x86_64-dvd.iso\"\n\n$ openqa-cli api jobs/24 | jq '.job.settings.ISO'\n\"Rocky-9.1-x86_64-dvd.iso\"\n
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"documentation/dev_guides/wiki_development_boxes/","title":"How to create a live system to work on the documentation","text":"
There are several ways how to setup your development environment, here are the currently used once by the testing team:
For now here is the link to Trevor's vagrant box setup, this might be merged here in the future!
"},{"location":"documentation/dev_guides/wiki_development_boxes/#manual-setup-for-wsl-and-toolbox","title":"Manual setup for WSL and toolbox","text":""},{"location":"documentation/dev_guides/wiki_development_boxes/#wsl-specific","title":"WSL specific","text":"
Create a WSL machine like described here, make sure to give it a name like rocky-wiki.
Make sure you have toolbox installed on your system
Create a toolbox toolbox create rocky-wiki (on Rocky Linux 8 and 9 machines this will create either a Rocky Linux 8 or 9 toolbox container)
"},{"location":"documentation/dev_guides/wiki_development_boxes/#container-setup-for-both","title":"Container setup for both","text":"
Run dnf -y update to update the system
Run dnf -y install git python39-pip to install Python 3.9 and pip (Python 3.9 is default for Rocky Linux 9, the package is called python3-pip there)
Run python3.9 -m pip install -U pip to update pip
Clone the repo git clone <path-to-git-project>
And get into the folder of the repo cd <git-project-name>
Sometimes you will need to switch the branch here
Install all the requirements of the repo python3.9 -m pip install -r requirements.txt
If you just want to look at the output run mkdocs serve 2>&1 | tee ./mkdocs.serve.log
To develop then, the easiest way is to use VS Code with the Remote - WSL, where you have to open the repo in the container (click on the Remote symbol on the lower left, 'Open folder in WSL...').
For toolbox just place the repo inside your user profile and you will be able to access it with VS Code inside and outside of the toolbox container.
And finally run mkdocs serve 2>&1 | tee ./mkdocs.serve.log in the terminal of this VS Code session. Then you are ready to start changing stuff!
From the root of this repository on a machine with Docker installed, run
docker-compose up\n
When the container finishes starting up, you can access the documentation in your web browser at http://localhost:8000.
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Release Requirements documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This section goes over guidelines that the Testing team has set out for anything related to the infrastructure used for testing Rocky Linux.
All guidelines are listed on the left side of this page.
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"guidelines/openqa_manual_install/","title":"Manual Install of openQA for rockylinux","text":""},{"location":"guidelines/openqa_manual_install/#intended-audience","title":"Intended Audience","text":"
Those who wish to use the openQA automated testing system configured for Rocky Linux tests. If so, you will need a PC or server with hardware virtualisation running an up-to-date Fedora Linux.
This guide explains the use of the openQA automated testing system to test various aspects of Rocky Linux releases either at the pre-release stage or thereafter.
openQA is an automated test tool that makes it possible to test the whole installation process. It uses virtual machines which it sets up to reproduce the process, check the output (both serial console and GUI screen) in every step and send the necessary keystrokes and commands to proceed to the next step. openQA checks whether the system can be installed, whether it works properly, whether applications work and whether the system responds as expected to different installation options and commands.
Rocky Linux openQA tests can be found in the os-autoinst-distri-rocky repository
openQA can run numerous combinations of tests for every revision of the operating system, reporting the errors detected for each combination of hardware configuration, installation options and variant of the operating system.
The web UI is a very useful feature of the openQA system since it provides an easily accessed view of the progress and details of openQA tests either on the local machine or remotely or both. It is intended to be intuitive and self-explanatory.
Some pages use queries to select what should be shown. The query parameters are generated on clickable links, for example starting from the index page or the group overview page clicking on single builds. On the query pages there can be UI elements to control the parameters, for example to look for older builds or show only failed jobs, or other settings. Additionally, the query parameters can be tweaked by hand if you want to provide a link to specific views.
openQA can be installed only on a Fedora (or OpenSUSE) server or workstation. The following install procedure was tested on Fedora 40 Server. You can use either a local terminal or an ssh login from another host on the lan.
# install Packages\n# for openqa\nsudo dnf install -y openqa openqa-httpd openqa-worker fedora-messaging python3-jsonschema\nsudo dnf install -y perl-REST-Client.noarch\n\n# and for createhdds\nsudo dnf install -y libguestfs-tools libguestfs-xfs python3-fedfind python3-libguestfs\nsudo dnf install -y libvirt libvirt-daemon-config-network libvirt-python3 virt-install withlock\n\n# configure httpd:\ncd /etc/httpd/conf.d/\nsudo cp openqa.conf.template openqa.conf\nsudo cp openqa-ssl.conf.template openqa-ssl.conf\nsudo setsebool -P httpd_can_network_connect 1\nsudo systemctl restart httpd\n\n# configure the web UI\nsudoedit /etc/openqa/openqa.ini\n[global]\nbranding=plain\ndownload_domains = rockylinux.org\n[auth]\nmethod = Fake\n\nsudo dnf install postgresql-server\nsudo postgresql-setup --initdb\n\n# enable and start services\nsudo systemctl enable postgresql --now\nsudo systemctl enable httpd --now\nsudo systemctl enable openqa-gru --now\nsudo systemctl enable openqa-scheduler --now\nsudo systemctl enable openqa-websockets --now\nsudo systemctl enable openqa-webui --now\nsudo systemctl enable fm-consumer@fedora_openqa_scheduler --now\nsudo systemctl enable libvirtd --now\nsudo setsebool -P httpd_can_network_connect 1\nsudo firewall-cmd --add-service=http --permanent\nsudo firewall-cmd --reload\nsudo systemctl restart httpd\n\n# to create API key in local web interface at http://localhost\n# or on remote system http://<ip addr>\n# Click Login, then Manage API Keys, create a key and secret.\n\n# insert key and secret\nsudoedit /etc/openqa/client.conf\n\n[localhost]\nkey = ...\nsecret = ...\n\n# create workers\nsudo systemctl enable openqa-worker@1 --now\n# then ...@2 ...etc as desired. Look in webui workers to check shown idle.\n# as a rule of thumb, you can have about half the number of workers as cores\n\n# get Rocky tests\ncd /var/lib/openqa/tests/\nsudo git clone https://github.com/rocky-linux/os-autoinst-distri-rocky.git rocky\nsudo chown -R geekotest:geekotest rocky\ncd rocky\n\n# when working in /var/lib/openqa nearly all commands need sudo.\n\nsudo git config --global --add safe.directory /var/lib/openqa/share/tests/rocky\n\nsudo git checkout develop\n# or whichever branch has the latest updates for your tests\n\nsudo ./fifloader.py -l -c templates.fif.json\nsudo git clone https://github.com/rocky-linux/createhdds.git ~/createhdds\nsudo mkdir -p /var/lib/openqa/share/factory/hdd/fixed\n\n# will need about 200GB disk space available for ongoing tests\ncd /var/lib/openqa/factory/hdd/fixed\n\n# start a long running process that provides hdd image files for ongoing tests\n~/createhdds/createhdds.py -t -b stg all\n\n# get Rocky iso files for testing from staging repository\nsudo mkdir -p /var/lib/openqa/share/factory/iso/fixed\ncd /var/lib/openqa/factory/iso/fixed\n\nsudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-boot.iso\nsudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-minimal.iso\nsudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/Rocky-9.3-x86_64-dvd.iso\nsudo curl -LOR https://dl.rockylinux.org/stg/rocky/9/isos/x86_64/CHECKSUM\n\nsha256sum -c CHECKSUM\n\n# fix ownership, add <user> to group, reboot\ncd /var/lib/openqa/factory/\nsudo chown -R geekotest:geekotest ./\nsudo usermod -aG geekotest <user>\nsudo init 6\n\n# post tests and view progress on webui\ncd /var/lib/openqa/tests/rocky/\nsudo ./fifloader.py -c -l templates.fif.json\nsudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-minimal.iso ARCH=x86_64 DISTRI=rocky FLAVOR=minimal-iso VERSION=9.3 BUILD=\"$(date +%Y%m%d.%H%M%S).0\"-minimal\nsudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-boot.iso ARCH=x86_64 DISTRI=rocky FLAVOR=boot-iso VERSION=9.3 BUILD=\"$(date +%Y%m%d.%H%M%S).0\"-boot\nand for a full build (this will post 95 jobs)\nsudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-dvd.iso ARCH=x86_64 DISTRI=rocky FLAVOR=dvd-iso VERSION=9.3 BUILD=\"$(date +%Y%m%d.%H%M%S).0\"-dvd-iso\nsudo openqa-cli api -X POST isos ISO=Rocky-9.3-x86_64-dvd.iso ARCH=x86_64 DISTRI=rocky FLAVOR=universal VERSION=9.3 BUILD=\"$(date +%Y%m%d.%H%M%S).0\"-universal\n
You can watch progress of these tests on the webui on any browser on the same lan as the test host at
http://<ip_addr_of_test_host>/tests
If you click \"login\" in the top right corner you will be able to control tests from the webui.
At this point the multi-vm tests will fail or be skipped. This is because at the moment your system is configured for single vm deployment and it can be used as such. Pause your installation here if you wish to get some practice using openQA before progressing further (recommended).
Installation of facilities for multi-vm testing, which is substantially more complicated, will be described in this document in a later revision (watch this space).
Createhdds is used to prepare .img and .qcow2 files for some of the Rocky tests. If you ran the above procedure you will have noticed that it produces a number of files in /var/lib/openqa/factory/hdd/fixed determined by the files provided in createhdds.
Tests are normally posted using openqa-cli as you have already used above. Test parameters are listed and explained in the openQA VARIABLES definition document
One of the challenges that arises when testing an operating system, especially when doing continuous testing, is that there is always a certain combination of jobs, each one with its own settings, that needs to be run for every revision. These combinations can be different for different FLAVORs of the same revision, like running a different set of jobs for each architecture. This combinational problem can go one step further if openQA is being used for different kinds of tests, like running some simple pre-integration tests for some snapshots combined with more comprehensive post-integration tests for release candidates.
This section describes how an instance of openQA could be configured using the options in the admin area of the webUI to automatically create all the required jobs for each revision of your operating system that needs to be tested. If you were starting from scratch (the difficult way), you would probably go through the following order:
Define machines in 'Machines' menu
Define medium types (products) you have in 'Medium types' menu
Specify various collections of tests you want to run in the 'Test suites' menu
Define job groups in 'Job groups' menu for groups of tests
Select individual 'Job groups' and decide what combinations make sense and need to be tested
If you followed the install guide above then the cloned Rocky tests from os-autoinst-distri-rocky will have pre-configured the admin area of the webUI. You may find it useful to consult when reading the following sections.
Machines, mediums, test suites and job templates can all set various configuration variables. The job templates within the job groups define how the test suites, mediums and machines should be combined in various ways to produce individual 'jobs'. All the variables from the test suite, medium, machine and job template are combined and made available to the actual test code run by the 'job', along with variables specified as part of the job creation request. Certain variables also influence openQA\u2019s and/or os-autoinst\u2019s own behavior in terms of how it configures the environment for the job.
The configuration is set up from /var/lib/openqa/tests/rocky/templates.fif.json
You need to have at least one machine set up to be able to run any tests. These machines represent virtual machine types that you want to test. Realistically to make tests actually happen, you have to have a number of openQA workers connected that can fulfill these specifications.
Name User defined string - only needed for operator to identify the machine configuration.
Backend What backend should be used for this machine Recommended value is qemu as it is the most tested one, but other options such as kvm2usb or vbox are also possible.
Variables Most machine variables influence os-autoinst\u2019s behavior in terms of how the test machine is set up. A few important examples:
QEMUCPU can be qemu32 or qemu64 and specifies the architecture of the virtual CPU
QEMUCPUS is an integer that specifies the number of cores you wish to be used
USBBOOT when set to 1 the image will be loaded through an emulated USB stick.
A medium type product in openQA is a simple description without any definite meaning. It basically consists of a name and a set of variables that define or characterise this product in os-autoinst.
Some example variables are:
ISO_MAXSIZE contains the maximum size of the product. There is a test that checks that the current size of the product is less or equal than this variable.
DVD if it is set to 1 this indicates that the medium is a DVD.
LIVECD if it is set to 1 this indicates that the medium is a live image (can be a CD or USB)
GNOME this variable, if it is set to 1 indicates that it is a GNOME only distribution.
A test suite consists of a name and a set of test variables that are used inside this particular test together with an optional description. The test variables can be used to parameterise the actual test code and influence the behaviour according to the settings.
Some sample variables are:
DESKTOP possible values are kdegnomelxdexfce or textmode. Used to indicate the desktop selected by the user during the test.
The job groups are the place where the actual test scenarios are defined by the selection of the medium type, the test suite and machine together with a priority value.
The priority value is used in the scheduler to choose the next job. If multiple jobs are scheduled and their requirements for running them are fulfilled the ones with a lower priority value are triggered. The id is the second sorting key of two jobs with equal requirements and same priority value the one with lower id is triggered first.
Job groups themselves can be created over the web UI as well as the REST API. Job groups can optionally be nested into categories. The display order of job groups and categories can be configured by drag-and-drop in the web UI.
The scenario definitions within the job groups can be created and configured by different means:
A simple web UI wizard which is automatically shown for job groups when a new medium is added to the job group.
An intuitive table within the web UI for adding additional test scenarios to existing media including the possibility to configure the priority values.
The scripts openQA-load-templates and openQA-dump-templates to quickly dump and load the configuration from custom plain-text dump format files using the REST API.
Using declarative schedule definitions in the YAML format using REST API routes or an online-editor within the web UI including a syntax checker.
Needles are very precise and the slightest deviation from the specified display will be detected. This means that every time there is a new release, very small changes occur in layout of displays resulting in many new or modified needles being required. There is always a significant amount of work needed by the Test Team to produce the automatic tests for a new version.
A very useful feature of the webui is the online needle editor. When a test fails for a missing needle, the needle editor can be activated by clicking the icon and a new needle can be created, usually by copying a similar needle together with the current screenshot. The needle files are saved in the /var/lib/openqa/tests/rocky/needles directory
Starter Guide and Upstream documentation are useful for reference but since they are a mixture of advice and instructions relating to openSUSE and Fedora which have substantial differences between them it is not always clear which are significant for Rocky. However, as an rpm based distribution, Rocky Linux use is loosely related to the Fedora version.
The following terms are used within the context of openQA:-
test module
An individual test case in a single perl module .pm file, e.g. sshxterm If not further specified a test module is denoted with its short name equivalent to the filename including the test definition. The full name is composed of the test group, which itself is formed by the top-folder of the test module file, and the short name, e.g. x11-sshxterm (for x11/sshxterm.pm)
test suite
A collection of test modules, e.g. textmode All test modules within one test suite are run serially
One run of individual test cases in a row denoted by a unique number for one instance of openQA, e.g. one installation with subsequent testing of applications within gnome
test run
Equivalent to job
test result
The result of one job, e.g. passed with the details of each individual test module
test step
the execution of one test module within a job
distri
A test distribution but also sometimes referring to a product (CAUTION: ambiguous, historically a \"GNU/Linux distribution\"), composed of multiple test modules in a folder structure that composes test suites, e.g. rocky (test distribution, short for os-autoinst-distri-rocky)
product
The main system under test (SUT) e.g. rocky also called Medium Types in the web interface of openQA
job group
Equivalent to product, used in context of the webUI
version
One version of a product, don\u2019t confuse with build
flavor
Keyword for a specific variant of a product to distinguish differing variants, e.g. dvd-iso
arch
An architecture variant of a product, e.g. x86_64
machine
Additional variant of machine, e.g. used for 64bitbiosuefi etc.
scenario
A composition of <distri>-<version>-<flavor>-<arch>-<test_suite>@<machine> e.g. Rocky-9-dvd-x86_64-gnome@64bit
build
Different versions of a product as tested, can be considered a sub-version of version, e.g. Build1234 CAUTION: ambiguity: either with the prefix build included or not
openQA started with OS-autoinst: automated testing of Operating Systems The OS-autoinst project aims at providing a means to run fully automated tests, especially to run tests of basic and low-level operating system components such as bootloader, kernel, installer and upgrade, which can not easily be tested with other automated testing frameworks. However, it can just as well be used to test firefox and openoffice operation on top of a newly installed OS. openQA is a test-scheduler and web-front for openSUSE and Fedora using OS-autoinst as a backend. openQA originated at openSuse and was adopted by Fedora as the automated test system for their frequent distribution updates. Maintenance activity is fairly intense and is ongoing at various levels of users. openQA was adopted by Rocky Linux Test Team as the preferred automated testing system for the ongoing releases of it's distribution. openQA is free software released under the GPLv2 license.
Since Rocky Linux use of openQA is drawn from upstream Fedora and hence openSUSE this document contains many passages which are edited versions of upstream documentation and that use is hereby gratefully acknowledged. As with many open source projects, we build on previous work.
"},{"location":"guidelines/release_criteria/release_criteria/","title":"Rocky Linux Release Status","text":"
The QA and Testing efforts during releases are tracked in online shared documents. After release the status track and go/no-go documents are published here.
Rocky Linux Version Release Criteria QA and Testing Status QA and Testing GO / NO-GO Summary Official Release Date Rocky Linux 8.5 not available not available not available NOVEMBER 15, 2021 Rocky Linux 8.6 AVAILABLE AVAILABLE AVAILABLE MAY 16, 2022 Rocky Linux 9.0 AVAILABLE AVAILABLE AVAILABLE TBD Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"guidelines/release_criteria/r8/8.6_qa_testing_go_no_go/","title":"Rocky Linux 8.6 QA and Testing : GO / NO GO Status","text":"
This document summarizes the GO / NO GO Status for Release of Rocky Linux 8.6 from perspective of the QA / Testing efforts. It is based largely on the Release Criteria (https://wiki.rockylinux.org/team/testing/release_criteria/) as was started as an import of that document. If there are differences between the official Release Critieria document and this document the official Release Criteria document will override and this document shall be updated.
As a reminder, the objective of a release (major or minor) is to provide a solid Enterprise Linux release that is suitable to: - Meet the needs of end users - Meet the needs of enterprises big or small
This document will record a summary of all QA and Testing results for Rocky Linux 8.6 release. It is only a record of success and/or failure. Solution discussion should take place elsewhere.
Please include PASS, FAIL, NOTABUG, INVESTIGATE or UPSTREAM as appropriate in all entries.
Please only provide brief summary. Details should go to Rocky Pastebin, links here is OK.
Especially for an negative result please leave your MM @handle so we can talk to you to get resolution.
If the item you are reported is related to a QA:Testcase please mention it. If it should be a QA:Testcase, even if it's not a current requirement, suggest a title and create an issue in the wiki repository so we can add it.
errors in all tests in openQA - INVESTIGATE - see openQA section below.
INVESTIGATE whether kdump issue affects qcows with encrypted partitions in createhdds. These are pre-reqs for openQA multi-machine tests. NOTE: This is addressed below in section - @tcooper
KDE and XFCE Life images are broken - INVESTIGATE - @label
Anaconda error when specific steps get executed in the right order (configure network -> disable kdump -> select some os install group -> configure default storage -> configure the storage a second time, but this time with encryption enabled, confirmed via several openqa test suites and manual installation on ESXi) - retested in RC1_2 - UPSTREAM - @lumarel
Issue repeated on RHEL8.6 - @atomicturtle
Issue reported to RH https://bugzilla.redhat.com/show_bug.cgi?id=2085321 - @stack
Minimal: Selecting a SCAP profile with dependencies not available (aide, etc), selecting Ignore dependency during installation will crash anaconda at the final oscap check. NOTABUG, this is for documentation - @atomicturtle
Minimal ISO: is missing the source for rsyslog again, and somehow also doesn't pull it in when installing, which means it is missing it after the install (doesn't happen for boot ISO and dvd1 ISO) - NOTABUG (per @label) - @lumarel
Minimal ISO: if the server base environment is installed with the minimal iso and cockpit is enabled after the installation, the SELinux submenu shows an error \"semanage: command not found\" (doesn't happen with boot/dvd-iso) - also marked as expected - NOTABUG (per @label) - @lumarel
"},{"location":"guidelines/release_criteria/r8/8.6_qa_testing_summary/#manual-success-reported-in-mm","title":"Manual success reported in MM","text":"
minimal install from minimal ISO fine - PASS - @Luna Jernberg
workstation (x86_64) install with applications fine - retested in RC1_2 - PASS - @lumarel
all repos are available with the exact naming as they are in the rocky-repos package (nfv needs fix for that) - retested in RC1_2 - PASS - @lumarel
packer build for 8.6 worked flawlessly - retested by @neil in RC1_2 - PASS - @gmazrael
security profiles look good in anaconda UI - PASS - @atomicturtle (need openQA testing)
minimal and dvd recognized as Rocky Linux 8 in KVM - PASS - @atomicturtle
CIS profiles confirmed good in lvl1/2 in anaconda - PASS - @atomicturtle
DISA profiles confirmed good in anaconda - PASS - @atomicturtle
DVD: libvirt correctly boots when Rocky Linux 8 profile is selected - PASS - @atomicturtle
SELinux checks on Server (x86_64) (letting it run for an hour and run sealert -a /var/log/audit/audit.log) - everything okay - retested in RC1_2 - PASS - @lumarel
SELinux checks on Desktop (x86_64) (start the GNOME SETroubleshooter after some minutes of running) - everything okay - retested in RC1_2 - PASS - @lumarel
DVD: Anaconda manual network configuration, and PCI-DSS SCAP profile selected confirmed good - PASS - @atomicturtle
QA:Testcase_Mediacheck - PASS for all x86_64 ISOs - @tcooper
QA:Testcase_Mediacheck - PASS for all aarch64 ISOs - @tcooper
QA:Testcase Media Repoclosure - PASS for minimal & dvd1 for x86_64 & aarch64 (confirms RelEng results) - @tcooper
QA:Testcase Media File Conflicts - PASS for minimal for x86_64 & aarch64 (0 file conflicts found and 0 package conflicts found) - @tcooper
QA:Testcase Basic Graphics Mode - PASS - verified manually for Rocky-8.6-x86_64-dvd1.iso in VirtualBox on macOS X - @tcooper
DVD: Anaconda install with 3rd party repo, encrypted filesystem, HIPAA SCAP profile selected, confirmed good - PASS - @atomicturtle
Upgrade tests on several test machines from 8.5 to 8.6, no issues no SELinux alerts - PASS - @lumarel
All module streams except perl:5.32 and log4j:2 correctly have the dependencies set and packages look to be built correctly - PASS - @lumarel
log4j module stream was broken, (should be able to hook against java-8 and 11) - got fixed now in RC1_2 - PASS - @lumarel
Anything perl 5.32 (module stream) was broken - got fixed in RC1_2 - PASS - @nazunalika
Greenbone appliance installation test (https://rpa.st/DQNA) - PASS - @atomicturtle
QA:Testcase Debranding for RC2 content from koji (srpms, kernel-rt and pcs are not all on the dvd1) - 46/47 PASS , 1 FALSE PASS - https://rpa.st/raw/QK3A - @tcooper
QA:Testcase Media Consistency Verification (not written yet) for all RC2 ISOs x86_64, aarch64 - PASS - @tcooper
QA:Testcase Media File Conflicts - EXPECTED(per @label) for Rocky-8.6-x86_64-dvd1.iso (4 file conflicts found and 13 package conflicts found, these appear to be same as 8.5 conflict between mariadb and mysql packages/files, full results - https://rpa.st/raw/ZWPQ) - @tcooper
QA:Testcase Media File Conflicts - EXPECTED(per @label) for Rocky-8.6-aarch64-dvd1.iso (modular dependency problems, 3 file conflicts found 4 package conflicts found, full results - https://rpa.st/raw/KOFQ) - @tcooper
QA:Testcase Media File Conflicts for both x86_64 (https://rpa.st/raw/NLGA) and aarch64 (https://rpa.st/raw/4SFQ) are essentially unchanged and remain - EXPECTED(per @label) with RC1_2 ISOs. - @tcooper
OpenQA tests @lumarel - there are errors from the test cases, but everything image and repo related looks good - PASS - @lumarel
the dvd1 iso of aarch64 doesn't show an workstation base environment - it doesn't have an workstation environment - PASS - @lumarel
Installs of aarch64 systems of all 3 isos look good and installs with all base environments work as expected from these - PASS - @lumarel
Live Image Workstation and Workstation Lite looks good - PASS - @lumarel
QA:Testcase Boot Methods Boot Iso - PASS - @neil
QA:Testcase Boot Methods DVD - PASS - @neil
QA: Testcase boot/install minimal x86_64 over DVD/Bluray (burned with fedora mediawriter) on G752 ASUS laptop - PASS - @atomicturtle
Container images for x86_64 and aarch64 work as expected in Docker, Podman and WSL - PASS - @lumarel
QA: Testcase Update Image - PASS - @raktajino (manually checked against Fedora's testcase (https://fedoraproject.org/wiki/QA:Testcase_Anaconda_updates.img_via_URL), needles also still match in openQA)
Upgrade F35 -> F36 needs postgresql-setup --upgrade to convert openqa databse to new format - @alangm
Per discussion in Testing Team meeting we have 4-8 (ish) issues to fix in openQA (needles and code) to be able to complete all tests. @lumarel has created issues our openQA repo (https://github.com/rocky-linux/os-autoinst-distri-rocky) and we'll pick up and resolve ASAP.
"},{"location":"guidelines/release_criteria/r8/8.6_qa_testing_summary/#createhdds-kickstart-file-test-summary","title":"createhdds kickstart file test summary","text":"
Test method: Used packer to build VM. Booted VM. Verified root login. Shutdown VM.
UEFI Testing:
desktop.ks - PASS - Note: resulting image asks for EULA acceptance when booted due to firstboot --enable (unsure if that is desired behavior)
desktopencrypt.ks - PASS - Note: resulting image asks for EULA acceptance when booted due to firstboot --enable (unsure if that is desired behavior)
minimal-uefi.ks - PASS
server.ks - PASS
support.ks - PASS
BIOS Testing:
desktop.ks - PASS - Note: resulting image asks for EULA acceptance when booted due to firstboot --enable (unsure if that is desired behavior)
desktopencrypt.ks - PASS - Note: resulting image asks for EULA acceptance when booted due to firstboot --enable (unsure if that is desired behavior)
minimal.ks - PASS
server.ks - PASS
support.ks - PASS
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/","title":"Rocky Linux 8 Final Release Objectives","text":"
The objective of a release (major or minor) is to provide a solid Enterprise Linux release that is suitable to:
Meet the needs of end users
Meet the needs of enterprises big or small
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#rocky-linux-8-final-release-requirements","title":"Rocky Linux 8 Final Release Requirements","text":"
In order for Rocky Linux to be released to the general public, a compose must be able to meet all the following criteria as provided in this document. This is allows the decision process to be straightforward and as clear as possible. This document only contains \u201chard requirement\u201d items. Optional/nice to have items are not to be included in this list.
There may cases where a requirement cannot be met but only in particular configurations. In these types of cases, the Release Engineering Team should use their judgement to determine whether or not the issue should be considered to block the release. They should consider the number of users likely to be affected by said issue, the severity of the case, if the issue can be avoided with ease (by both informed and uninformed users), and if the problem exists upstream in the current Red Hat Enterprise Linux that the release is based on.
Release-blocking Server
...means bugs as it pertains to server functionality can be considered to block a release. This applies to any packages that provide a service such as httpd, nginx, etc. All architectures apply.
Release-blocking Desktop
...means bugs as it pertains to desktop functionality (GNOME) can be considered to block a release. This applies to both x86_64 and aarch64. Additional desktops (as provided by EPEL or a SIG) are not considered blockers.
Release-blocking Image
...means bugs as it pertains to the images built that can block a release. This applies to the DVD, minimal, and boot images on all architectures.
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#initialization-requirements","title":"Initialization Requirements","text":""},{"location":"guidelines/release_criteria/r8/8_release_criteria/#release-blocking-images-must-boot","title":"Release-blocking images must boot","text":"
Release-blocking installer images must boot when written to optical media or USB flash drive of appropriate sizes (if applicable) via officially supported methods. It is not the testing team\u2019s responsibility to test optical media, but they can and report back. If a bug is found, it is considered a blocker.
Optical Media Requirements
Release-blocking images must boot when written to optical media of an appropriate size. Current size requirements are: boot.iso = 789M, minimal.iso = 2.0G and dvd.iso = 10G.
Officially supported USB flash drive writing methods
The following methods of writing USB flash drives are officially support: dd The following methods of writing USB flash drives are not supported: rufus
The generic video driver option (\u201cbasic graphics mode\u201d) on all release-blocking installers must function as intended. This means launching the installer or desktop and attempting to use a generic driver. There must be no bugs that prevent the installer from being reached in this configuration on all systems and classes of hardware supported by the enterprise linux kernel.
Critical errors, such as undeclared conflicts, unresolved dependencies, or modules relying on packages from another stream will be considered an automatic blocker. There are potential exceptions to this (eg, freeradius cannot be installed on an older perl stream, this is a known issue upstream).
References
Test cases:
QA:Testcase Media Repoclosure
QA:Testcase Media File Conflicts
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#repositories-must-match-upstream","title":"Repositories Must Match Upstream","text":"
Repositories and the packages within them should match upstream as closely as possible. Notable exceptions would be kmods, kpatch, or what is deemed as \u201cspyware\u201d like insights. Packages that are available from upstream should not have hard requirements on RHSM and packages that have it default built in should be patched out.
This means that the installer\u2019s mechanism for verifying the install medium is intact and must complete successfully, with the assumption that the medium was correctly written. It should return a failure message if this not the case.
References
Test cases:
QA:Testcase Media USB dd
QA:Testcase Boot Methods Boot ISO
QA:Testcase Boot Methods DVD
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#packages-and-installer-sources","title":"Packages and Installer Sources","text":"
The installer must be able to use all supported local/remote packages and installer sources.
The installer must be able to create and install to any workable partition layout using any file system or format combination offered or supported by the installer. File systems that are not supported by the EL kernel is not tested here (this means btrfs, zfs, both of wish are not supported).
The installer must be able to detect and install to firmware RAID devices. Note that system-specific bugs do not count as blockers. It is likely that some hardware support might be broken or not available at all. DUDs (driver update disks) are not considered for this criteria.
References
Test cases:
QA:Testcase Firmware RAID
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#bootloader-disk-selection","title":"Bootloader Disk Selection","text":"
The installer must allow the user to choose which disk the bootloader will be installed to or, if the user so chooses, not to install a bootloader.
Any installer mechanism for resizing storage volumes must correctly attempt the requested operation. This means that if the installer offers a way to resize storage volumes, then it must use the correct resizing tool with the correct parameters. However, it does not require the installer to disallow resizing of unformatted or volumes with an unknown filesystem type.
The installer must be able to use an installer update image retrieved from removable media or a remote package source. This includes DUDs (driver update disks).
The installer must correctly display all complete translations that are available for use.
References
Test cases:
QA:Testcase Installer Translations
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#cloud-image-requirements","title":"Cloud Image Requirements","text":""},{"location":"guidelines/release_criteria/r8/8_release_criteria/#images-published-to-cloud-providers","title":"Images Published to Cloud Providers","text":"
Release-blocking cloud disk images must be published to appropriate cloud providers (such as Amazon) and they must successfully boot. This also applies to KVM based instances, such as x86 and aarch64 systems.
All system services present after installation must start properly, with the exception of services that require hardware which is not present. Examples of such services would be:
Computers using two monitors, the graphical output is correctly shown on both monitors.
References
Test cases:
QA:Testcase Multimonitor Setup
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#artwork-and-assets-server-and-desktop","title":"Artwork and Assets (Server and Desktop)","text":"
Proposed final artwork (such as wallpapers and other assets) must be included. A wallpaper from this package should show up as a default for GDM and GNOME.
References
Test cases:
QA:Testcase Artwork and Assets
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#packages-and-module-installation","title":"Packages and Module Installation","text":"
Packages (non-module) should be able to be installed without conflicts or dependent on repositories outside of Rocky Linux.
Default modules (as listed in dnf module list) should be installed without requiring them to be enabled.
Module streams should be able to be switched and those packages should be able to be installed without errors or unresolved dependencies.
References
Test cases:
QA:Testcase Basic Package installs
QA:Testcase Module Streams
"},{"location":"guidelines/release_criteria/r8/8_release_criteria/#identity-management-server-setup","title":"Identity Management Server Setup","text":"
It should be possible to setup a IdM server (FreeIPA), use it's functionality and connect clients.
References
Test cases
QA:Testcase Identity Management
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Release Requirements documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"guidelines/release_criteria/r9/9.0_qa_testing_go_no_go/","title":"Rocky Linux 9 QA and Testing : GO / NO GO Status","text":"
This document summarizes the GO / NO GO Status for Release of Rocky Linux 9.0 from perspective of the QA / Testing efforts. It is based largely on the Release Criteria (https://wiki.rockylinux.org/team/testing/release_criteria/) as was started as an import of that document. If there are differences between the official Release Critieria document and this document the official Release Criteria document will override and this document shall be updated.
As a reminder, the objective of a release (major or minor) is to provide a solid Enterprise Linux release that is suitable to: - Meet the needs of end users - Meet the needs of enterprises big or small
Artwork and Assets (Server and Desktop) - PASS - (@lumarel, semi-automatic, openQA)
Packages and Module Installation - PASS - (@lumarel, semi-automatic, openQA)
"},{"location":"guidelines/release_criteria/r9/9.0_qa_testing_summary/","title":"Rocky Linux 9 QA and Testing Summary","text":"
Last updated:"},{"location":"guidelines/release_criteria/r9/9.0_qa_testing_summary/#scope","title":"Scope","text":"
This document will record a summary of all QA and Testing results for Rocky Linux {{ no such element: dict object[9] }} release. It is only a record of success and/or failure. Solution discussion should take place elsewhere.
Please include PASS, FAIL, NOTABUG, INVESTIGATE or UPSTREAM as appropriate in all entries.
Please only provide brief summary. Details should go to Rocky Pastebin, links here is OK.
Please leave your MM @handle on all items you have done or are working on so we can talk to you to get resolution.
If the item you have reported is related to a QA:Testcase please mention it.
If you think the item you have reported should be a QA:Testcase, even if it's not a current requirement, suggest a title and create an issue in the wiki repository so we can add it.
This is a list of items that are being INVESTIGATEd further before being assigned a PASS, FAIL, NOTABUG or UPSTREAM status. PLEASE add your MM handle if you are working on this item to minimize duplication of work. More than one handle is allowed but please communicate.
This is a list of items that have been verified to be replicated UPSTREAM in RHEL {{ no such element: dict object[9] }} and/or are described clearly in the RHEL 9 Release Notes.
This is a list of items that have been verified to FAIL the QA:Testcase. In addition to recording who did the test please indicate if the item is BLOCKING release or not.
RC1 - The blue side banner background at the left side of the Anaconda installer display is not displaying correctly in virt-viewer. [minor BUG] - @alangm
RC1 - QA: Testcase Boot Methods Boot Iso - [PASS] - @alangm - minimal system, graphical server & basic workstation - nothing to report except as above ^^^
RC1 - Minimal install on QEMU/KVM passing - [PASS] - @boris - reboot takes slightly longer on the first reboot
RC1 - Repo Health Check - [PASS] - @lumarel - sqlite database files for repo metadata is missing up to now, which will hinder some applications from syncing the sources - are implemented
RC1 - Repo Health Check - [PASS] - @lumarel - metadata signing not implemented up to now - looks to be implemented as well now
RC1 - Repo Health Check - [PASS] - @lumarel - Repos look good now excl. BaseOS of aarch64, ppc64le, s390x, where the boot image is missing, which is referenced in the .treeinfo
RC1 - Redesign looks to be broken (Post-Install error, effects some of the install groups) - [PASS] - @lumarel
RC1 - Workstation install with known pesign bug - [PASS] - @alangm - error window \"Exit Installer\" button froze Anaconda instead of exit so had to initiate shutdown from cockpit - @lumarel - fixed!
RC1 - Building packages with mock - [PASS] - @hbjy - building works with the mock config from sokels' repo (will be upstreamed for release)
RC1 - Install apache + mariadb-server - [PASS] - @sspencerwire - mariadb-secure-installation works, nextcloud install on top as well
RC1 - Install works on macOS M1 - [PASS] - @netwaze, @gardo984, @jordan_c
RC1 - Install on baremetal went well - [PASS] - @alangm - on a Dell T630
RC1 - Install went well - [PASS] - @kars88 - there was some flickering during the install
RC1.1 dvd - STIG security - [PASS] - @atomicturtle - packages were not complete in RC1 dvd, but are now in RC1.1
RC1.1 - Basic installs work - [PASS] - @mkahric - Virtualbox on Windows (UEFI w/o SB), Workstation Player on Windows (UEFI w/ SB), Hyper-V (UEFI w/ SB)
RC1.1 - docker installation with ansible works - [PASS] - @gardo984
RC1 - Repo Health Check - [PASS] - @lumarel - all repos (x86_64, aarch64, ppc64le, s390x) look good now, all metadata is healthy and all package checksums match
RC1.1 - QA:Testcase Artwork and Assets - [PASS] - @lumarel - no issues found
RC1.1 - QA:Testcase GNOME UI Functionality - [PASS] - @lumarel - everything behaves as it should
RC1.1 - QA:Testcase SELinux Errors on Desktop - [PASS] - @lumarel - After an hour of usage no errors
RC1.1 - QA:Testcase Keyboard Layout - [PASS] - @lumarel - OpenQA tests and manual tests show normal behavior
RC1.1 - QA:Testcase SELinux Errors on Server - [PASS] - @lumarel - after more than an hour of runtime with several installs and application setups (missing, Katello bootstrap, which once brought some SELinux errors)
RC1.1 - QA:Testcase System Services - [PASS] - @lumarel - no errors
RC1.1 - QA: Testcase Installation Interfaces - [PASS] - @raktajino - failures on the Welcome Tour screen because we haven't handled it yet. Everything else seems good.
RC1.1 - QA:Testcase Installer Help - [PASS] - @raktajino - no errors
RC1.1 - QA: Testcase Disk Layouts - [PASS] - @raktajino - Assorted post-install failures due to either mismatch between console login and GUI login or unhandled Welcome Tour.
RC1.1 - QA: Testcase Kickstart Installation - [PASS] - @raktajino - Executed manually with virt-install. Nothing to report.
RC1.1 - QA: Testcase Update Image - [PASS] - @raktajino - failure on _console_wait_login as the GUI login screen is displayed. Update image is applied as expected.
QA:Testcase Basic install boot final ISO - [PASS] - @lumarel
QA:Testcase Basic install minimal final ISO - [PASS] - @lumarel
QA:Testcase Basic installs dvd final ISO - [PASS] - @lumarel - install of every base environment + custom operating system with all options enabled
OpenQA tests with final ISOs - [PASS] - @lumarel - boot-iso 2/2 | minimal-iso 2/2 | minimal 22/26 (failing are all false-positive) | server 21/26 (failing are all false-positive) | package-set 5/5 | workstation 17/26 (failing are all false-positive) | graphical-server 17/26 (failing are all false-positive) | universal 34/43 (failing are all false-positive)
QA:Testcase Module Streams - @lumarel - 9.0 currently does not have any Stream metadata and only the base Streams
Repo Health Check - @lumarel - yumrepofs is not sending content lengths, which make syncing with Katello impossible
Missing package in package group additional-devel - @stack - dnf -y group install additional-devel: No match for group package \"hmaccalc\" - this is an old EL bug
Hosting a nfs server in macOS, and using that in Virtualbox for OpenQA shares is a pain - @tcooper
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/","title":"Rocky Linux 9 Final Release Objectives","text":"
The objective of a release (major or minor) is to provide a solid Enterprise Linux release that is suitable to:
Meet the needs of end users
Meet the needs of enterprises big or small
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#rocky-linux-9-final-release-requirements","title":"Rocky Linux 9 Final Release Requirements","text":"
In order for Rocky Linux to be released to the general public, a compose must be able to meet all the following criteria as provided in this document. This is allows the decision process to be straightforward and as clear as possible. This document only contains \u201chard requirement\u201d items. Optional/nice to have items are not to be included in this list.
There may cases where a requirement cannot be met but only in particular configurations. In these types of cases, the Release Engineering Team should use their judgement to determine whether or not the issue should be considered to block the release. They should consider the number of users likely to be affected by said issue, the severity of the case, if the issue can be avoided with ease (by both informed and uninformed users), and if the problem exists upstream in the current Red Hat Enterprise Linux that the release is based on.
Release-blocking Server
...means bugs as it pertains to server functionality can be considered to block a release. This applies to any packages that provide a service such as httpd, nginx, etc. All architectures apply.
Release-blocking Desktop
...means bugs as it pertains to desktop functionality (GNOME) can be considered to block a release. This applies to both x86_64 and aarch64. Additional desktops (as provided by EPEL or a SIG) are not considered blockers.
Release-blocking Image
...means bugs as it pertains to the images built that can block a release. This applies to the DVD, minimal, and boot images on all architectures.
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#initialization-requirements","title":"Initialization Requirements","text":""},{"location":"guidelines/release_criteria/r9/9_release_criteria/#release-blocking-images-must-boot","title":"Release-blocking images must boot","text":"
Release-blocking installer images must boot when written to optical media or USB flash drive of appropriate sizes (if applicable) via officially supported methods. It is not the testing team\u2019s responsibility to test optical media, but they can and report back. If a bug is found, it is considered a blocker.
Optical Media Requirements
Release-blocking images must boot when written to optical media of an appropriate size. Current size requirements are: boot.iso = 789M, minimal.iso = 2.0G and dvd.iso = 10G.
Officially supported USB flash drive writing methods
The following methods of writing USB flash drives are officially support: dd The following methods of writing USB flash drives are not supported: rufus
The VNC installation option on all release-blocking installers must function as intended. This means launching the installer or desktop and connecting with VNC to complete the installation. There must be no bugs that prevent the installer from being reached in this configuration on all systems and classes of hardware supported by the enterprise linux kernel.
Critical errors, such as undeclared conflicts, unresolved dependencies, or modules relying on packages from another stream will be considered an automatic blocker. There are potential exceptions to this (eg, freeradius cannot be installed on an older perl stream, this is a known issue upstream).
References
Test cases:
QA:Testcase Media Repoclosure
QA:Testcase Media File Conflicts
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#repositories-must-match-upstream","title":"Repositories Must Match Upstream","text":"
Repositories and the packages within them should match upstream as closely as possible. Notable exceptions would be kmods, kpatch, or what is deemed as \u201cspyware\u201d like insights. Packages that are available from upstream should not have hard requirements on RHSM and packages that have it default built in should be patched out.
This means that the installer\u2019s mechanism for verifying the install medium is intact and must complete successfully, with the assumption that the medium was correctly written. It should return a failure message if this not the case.
References
Test cases:
QA:Testcase Media USB dd
QA:Testcase Boot Methods Boot ISO
QA:Testcase Boot Methods DVD
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#packages-and-installer-sources","title":"Packages and Installer Sources","text":"
The installer must be able to use all supported local/remote packages and installer sources.
The installer must be able to create and install to any workable partition layout using any file system or format combination offered or supported by the installer. File systems that are not supported by the EL kernel is not tested here (this means btrfs, zfs, both of wish are not supported).
The installer must be able to detect and install to firmware RAID devices. Note that system-specific bugs do not count as blockers. It is likely that some hardware support might be broken or not available at all. DUDs (driver update disks) are not considered for this criteria.
References
Test cases:
QA:Testcase Firmware RAID
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#bootloader-disk-selection","title":"Bootloader Disk Selection","text":"
The installer must allow the user to choose which disk the bootloader will be installed to or, if the user so chooses, not to install a bootloader.
Any installer mechanism for resizing storage volumes must correctly attempt the requested operation. This means that if the installer offers a way to resize storage volumes, then it must use the correct resizing tool with the correct parameters. However, it does not require the installer to disallow resizing of unformatted or volumes with an unknown filesystem type.
The installer must be able to use an installer update image retrieved from removable media or a remote package source. This includes DUDs (driver update disks).
The installer must correctly display all complete translations that are available for use.
References
Test cases:
QA:Testcase Installer Translations
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#cloud-image-requirements","title":"Cloud Image Requirements","text":""},{"location":"guidelines/release_criteria/r9/9_release_criteria/#images-published-to-cloud-providers","title":"Images Published to Cloud Providers","text":"
Release-blocking cloud disk images must be published to appropriate cloud providers (such as Amazon) and they must successfully boot. This also applies to KVM based instances, such as x86 and aarch64 systems.
All system services present after installation must start properly, with the exception of services that require hardware which is not present. Examples of such services would be:
Computers using two monitors, the graphical output is correctly shown on both monitors.
References
Test cases:
QA:Testcase Multimonitor Setup
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#artwork-and-assets-server-and-desktop","title":"Artwork and Assets (Server and Desktop)","text":"
Proposed final artwork (such as wallpapers and other assets) must be included. A wallpaper from this package should show up as a default for GDM and GNOME.
References
Test cases:
QA:Testcase Artwork and Assets
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#packages-and-module-installation","title":"Packages and Module Installation","text":"
Packages (non-module) should be able to be installed without conflicts or dependent on repositories outside of Rocky Linux.
Default modules (as listed in dnf module list) should be installed without requiring them to be enabled.
Module streams should be able to be switched and those packages should be able to be installed without errors or unresolved dependencies.
References
Test cases:
QA:Testcase Basic Package installs
QA:Testcase Module Streams
"},{"location":"guidelines/release_criteria/r9/9_release_criteria/#identity-management-server-setup","title":"Identity Management Server Setup","text":"
It should be possible to setup a IdM server (FreeIPA), use it's functionality and connect clients.
References
Test cases
QA:Testcase Identity Management
Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Release Requirements documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"include/contacts_top/","title":"Contacts top","text":""},{"location":"include/contacts_top/#contact-information","title":"Contact Information","text":"Owner Testing Team Email Contact testing@rockylinux.org Mattermost Contacts @stack, @tcooper Mattermost Channels ~Testing"},{"location":"include/content_bottom/","title":"Content bottom","text":"Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"include/members_full/","title":"Members full","text":"Role Name Email Mattermost Name IRC Name Testing Lead Chris Stackpole stack@rockylinux.org @stack Testing Team Al Bowles @raktajino raktajino Testing Team Trevor Cooper tcooper@rockylinux.org @tcooper Testing Team Lukas Magauer lukas@magauer.eu @lumarel Testing Team Alan Marshall @alangm alangm Testing Team Rich Alloway @ralloway Testing Team Anthony Navarro @anavarro10"},{"location":"include/members_no_role/","title":"Members no role","text":"
| Name | Email | Mattermost Name | IRC Name |\n| --------------- | ----------------------- | ------------------ | --------- |\n| Chris Stackpole | stack@rockylinux.org | @stack | |\n| Al Bowles | | @raktajino | raktajino |\n| Trevor Cooper | tcooper@rockylinux.org | @tcooper | |\n| Lukas Magauer | lukas@magauer.eu | @lumarel | |\n| Alan Marshall | | @alangm | alangm |\n| Rich Alloway | | @ralloway | |\n| Anthony Navarro | | @anavarro10 | |\n
"},{"location":"include/qa_content_example_only/","title":"Qa content example only","text":"
CONTENT EXAMPLE ONLY
Content on this page may be copy-pasta from Fedora Quality Assurance documents and needs to be replaced and/or reviewed before publishing for applicability for Rocky Linux.
"},{"location":"include/qa_data_loss_warning/","title":"Qa data loss warning","text":"
DATA LOSS
Depending on installer choices this MAY destroy all the data on the test system. If you choose to complete the installation of the test system any/all data on the system may be lost. Please do not install on a system whose contents you need to keep.
"},{"location":"include/qa_setup_boot_to_media/","title":"Qa setup boot to media","text":"
Obtain access to supported system and hardware class to be installed.
Prepare appropriate media for the selected ISO to be tested.
Example: QA:Testcase Media USB dd
Boot the system from the prepared optical, USB media or virtual device attachment.
Examples: QA:Testcase Boot Methods Boot ISO, QA:Testcase Boot Methods DVD
In the boot menu select the appropriate option to boot the installer.
"},{"location":"include/qa_testcase_bottom/","title":"Qa testcase bottom","text":"Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Quality Assurance documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"include/qa_testcase_supported_systems/","title":"Qa testcase supported systems","text":"Supported Systems and Hardware Classes x86_64aarch64ppc64s309x
TBD
TBD
TBD
TBD
"},{"location":"include/rc_content_bottom/","title":"Rc content bottom","text":"Additional Information ContactDisclaimerAttributionLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at testing@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This work is heavily inspired by the Fedora Release Requirements documents which were made available under Attribution-Share Alike 4.0 International license unless otherwise noted.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"include/rc_content_example_only/","title":"Rc content example only","text":"
CONTENT EXAMPLE ONLY
Content on this page may be copied from Fedora Release Requirements documentation and needs to be replaced and/or reviewed before publishing for applicability for Rocky Linux.
This section goes over the various SOP's for the Testing Team. Please use the menu items to find the various pages of interest.
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This SOP covers how the Rocky Linux Testing Team handles requests for Operator access to the openQA system.
"},{"location":"sop/openqa_sop_operator_access/#contact-information","title":"Contact Information","text":"Owner Testing Team Email Contact testing@rockylinux.org Mattermost Contacts @stack, @tcooper Mattermost Channels ~Testing"},{"location":"sop/openqa_sop_operator_access/#responding-to-an-openqa-operator-access-request","title":"Responding to an openQA Operator Access Request","text":"
TODO
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
This SOP covers how the Rocky Linux Testing Team handles requests for Operator access removal on the openQA system.
"},{"location":"sop/openqa_sop_operator_removal/#contact-information","title":"Contact Information","text":"Owner Testing Team Email Contact testing@rockylinux.org Mattermost Contacts @stack, @tcooper Mattermost Channels ~Testing"},{"location":"sop/openqa_sop_operator_removal/#responding-to-an-openqa-operator-access-removal","title":"Responding to an openQA Operator Access Removal","text":"
TODO
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
"},{"location":"sop/openqa_sop_system_upgrades/","title":"SOP: openQA - System Upgrades","text":"
This SOP details the necessary steps for performing a system upgrade on an openQA host.
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.
To identify which packages may need updates, visit the appropriate RepoCompare page, focusing on the SRPM Repo Comparison page for each version. Packages where the Rocky version is lower than the RHEL version likely require an update - you can do a manual comparison to be sure.
"},{"location":"sop/sop_repocompare/#comparing-a-package","title":"Comparing a package","text":"
If the Name/Epoch/Version/Release (NEVR) for the RHEL package is newer than the one for the Rocky package, the package requires an update. In this situation, there will also likely be a newer entry in the changelog for the RHEL package, as shown below:
./manual_compare.sh 9 AppStream golang\nRocky Linux 9.2 golang 1.19.9 2.el9_2 * Tue May 23 2023 Alejandro S\u00e1ez <asm@redhat.com> - 1.19.9-2\nRed Hat golang 1.19.10 1.el9_2 * Tue Jun 06 2023 David Benoit <dbenoit@redhat.com> - 1.19.10-1\n
Notice that the Red Hat golang package has a higher version than the Rocky Linux 9.2 package. It also has a newer entry in its changelog.
Some packages are not considered relevant for repocompare purposes. These include:
rhc\nshim-unsigned\n# Any package that exists in RHEL but not in Rocky (denoted by **DOES NOT EXIST** in the Rocky column on the repocompare website)\n
Additional Information ContactDisclaimerLicense
If you have questions with respect to this content or to report concerns regarding the use or misuse content please do not hesitate to contact us at info@rockylinux.org.
Rocky Linux and the Rocky Enterprise Software Foundation (RESF) does not make any express or implied warranties, including but not limited to the warranties of non-infringement of any third party intellectual property rights. RESF does not warrant that any pending trademark applications for trademarks of RESF will result in any granted trademark protection. RESF shall not be liable for any claims relating to user's activities falling within the scope of the permission and user hereby agrees to indemnify, defend and hold RESF and its contributors harmless against any such claim.
This content is licensed under under Attribution-Share Alike 4.0 International license unless otherwise noted.