We know you have missed the usual summary from the YaST trenches. But don’t panic, here you got it! As usual, we will only cover some highlights, saving you from the gory details of the not so exciting regular bugfixing.

Package notifications

libzypp has a nice feature that enables packages to display notifications when they’re installed/upgraded. Zypper takes advantages of this feature and shows that information when a package is installed/upgraded. For example, if you install mariadb package, Zypper will inform you about setting up a database root password and so on.

If you installed any of those packages with YaST, you missed that piece of information… until now! Starting on yast2 3.1.175 YaST will show packages notifications.

The only exception is when doing a regular installation (or autoinstallation), as we want to show as few dialogs as possible.

Registration Codes from a USB Stick

During the installation of a SUSE Linux Enterprise product, you are asked for a registration code. Previously you had to remember it and type it by hand. Now the code can be read from USB storage.

Insert a USB stick at installation boot time or at the latest before you proceed from the first installation screen (Language, Keyboard and License Agreement). That stick should contain the registration codes either at /regcodes.txt or at /regcodes.xml. In the registration dialogs, the input fields will be prefilled.

The syntax of the files is as follows. In the file identify the product with the name quoted by zypper search --type product or SUSEConnect --list-extensions (without the /version/architecture part).

regcodes.txt:

SLES    cc36aae1
SLED    309105d4

sle-we  5eedd26a
sle-live-patching 8c541494

regcodes.xml: (xml wins if both xml and txt are present)

<?xml version="1.0"?>
<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
  <suse_register>
    <!-- See https://www.suse.com/documentation/sles-12/singlehtml/book_autoyast/book_autoyast.html#CreateProfile.Register.Extension -->
    <addons config:type="list">
      <addon>
        <!-- Name of add-on as listed by "zypper search --type product" -->
        <name>sle-we</name>
        <reg_code>5eedd26a</reg_code>
      </addon>
      <addon>
        <name>sle-live-patching</name>
        <reg_code>8c541494</reg_code>
      </addon>
      <addon>
        <!-- SLES is not an add-on but listing it here allows for combining
             several base product registration codes in a single file -->
        <name>SLES</name>
        <reg_code>cc36aae1</reg_code>
      </addon>
      <addon>
        <name>SLED</name>
        <reg_code>309105d4</reg_code>
      </addon>
    </addons>
  </suse_register>
</profile>

Lot of Btrfs-related improvements in the expert partitioner

We also invested quite some time improving the support for Btrfs in the expert partitioner. Implementing one requested feature and closing five bugs.

The following animation shows the feature #320296 (user friendly handling of subvolumes) in action, together with the fix to 965279 (Btrfs settings always overridden with default values).

But we have even more screenshots and animations for the improvements in the expert partitioner. In the description of this pull request, you have screenshots displaying the new dialog that was implemented to fix bug#928641. And in this other pull request, you can see in action the fixes for bug#944252 (snapshots were offered for partitions other than root) and for bug#954691 (fstab options being forgotten for Btrfs partitions).

Improving testability of the new storage code

In recent posts, we reported how we are about to refactor the storage subsystem of YaST. The improved partition proposal for installation presented in the previous summary performs a lot of operations – like analyzing what disks are there and what is on each one of them, checking if there already is enough free space and making a best guess on what partitions may be candidates to be removed to make space for a new Linux installation.

If there are many disks with many partitions, this can get complicated really quickly. So we need a reliable way to test it. Thus, we created a testing framework to build fake storage hardware (disks) with fake partitions and file systems. Although it’s fake hardware (we can’t create hard disks out of thin air… yet), it enables us to do unit tests without setting up virtual machines. With those tests we can cover a lot more scenarios that would otherwise be really difficult to test, with one or many disks, with many partitions of different kinds, with a previously existing RAID array or whatever.

One nice thing about the new libstorage is that it operates on “device graphs” that can be transformed into the GraphViz format for easy visualization. Here you have a nice diagram generated by libstorage based on some fake hardware created from this YAML specification.

Better handling of wrong registration code for extensions

We also spent some time improving the usability of the section for registration of extensions and modules. Now if the user selects several modules and the registration of some of them fails, the user will be kindly redirected back to the same dialog but only with inputs for the unregistered ones. From there, they can go back to unselect the failing extensions or retry with different (or even with the same) codes.

Say goodbye to the “receive system mail” checkbox

As the last step of the improvements done to the user creation dialog (see the previous post for more details). We removed the long-ago meaningless checkbox titled “Receive System Mail”. That leaded to the removal of quite some code… and removing code is usually a good thing. 🙂

Many other things

As usual, this is just a short summary with some highlights. Many other stuff was implemented and several other bugs were fixed but, you know, we cannot blog about everything if we want to invest some time in debugging and coding. 🙂

See you in the highlights for next sprint, in around three weeks.

PS.- If you want to be part of the fun, take a look to the YaST-related summer projects we have on the openSUSE mentoring page.

Another three weeks period and another report from the YaST Team (if you don’t know what we are talking about, see highlights of sprint 13 and the presentation post). This was actually a very productive sprint although, as usual, not all changes have such an obvious impact on final users, at least in the short term.

Redesign and refactoring of the user creation dialog

One of the most visible changes, at least during the installation process, is the revamped dialog for creating local users. There is a full screenshots-packed description of the original problems (at usability and code levels) and the implemented solution in the description of this pull request at Github.com.

Spoilers: the new dialog looks like the screenshot below and the openSUSE community now needs to decide the default behavior we want for Tumbleweed regarding password encryption methods. To take part in that discussion, read the mentioned description and reply to this thread in the openSUSE Factory mailing list.

Beyond the obvious changes for the final user, the implementation of the new dialogs resulted in a much cleaner and more tested code base, including a new reusable class to greatly streamline the development of new installation dialogs in the future.

One step further in the new libstorage: installation proposal

In the highlights of the previous sprint, we already explained the YaST team is putting a lot of effort in rewriting the layer that access to disks, partitions, volumes and all that. One important milestone in such rewrite is the ability to examine a hard disk with a complex partitioning schema (including MS Windows partitions, a Linux installation and so on) and propose the operations that need to be performed in order to install (open)SUSE. It’s a more complex topic that it could look at the first glance.

During this sprint we created a command line tool that can perform that task. Is still not part of the installation process and will take quite some time until it gets there, but it’s already a nice showcase of the capabilities of the new library.

Fixed a crash when EULA download fails

If a download error occurred during the installation of any module or extension requiring an EULA, YaST simply exited after displaying a pop-up error, as you can see here.

Now the workflow goes back to the extension selection, to retry or to deselect the problematic extension. Just like this.

Continuous integration for Snapper and (the current) libstorage

Snapper and libstorage now build the Git “master” branch continuously on ci.opensuse.org (S, L), and commit a passing build to the OBS development project (S, L), and if the version number has changed, submit the package to Factory (S, L).

The same set-up works on ci.suse.de (S, L), committing to the SUSE’s internal OBS instance (S, L) and submitting to the future SLE12-SP2 (S, L).

This brings these two packages up to the level of automation that the YaST team uses for the yast2-* packages, and allows releasing simple fixes even by team members who do not work on these packages regularly.

Disk usage stats in installation and software manager: do not list subvolumes

While installing software, YaST provides a visual overview of the free space in the different mount points of the system. With Btrfs and its subvolumes feature, the separation between a physical disk and its mount point is not that clear anymore. That resulted in wrong reports in YaST, like the one displayed in the left bottom corner of this screen.

The actual calculation of free space is performed by libzypp (the Zypper library), YaST only takes care of rendering the result of that calculation in the screen. Thus, we closely collaborated with the Zypper developer, Michael Andres, to teach libzypp how to deal with Btrfs subvolumes. Thanks to his work, with any version of libzypp >= 15.21 (already available in Tumbleweed), you can enjoy an error-free disk usage report.

To ensure we have no regressions, the YaST team also contributed a new test to openQA. See it in action.

Cleanup dependencies in YaST systemd services

We have received several bug reports about problems executing AutoYaST or YasT2-Firstboot in combination with complex network settings or third party services… and even in some simple scenarios. Many of these problems boil down to a single culprit – the dependencies of the YaST related systemd units.

During this sprint we have simplified the unit files for Tumbleweed and SLE, as you can see in this pull request. It’s a small change but with a huge impact and several implications, so a lot of time was invested into testing during the sprint. The problems seem to be gone, but more AutoYaST and YaST-Firstboot testing would be highly appreciated.

Many other things

As usual, this is only a brief collection of highlights of all the job done during the sprint. Using Scrum terminology, this represents only 27 story points out of a total of 81 story points delivered by the team during this sprint. Using more mundane words, this is just a third part of what we have achieved during the last three weeks.

Hopefully, enough to keep you entertained until the next report in other three weeks!