|Fedora Test Days|
|Anaconda and Dnf|
What to test?
Today's instalment of Fedora Test Day will focus on DNF use in Anaconda, the Fedora installer. DNF is the package manager intended to replace yum as the default for Fedora soon: part of the goal of this test day is to decide if it is in good enough shape to replace yum for Anaconda for Fedora 22.
The following cast of characters will be available testing, workarounds, bug fixes, and general discussion:
- Development - Brian Lane (bcl), David Cantrell (dcantrell)
- Quality Assurance - Adam Williamson (adamw), Mike Ruckman (roshi)
Prerequisite for Test Day
- An image to test
- Test system / drive or virtual machine (for this test day, you need something you can lose all the data from, non-destructive testing is not possible)
- (Optional) a server for hosting kickstarts
How to test?
Please test with one of these images (the 2015-02-10 nightly builds):
For all testing described below, please note that there are some issues that are already known - no need to spend time reproducing these problems and filing new reports.
- No proxy support. Proxies just won't be used
- kickstart repos additionally do not implement
- All of that, except proxy URL and cost, is also missing in the .repo files written with anaconda
%packages --multilibis not implemented
- Language support selection is not saved in the dnf-langpacks configuration
- Excluding packages in a kickstart does not work
- In the GUI, the default package set is Cloud Server - this is caused by RHBZ #1177002
Download one of the nightly images to be used for testing, and run through one or more of the test cases listed on the results page. Report any bugs you encounter, and enter your results on the results page.
You can also do free form testing to exercise the package-related functions of the installer as much as possible: try different things in the INSTALLATION SOURCE and SOFTWARE SELECTION screens, and exercise the kickstart directives relating to repositories and package sets. Please add results to the table below. Here are some ideas for exploratory testing from the installer developers:
- Try all environments (left-hand side choices) in SOFTWARE SELECTION, with add-ons (right-hand side choices) left default: note dependency issues may be bugs in packages, not in anaconda or DNF, check the Rawhide Report emails to see
- Try Basic Desktop, Minimal Install or KDE Plasma Workspaces environment and select all add-ons
- Test installation with the
/root/anaconda-ks.cfgfile generated by any interactive install (e.g. those above), ensure it works and reproduces the same install options
- Test various options for : , , , ,
- Test various options for definitions: ,
- Test various special entries in
- - all packages
- - exclude group
- - wildcard package match
- - exclude wildcard package match
- - exclude kernel (should work, with kernel-core)
- - exclude kernels (???)
It would be very valuable to the installer team for testers to help produce more kickstarts which can be used for automated testing. This is really just a regular kickstart with some shell script commands in
/root/RESULT. For a successful run, the file should contain only the text . For a failed run, the file should contain a short error message.
Here is an example automatable kickstart, which sets some package groups and environment groups to be installed and checks that they are:
url --mirrorlist=https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch install network --bootproto=dhcp bootloader --timeout=1 zerombr clearpart --all autopart keyboard us lang en timezone America/New_York rootpw qweqwe shutdown %packages @core @c-development @^web-server-environment %end %post # We don't have a way of determining if a group/env is installed or not. # These sentinel packages will have to do. rpm -q httpd if [[ $? != 0 ]]; then echo '*** web-server-environment was not installed' > /root/RESULT else rpm -q gcc if [[ $? != 0 ]]; then echo '*** c-development was not installed' > /root/RESULT else echo SUCCESS > /root/RESULT fi fi %end
Exploratory / kickstart testing results
You can add test kickstarts and bugs you encounter in exploratory testing to the table below, following the example format. Please include all details and comments about the bug in the bug report and just include your name and the lists of bugs and kickstarts in the table. It's fine to only include bugs (if you only do interactive testing) or only kickstarts (if you tested kickstarts and didn't find any bugs). If you do not have access to a site or service to upload your kickstarts to, you can upload them to this Wiki.
|Example||RHBZ #123456 RHBZ #654321||groups.ks|
If you have problems with any of the tests, report a bug to Bugzilla for the appropriate component. Likely choices are:
If you are unsure about which component to report a bug against, exactly how to file the report, or what other information to include, just ask on IRC and we will help you.
Please enter results for the planned testing on the results page. The results will be transferred here some time after the Test Day concludes for the record.