Hey Fabrizio

Hi Sumantro, thanks for your interest

We do have how to test kernel in http://fedoraproject.org/wiki/QA:Testcase_kernel_regression and a blog https://fedoramagazine.org/running-fedora-kernel-regression-tests/

Yes, i'm using exactly these links to write a draft and summarize all the steps for new people willing to partecipate in a test day. The goal is to have a place where newcomers can quickly learn how to contribute successfully during a testing day. Will providing a link to the guide in future posts announcing the test day eventually decrese comments of people asking how to test, and will increase the number and types of machines we receive feedback from?

Quick Docs are mostly for all generic use cases a user would like to use Fedora for like booting and installing Fedora and writing image on a SD card and so on and so forth.

The idea you have is very good and I would like to work with you closely to set up a Fedora QA docs repo and then you can start writing some docs there. Note that Test Days are events which take place in every release cycle and writing blogs about them make more sense than writing docs. Hence most of these test cases are written in Wiki and the QA team uses Fedora Wiki TCMS to maintain its test cases. However, if you want to write test cases for "how to test" starting with writing test cases will be a better place to start.

Let me know what you think?

I'm still unsure where will fits best, if in a wiki page, in a quick-doc page, or in QA docs, but I'm pasting here below my initial draft for the "kernel test how to", let me know what you think too ;)

How to participate in Kernel Test Days:

You can download a ‘test day image’ which is a live distro of Fedora with the new kernel to test already in it. The test day image also contain the test suite, aka the scripts to test the kernel on your machine. The downloaded .iso file must then be written in a bootable USB stick. see https://docs.fedoraproject.org/en-US/quick-docs/creating-and-using-a-live-in...

You can also install the new kernel on a Virtual Machine running an up to date Fedora release and do the test in the VM. In this case you can just add this Copr repo on the fedora distro running in your VM: https://copr.fedorainfracloud.org/coprs/jforbes/kernel-stabilization/ once you added the repo, you can do: sudo dnf upgrade && sudo dnf install kernel-5.0.0-200.fc29.x86_64 (in this example we install kernel-5.0.0-200 on fedora 29 with 64 bit arch) and this will install the kernel to test. Reboot and you are ready to test.

(Is also possible to find kernels directly from koji builds….koji is recommended for secure boot users) #to improve

You could also install and test the new kernel on your Workstation/Server installation, on a bare metal machine, but make sure you have no important data on that installation, things might go wrong -- don't do this on your production machine!

Lets start testing! (and possibly earn a new badge)

To run the tests, you need the gcc, git, and python-fedora packages installed.

sudo dnf install gcc git python-fedora

If you are using the ‘test day image’ you will have the kernel-tests folder in your home folder. so you can enter the folder with cd ~/kernel-tests

If you are not using the test day image you will need to clone the kernel-tests repo. issue this command in terminal: git clone https://pagure.io/kernel-tests.git

this will download the same folder that you find in the test day image, with the testing scripts. cd kernel-tests

Once inside the kernel-tests folder , it’s time to write some configurations, first we need to copy the content of the config.example file to a new hidden file named .config

cp config.example .config

Now edit the .config file with your favorite editor

Here we can decide whether or not to upload the results of our tests to Fedora servers. By default, tests do not submit results to the server. They will just run and write results on a log file in /kernel-tests/logs/ To submit results anonymously, edit the .config file with submit=anonymous. To submit results linked to your FAS username, set submit=authenticated and username=<your FAS login> in .config. If you link your submission to your FAS username, you’ll also receive a Fedora badge!

The results of your test will be uploaded here: https://apps.fedoraproject.org/kerneltest/

Running the tests:

(Before running the test, be sure your machine has no workload already, like other cpu intensive processes)

To run the basic set of tests, use this command: $ sudo ./runtests.sh

To run the performance test suites, use this command: $ sudo ./runtests.sh -t performance

The expected result is that the tests pass. However, some tests may fail occasionally due to system load. Anyway add whatever results you got from the tests on the dedicated result page of the Kernel Test day!

If a test fails repeatedly, though, consider helping by reporting the failure on Bugzilla.

Other raccomendations: Some of the tests requires additional package to be installed. Install keyutils package to run the modsign test. #or we just ask to install this packages to everybody? I’ll recommend also dnf install libtirpc-devel, this to avoid the issue with rpc.h in compiling, that could still happen if someone upgraded from older releases. https://pagure.io/kernel-tests/pull-request/18

Update. In the meanwhile the nice post about quick-docs from @ankursinha on the communityblog inspired me (he said : you write new documents about topics that interest you. It could be anything, anything at all, that you think is worth documenting. Quite a few of us document various tools and techniques on our blogs—why not put these up on quick-docs if the are general enough to be of interest to a wider audience?) and i was also very curious about the new process of writing docs using antora and asciidoc, so i wrote a draft for the ‘kernel-test guide’ and the PR is here for you to review https://pagure.io/fedora-docs/quick-docs/pull-request/128

I’d like to add some images in the future but for now let me know any suggestion about this guide; if can be published as quick-doc or has to be moved in a new QA doc repo or to a wiki page. Especially @sumantro let me know if i forgot something and feel free to contact me for any technical details to add, modify or improve.

Thanks.