Home Home > 2013 > 10 > 22 > Help test the openSUSE Release Candidates!
Sign up | Login

Help test the openSUSE Release Candidates!

October 22nd, 2013 by

RC1 is here_black
openSUSE made its first release candidate for 13.1 available less than two weeks ago. And with it, we issued a call for testing. If you’re interested in helping out but would appreciate a few pointers on how to do so, read on!

What do we need

openSUSE uses automated testing which ensures the basic suitability and stability of our distribution images. We also have a large number of users using Factory, our development version, finding issues when they arise. But with about 6000 packages available, not every combination and usecase can be tested. What needs some extra help? We’ve laid out a few areas where your testing would be very valuable.

Real hardware installations

The automated testing has limitations: it only works in a virtualized environment, precluding testing of hardware and technologies like UEFI/Secure boot. And our Factory users have a limited amount of hardware available and they’re usually only updating, not doing new installations.

So it is extremely valuable if you grab an old (or new!) laptop or desktop and do a full installation on it instead of using a virtual machine.

Upgrading and installation

We’re also looking for help testing updates from 12.3 to 13.1 with both zypper dup and from the GUI in YaST; and for new installations extra testing would be worthwhile to be done with dual boot.


Anything YaST related is in need of testing as we did port it to ruby! There have also been related changes like in the area of networking. For example, systemd now takes care of labeling ethernet devices instead of udev. So we would love to see you test the network, firewall, NAT and other networking functionality in YaST.


We’ve been giving extra attention to btrfs and this next generation filesystem is still a target for testing, even though it is not the default in openSUSE 13.1.

By default, only the ‘safe’ features of btrfs are enabled, including the snapshot and metadata and data integrity feature. These both offer protection against data loss. The snapshots do this by making it easy to revert files to earlier states, even bringing back removed files where needed! The (meta)data integrity feature uses error checking codes on your data to ensure your spinning rust or deep fried sand gives you back the data you stored on it the way you intended.

However, who installs btrfs now will be able to instantly benefit from the many features under development as soon as they are marked stable. Some of these include transparent compression of data, de-duplication of files and data, multi-volume drives and hot add/remove of drives part of it and various performance improvements. These features are there, but are disabled by default. However, you can already test them by adding the ‘allow_unsupported=1’ option to the btrfs module either on the kernel command line or in /etc/modprobe.d.

Other specific technologies to test

On the page we’re gathering what’s new in openSUSE 13.1 you can see the major changes – which of course can use some testing. For example, we would love to see some extra attention given to the following:


  • Network connectivity: WiFi and bluetooth on the desktops (note that due to an update to Bluez 5, bluetooth doesn’t work very well in Plasma Desktop, an update is coming)
  • Libreoffice
  • printing
  • performance regression tests
  • btrfs of course

Testing and Reporting

See the testing wiki for some info on testing. Testing is a matter of trying out some scenario’s you decided to test, for example, pairing your Android phone to your computer with Bluetooth. If it works – awesome, move on. If it doesn’t, you have to find out as much as you can about the why and use that for a bug report.

You then file the bug in bugzilla. If you have strong doubts about it being a bug or if you think it is extremely serious, you can report it on the openSUSE-factory mailing list. Even if you contact the list you should file a bug first, issues tend to get lost on the mailing list. Also, be sure to make good use of the openSUSE Testing documentation at the Testing portal, the Bug report how-to and read the Bug Reporting F.A.Q!

Triaging Bugs

Another useful contribution is triaging bugs, which has the following goal:


      a) find if it is really a bug (can be reproduced)


      b) find in which component is the bug and


    c) assign or cc the maintainer of that component

If you can’t reproduce a bug, the bug might have to be marked as “WORKSFORME” or “NEEDINFO” if you can’t reproduce it due to a lack of information. And in some cases, the bug report is plain wrong (“Firefox doesn’t make coffee“) and must be closed as “INVALID”. You can find more information in the bugreporting FAQ. As long as you have no rights yet to close bugs on bugzilla, you can just add your information as comments and they will be picked up by a maintainer – it is no less useful!

Bernhard, the author of openQA, has developed a nice web interface for easy bug browsing. The web interface provides a list of some random bugs. If you are interested in a specific component, then you can use the search bar and look for them. For triaging, it makes most sense to use this query, which shows bugs added in the last month, still open, and filtered on the ‘screening’ term. Once you have a random list of bugs that may interest you, go in and try to test and add information to the bug. While the real fixing is still left for the developers to do, the triaging makes it easier for them to do so and saves them time.

Thanks a lot!

Finding time for testing makes a big difference. It helps ensure openSUSE 13.1 will be a great, stable, usable release ready for installation on almost half a million machines!

Both comments and pings are currently closed.

12 Responses to “Help test the openSUSE Release Candidates!”

  1. I gave up using VM’s a couple of releases back.
    I’ll happily contribute

  2. Pierre

    I am really looking forward to this release.
    openSUSE is my companion again since version 12.1 and runs on all of my machines. Well, except my webserver, which is running Debian Stable/Wheezy, but I guess you can forgive me this. ;-)
    Hopefully this one will run as stable as the previous releases since 12.1 and as soon as I have the time I will grab the RC1 iso and install it on my laptop at least.

    And keep up the good work.

  3. Javier Arias

    The shift from version 12.3 to 13.1 is quite traumatic, Tumbleweed repository fails to change the system packages, patches fail to be applied successfully, I can not find out why, but I think it is related to the mkinitrd command

  4. Scott Wilson

    Ok I have a Dell XPS 630i. what do I need to do?

    • Install or upgrade your openSUSE to 13.1; see how that works. Then check wireless, libreoffice, printing and samba networking if you can. If they all work well – awesome, we did great. If there are issues, please see the links for filing bugs!


  5. Jordi Relats

    I have install Opensuse13.1 rc2 in a lenovo yoga.

    I had to disable secure boot, was not working for me I tried during installation and I have enabled later no way to start the computer

    I have a SSD hard drive, I have not found the way to use the file system F2FS.

    Probably I have done something wrong but I don’t know what.

    • F2FS is not available in YaST as it is too experimental. You can use the command line tools to format a drive in F2FS and then use it. Install f2fs-tools and use mkfs.f2fs to test it out.

  6. Rafael

    I launch 13.1 RC2 from USB but when it reaches KDE desktop, it said user home drive is out of space. So I can only move the mouse but anything more. The USB stick was of 1Gb capacity, but I’m sure that was not the problem.

    My desktop computer was running a installed version of OpenSUSE 12.3 without problems.

    Any idea ?

  7. Maxim

    I have installed 13.1 on Lenovo Ideapad Y560. When I try to use projector I see black workplace. When I try to configure screen, system crashes, I see login screen.