Home Home
Sign up | Login

Highlights of YaST Development Sprint 44

October 11th, 2017 by

Here is the YaST team again with a new report from the trenches, this time with a small delay over the usual two weeks. Most of the team keeps focused on the development of the upcoming SUSE Linux Enterprise 15 products family, including openSUSE Leap 15. That means finishing and polishing the new storage stack, implementing the new rich ecosystem of products, modules, extensions and roles (one of the biggest highlights of the SLE15 family) and much more. So let’s dive into the most interesting bits coming out of the sprint.

Hostname configuration during installation

And let’s start with one of those stories that illustrate the complexity hidden below the user-oriented YaST surface. During installation is very common to assign a hostname to the machine being installed to identify it clearly and unequivocally in the future.

Usually it is a fixed hostname (stored in /etc/hostname) but in some circumstances is preferable to set it dynamically by DHCP. Since some time ago (as you read in a previous report and is shown in the image below) YaST allows to set the hostname selecting a concrete interface or with a system-wide variable named DHCLIENT_SET_HOSTNAME which is defined in /etc/sysconfig/network/dhcp. The value to be set for such variable during installation can be optionally read from the distribution control file. Last but not least, as you already know, Linuxrc can also be used to enforce a particular network configuration.

YaST DHCP configuration with several network interfaces

Most users have a simple setup that works flawlessly, but we recently got a bug report about a wrong network configuration after installing the system if the hostname configuration was set via Linuxrc. After some research we found that the value of DHCLIENT_SET_HOSTNAME coming from the control file was overwriting the Linuxrc configuration at the end of the installation. Now it’s fixed and the global variable will be set by the linuxrc sethostname option if provided or loaded from the control file if not. And all that happens now at the very beginning of the installation to give the user to chance to modify it and to ensure the user’s choice is respected at the end.

Setting hostname in Linuxrc

Take into account that with multiple DHCP interfaces the resulting value for DHCLIENT_SET_HOSTNAME is not fully predictable. Hence, in that scenario we recommend to explicitly select the interface which is expected/allowed to modify the hostname.

Extending the installation process via RPM packages

As we have mentioned (a couple of times) during latest reports, we are implementing multi-product support for the installer. It means that SUSE will ship several products on a single installation media.

One interesting feature is that products, modules and extensions can define its own installation roles. For instance, if you select the desktop extension, you will be able to select GNOME as system role.

During this sprint, we have improved roles definitions handling, displaying a different list of roles depending on which product was selected.

As a side effect, we added support for sorting roles assigning them a display order.

Getting Release Notes from the Installation Repository

As part of our effort to drop SUSE tags from the installation media, we improved the way in which release notes are handled during installation.

Release notes are downloaded from openSUSE or SUSE websites in order to show always the latest version. Of course, the installation media includes a copy of them, which may be outdated, to be used when there is no network connection.

From now on, instead using some additional files, this offline copy of release notes will be retrieved from the release-notes package which lives in the packages repository. So we do not need to ship additional files containing release notes in the installation media anymore.

Moreover, although the old approach worked just fine in almost all cases, there was an uncovered scenario. Let’s consider a system which have access to an updated packages repository but is not connected to Internet. That could be the case, for instance, if you are using SUSE Subscription Management Tool (SMT). With the new approach, the installer will get release notes from that repository instead of displaying the (potentially outdated) ones included in the installation media.

Additionally, we refactored and clean-up a lot of old code, improving also test coverage.

Storage reimplementation: bringing more features back

We are also working hard to make sure the brand new yast2-storage-ng includes all the features from yast2-storage, in addition to the new ones. That means that, after this 44th sprint, SLE15 is already able to perform the following operations using the new module.

  • Creating MD software RAID devices in the expert partitioner. This feature is specially relevant for many openQA tests that rely on it.
  • Displaying the compact description of the partitioning proposal in the one-click-installer screen used by SUSE CaaSP and openSUSE Kubic
  • Importing users and SSH system keys from a previous (open)SUSE installation.

One-click-installer view on SUSE CaaSP 4.0 (yast2-storage-ng)

Rethinking LVM thin provisioning

When trying to create a thin-pool using all free space the metadata has to be accounted for. In contrast to linear LVs the metadata for thin-pool uses space of the VG. For instance, if there are 2048 GiB free in the VG, the metadata for a maximal size thin-pool is about 128 MiB and the pool can be about 2047.9 GiB big.

Additionally LVM creates a spare metadata with the same size. This spare metadata is shared between all pools and thus has the size of the biggest pool metadata. The spare metadata can be deleted manually and all pool metadata can also be resized.

When starting with an empty VG it is relative easy to account for the metadata. But how to handle this with an already existing volume group? Also take into account a volume group containing e.g. RAID LVs or cache pools (which also have metadata).

We finally decided that, during probing, YaST will check how much free space the VG has and then it will calculate “reserved” value for the volume group:

reserved = total size - used by LVs the library handles - free

So when calculating available space for a normal or thin pool, it will take the “reserved” into account:

max size = total size - reserved - used by LVs the library handles

The only drawback is that the maximal size for the pool can be smaller than actually possible since e.g. the spare metadata might be shared with an already existing thin pool.

More to come

The 45th sprint has already started and you can expect more and more work in the installer for SLE15 and openSUSE Leap 15 and more news regarding the revamped storage stack. Meanwhile, don’t forget to have a lot of fun!

SUSE Support Lands Upstream In cloud-init

September 21st, 2017 by

Well it’s been many many years and many many releases that we’ve been carrying a large number of patches for the cloud-init package in openSUSE and SUSE Linux Enterprise. I remember the first semi serious implementation of SLES support happened when I worked with HP to get SLES into the HP Public Cloud offering, which was based on OpenStack. The offer was eventually named Helion Public Cloud and then eventually shut down. Yes, it’s been many many years and I have received many questions about when is SUSE support going to be upstreamed, and my answer was always, “when I get around to it“. Well, it finally happened, in big part thanks to the cloud-init summit which was held for the first time earlier this year. Google in Seattle was a great host and I very much appreciate that I was invited.

Anyway, long story short spending some face time with other contributors and working out the kinks that existed in the pipeline worked wonders.  Rather than sending a small patch here and there the main implementation for openSUSE and SLE, lots of code, were accepted shortly after the cloud-init summit and over the last couple of days another couple of patches took us another step forward.

There are a few more loose ends that need work but with 17 patches removed from the package build, currently building in Cloud:Tools:Next in OBS we’ve made major progress.

Well, I for one am happy about this, and those that want to install from source can do so and have openSUSE and SLE support working from the upstream sources and not just from the packages included with openSUSE and SLE.

Thanks to Canonical for organizing the summit to get everyone together and thanks to Google for hosting the summit.

Oh and before I forget, getting the changes accepted was not the only major step forward, openSUSE Leap 42.3 will, in the not too distant future, like in the next couple of days, be integrated into cloud-init testing using containers the lxd project builds, go figure who knew these even existed.

Highlights of YaST Development Sprint 43

September 21st, 2017 by

The summer is about to end (in Europe) and it is time for another YaST Development Sprint report. As usual, storage-ng has been one of the stars of the show, but new installer features for upcoming SUSE/openSUSE versions have received a lot of attention too. Also CaaSP 2.0 got some love from us during this sprint.

storage-ng: Udev mapping and ARM64 support

The new storage layer is getting better everyday. After the big amount of work that came with the re-implementation, the team is trying to unleash the power of the new design.

Udev Mapping is Back

The bootloader module supports using persistent device names provided by Udev. It is a pretty useful feature that comes in handy in many situations but it was missing in the storage-ng based version of the module.

But fear not: this feature has been re-implemented taking advantage of the much improved API of the new storage layer. And that’s not all: the team also took this opportunity to clean up some code and document the strategy for picking Udev device names in a proper way.

Do you want more details? Here you have them. Let’s start with the scenarios we support:

  • S1: Disk with the booting configuration is moved to different machine
  • S2: Disk dies and its content is loaded to new disk from a backup (because you have a backup, right?)
  • S3: Path to disk breaks and is moved to different one

Given these scenarios, let’s have a look at the strategies:

  • If the device has a filesystem with its mount_by, do not change it.
  • If the device names includes a by-label, just use it. This behaviour enables us to handle the three scenarios.
  • If there is by-uuid, then use it. It can also handle the three scenarios.
  • If there is by-id, use it. It can handle S3, but not always.
  • If there is by-path, just use it. It is the last supported Udev symlink and, at least, it will prevent the name changing during boot.
  • As fallback, just use the kernel name (for instance, /dev/sda3).

storage-ng now works also on ARM64

For quite some time, the storage-ng code has been tested (and worked) on x86_64, ppc64 and s390x architectures. Now, we have added aarch64 to match the list of supported architectures in SUSE Linux Enterprise and openSUSE Leap.

Speeding up the Service Manager Startup

As you may know, YaST includes a nice module for managing systemd services. Compared to systemadm, included in the system-ui package, there are some key differences:

  • It displays only services, not other unit types such as sockets.
  • It can enable/disable them for the next boot.
  • It works, as any YaST module, in textmode (even on 80×25 terminals).

Some time ago we got a report that the presented information was inaccurate in some corner cases. We fixed that but also made the module a lot slower at the same time. It did not take long for that to be reported.

We tested the following scenario: 286 services (SUSE Linux Enterprise 12 SP3 with nearly all software patterns installed) on a not very fast virtual machine. Normally, you should have fewer services and probably a faster system, but we wanted to fix the issue even for the worst scenario.

After analyzing the problem, we found out the root cause: too many calls of systemctl, at least 3 times per service (show, is-active, is-enabled). With a couple dozen milliseconds per call, it quickly adds up.

The fix was to combine all show calls into one and correctly interpreting the ActiveState property to eliminate all of the is-active calls. But you want to know the numbers, right? After the fix, the startup time went down from 69 to 15 seconds (bear in mind that it is a slow virtual machine).

So even if your system is not that slow or you have fewer services installed, you may benefit of a shorter startup time for this module.

Multi Repository Media

There are some hidden gems in YaST that are maybe not well known although they have been there for a long time. One of those features is support for multi repository media.

What actually is a multi repository medium? Imagine a CD or DVD with several independent repositories. The advantage is that, if you want to release several add-ons, you can put them all on a single DVD medium. Really nice stuff, isn’t it?

Up to now YaST added all repositories found on the medium automatically without any user interaction. In this sprint we have added a new dialog into the workflow which asks the user to select which repositories should be used. Of course, if there is only one repository, it does not make sense to ask and the repository is added automatically.

Selecting which add-ons should be installed

i18n support for CaaSP 2.0

On June 2017, SUSE released the first version of the promising SUSE CaaS (Container as a Service) Platform. The YaST team actively worked on this project by adding several new features to the installer, like the one-dialog installation screen.

That very first version of CaaSP was only available in English. However, version 2.0, which is around the corner, will support more languages. For the YaST team, it means that we needed to add the language selector to the
installer, as you can see in the screenshot below, and to mark every string in the yast2-caasp for translation.

YaST2 CaaSP features a language selector

Finally, if you are interested in CaaSP, maybe you would like to check out Kubic, its Tumbleweed based variant.

More bug fixes

Apart from the new and shiny stuff, the YaST team was able to fix quite some issues during this sprint. Let’s have a look at some of them.

Taking Care of Small Details

Not enough space for device name

Usability is a critical point for a project like YaST. From time to time, we receive a bug report about some usability problem that needs to be addressed and we took them very serious. In this case, the bootloader module had a problem when showing long device names in the dialog to change the order of disks. So we just needed to do a minor fix in order to ensure that there is enough space.

Device name is shown properly

Please, keep reporting usability related issue you find in order to make YaST even better.

Fixing the INSECURE mode

It sounds scary, but YaST supports an insecure mode during installation. What does it mean? YaST is pretty flexible when it comes to system installation. You, as a user, has the power to modify/tweak the installer (using a Driver Update Disk), add custom repositories, etc. And sometimes it can be useful to skip some checks.

Some time ago, libzypp introduced a new callback to inform about bad (or missing) GPG signatures. This callback was properly handled by AutoYaST but it was ignored in regular installations, so the user always got the warning about the failing signature, even when running on insecure mode.

Now the problem has been fixed and you can run the installer in insecure mode if you want to do so.

Learning about FCOE

YaST deals with a lot of moving parts and, although it can be daunting for the newcomer, it also has a bright side: we regularly learn new stuff to play with.

In this case, Martin Vidner, one of our engineers, had to deal with a fix related to the Fibre Channel over Ethernet support in YaST. But instead of blindly applying the patch that we already had, Martin decided to learn more about the topic sharing his findings in its own blog. Sure it will be a valuable resource to check in the future.

Highlights of YaST Development Sprint 42

September 7th, 2017 by

Kids started school in Prague, and we’re energized to bring you news from the YaST team.

This sprint we made progress in:

  • selecting one of several products to present on a DVD
  • adapting to the switch to the rpm-md package metadata format, regarding licenses and the Beta notice
  • notifying about not being able to support ReiserFS also in the case of an upgrade via AutoYaST
  • not reporting missing optional patterns

As always, the new storage stack deserves a separate section.

  • Expert partitioner has a better initial summary and it handles Btrfs subvolumes better.
  • Snapper can create and restore snapshots now.
  • A more flexible installation proposal is being developed.
  • It has landed in SLE15/Leap15 already.

Selecting the base product in the first screen

As we reported three sprints ago, YaST will support having multiple products on the same installation medium. This feature will allow to ship several SUSE products on the same DVD asking the user which one to install.

But, as an (open)SUSE user, you may know that the first screen of the installer allows you to select the language/keyboard and, additionally, it shows the product’s license. But which license should we show for multi-product media?

After asking our UX expert, we decided to allow the selection of the product in the welcome screen as you can see in the image below.

Obviously, this behavior applies only to multi-product medias. When using a single product one, the license is shown directly in the welcome screen.

Finally, as developers, we would like to highlight that we mainly re-implemented the welcome screen using modern YaST techniques (like our object-oriented API to YaST widgets), improving test coverage and code quality.

Getting licenses from repositories

In the sprint 40 report, we announced that YaST was dropping support for SUSE tags because the plan is to use RPM metadata and packages to store all that information (licenses, release notes, etc.).

During this sprint (and the previous one) we focused on improving how base product licenses are handled. Until now, licenses lived in a tarball which was included in the installation media. But that is not the case anymore: now YaST relies on (the awesome) libzypp to get products licenses directly from the repositories. There are still some rough edges: for instance, multi-language support should be improved, but we will tackle them pretty soon.

Finally, bear in mind that only base product licenses have been adapted, but we plan to do basically the same for modules, extensions and add-ons.

Updated README.BETA Support

The YaST installer supports displaying the README.BETA file from the installation medium. This file is added during Beta phase so the users know this is not the final release. This is also useful after the final product is released if you by mistake boot the old medium.

Unfortunately the original YaST code supported only the so called SUSE-Tags repository format which was used for the CD/DVD media. However, the new SUSE Linux Enterprise media will use the RPM-MD format which is something completely different.

In this sprint we have added the support for the RPM-MD format and additionally we display the Beta warning popup also in the AutoYaST installations. Of course, blocking AutoYaST with a popup would be a bad idea so in the AutoYaST mode the popup is automatically closed after a timeout. (The default is 10 seconds but can be configured in the XML profile.)

Drop support for ReiserFS autoupgrade

The drop of ReiserFS support for manual installation was announced in our last post, and now is the turn to autoupgrades.

With SUSE Linux Enterprise 15 the autoupgrade will be blocked in case of ReiserFS presence were detected suggesting a manual conversion to another filesystem.

Software proposal does not report missing optional patterns

YaST guides you through the installation process of your system making you a proposal based on the different selections like the product, addons, system role, desktop etc.

This proposal contains some software patterns that are mandatory and some that are optional but only the mandatory ones will be reported when the proposal is shown.

During this sprint we solved a bug which reported not only missing mandatory patterns but also optional ones.

The Storage Stack (storage-ng)

Storage reimplementation: Expert Partitioner

As you probably already know, in the YaST team we are rewriting our powerful expert partitioner tool from scratch to adapt it to the new storage layer. Sprint by sprint we are bringing back some of the many great features the expert partitioner offers, and this time it will not be different.

Now, when entering to the expert partitioner, all available storage devices are presented in an initial summary. Moreover, in this first screen you could find an option to rescan your devices, which allows the expert partitioner to be aware about the changes in your system, for example when you plug in a USB stick.

The management of Btrfs subvolumes was also improved during this sprint. Now, you will be alerted when a new subvolume is shadowed by an existing mount point. Moreover, some subvolumes could be automatically deleted or created when a mount point changes in the system.

Snapper can snap again

We reintroduced one of the most important features about using Btrfs: Being able to create snapshots, so you can go back to a previous state of the system if anything went wrong during a package upgrade or when you changed anything about your system configuration. This means we are now again setting up and configuring snapper correctly, installing everything into a subvolume and creating an initial snapshot when the installation is complete.

Why install into a subvolume in the first place? When snapshots are made in the future (e.g., during package upgrade or installation) and at some point you decide to roll back to one of those snapshots, you might want to delete previous snapshots to save disk space. If we didn’t install into a subvolume, the initial files would always be left over and consume disk space, so there would be a considerable resource leak.

Twisting the storage proposal

As you should know, one important part of the rewritten storage stack is the partitioning proposal. The old one was designed with a rather narrow scope in mind. Targeting desktops and old-school servers, it always proposes a root file-system, a swap volume and an optional separate /home. That’s not the most useful schema for new innovative products with a different focus like SUSE CaaS Platform, openSUSE Kubic, SUSE Manager, etc.

As we remind quite often, all the products supported by YaST (SLES, SLED, Leap, Tumbleweed, Kubic, CaaSP, SUSE Manager, SLES4SAP, you name it) share an identical installer. That installer is fully configurable using the file control.xml that is included in the media and that allows to define the sequence of installer steps, the default values and much more.

One of the goals of the new storage proposal is to give product creators and release managers more freedom and flexibility configuring the behavior of the guided setup. And for that we need a better format for control.xml, so they can express themselves with fewer limitations.

Of course, that new format is not something for the YaST team do decide on its own, but something being designed openly in collaboration with all the involved parties. To make easier for anyone to jump into the subject we have prepared this detailed document which includes all the present and historical information to understand the topic, as well as an explanation of the new format with several examples based on existing or hypothetical use cases.

As everything in YaST, that document is alive and expected to continue changing and evolving based on everybody’s feedback and contributions. So feel free to take a look and suggest improvements or future use cases we may have overlooked.

The storage stack is dead, long live the storage stack

In our previous sprint report we told you we were working to integrate the new storage stack into the future SLE15 and openSUSE Leap 15 codebase. Now the submission process is over and the preliminary images of both future distributions are fully based on libstorage-ng. For openSUSE Tumbleweed, that is the Staging:E project. That means we now have many more eyes looking into it, finding bugs, pointing what is missing and providing feedback about the new behavior. Of course, every couple of eyes comes with a little bit more of pressure for the YaST Team to get things done as soon as possible, but also with a pair of hands to help us getting there.

New blog – cyberorg.wordpress.com

August 29th, 2017 by

I have not been actively participating in openSUSE project for some time now, as a result there has not been much to blog about on openSUSE Lizards blog, there is a new blog at https://cyberorg.wordpress.com to blog about what I have been and will be up to with Li-f-e: Linux for Education project among other things. I am also now “Member Emeritus” of the openSUSE community due to lack of participation, so cyberorg@opensuse.org email address will no longer work, please use @cyberorg.info if you need to get in touch with me.

After almost a decade of bringing you Li-f-e: Linux for Education based on openSUSE, it is now based on Ubuntu MATE LTS releases. I hope to provide the same excellent user experience that you have come to expect. Download it from here. Reason for this change is mentioned in previous post and it’s discussion(lack of interest/time/skills by anyone for maintaining live installer). You can of course easily enable Education Build Service repository to install packages on standard openSUSE or use susestudio to create your own spin with Education packages.

To new beginnings…

Highlights of YaST development sprint 41

August 24th, 2017 by

We all know that everything slows down in summertime and software development is not an exception. But heat is not enough to stop the YaST team from turning the Scrum wheel and delivering the corresponding sprint reports. Let’s take a look to what we have been doing the last two weeks.

The storage reimplementation gets on the launchpad

As already anticipated in the previous report, one of the goals of this sprint was to merge the new storage stack into the codebase of SUSE Linux Enterprise 15 and openSUSE Leap 15. That implies submitting everything to Factory first and making sure the result looks harmless and good enough there. Thanks to the awesome openSUSE tools and processes, that kind of experiments can be isolated in a dedicated staging project allowing us to reach useful conclusions without risking the stability and features of Tumbleweed.

So we submitted two new source packages libstorage-ng and yast2-storage-ng to Factory, together with new versions of all the affected packages (already adapted to use the new system, instead of the old yast2-storage) and a modified version of the list of packages to be used during installation.

Everything was mixed and cooked in the Staging:E project and… guess what! We got brand new Factory ISOs with storage-ng, successfully building and verified to work by openQA, as you can see in this screenshot of the Staging Dashboard.

Storage-NG in the Staging Dashboard

Yes, we know there are two failing tests in that dashboard, but that was fully expected since those tests use the expert partitioner to configure an installation of openSUSE on top of a MD RAID system and the reimplemented partitioner still lacks some controls to configure MD RAID arrays.

The new stack will live in Factory:Staging:E (or any other staging project the Tumbleweed crew decides) for quite some time, until it’s feature-pair with the old storage layer and, thus, can progress further in its travel to Tumbleweed. But Factory was just the first stop, the ultimate goal of this sprint was getting into the preliminary versions of the next SLE and openSUSE Leap.

That second integration is taking a little bit longer because it has coincided on time with other important changes in the installer and the base system… and the fact that August is the typical European vacation period is not exactly helping to iron all the details out. But since the new storage system works for Factory, we are certain it will do it for SUSE Linux and Leap.

As readers familiar with the Tumbleweed development process may have noticed already, having all those packages in Staging:E implies that newer versions of them will only reach Tumbleweed all at once, when yast2-storage-ng is considered mature enough for that. Somehow, that will block us from delivering new features for the packages you see in the list in the mentioned image of the dashboard. But don’t worry, if something serious happens and a critical update is needed we will not let our beloved Tumbleweed users down.

But there is much more happening in YaSTland beyond the storage reimplementation. Let’s take a look to the improvements in other areas.

Installation without Grub packages

Sometimes, users have already Linux installed in their system and they do not want to install Grub in MBR again with a new Linux distribution since the installed Linux can manage the bootloader. For this case, the user may decide to not install grub packages at all in the system. However, until now the user was obligated to install this package otherwise an error message would appear, as the image below shows.

YaST2-bootloader wrongly reporting about grub2 installation

For some specific scenarios, as you may find here, even other packages are required, and when the user decided for not installing the bootloader, these packages were still required for the installation.

We changed this behavior in Tumbleweed and SLE 15, and now the users will be able to install the system without the packages that are not required, in case they decide to manage bootloader through another operational system.

But that’s not the only improvement introduced in the bootloader management during this sprint.

Improve how YaST finds disk to install Grub in MBR

In Leap 42.3 and SLE 12.3, we found out that, in some very specific cases (check the bug report for more details), YaST was not finding the correct disk to install Grub in MBR. When it happened, an error message appeared at the end of the installation, showing that Grub could not be installed in /dev/btrfs disk.

Error during bootloader installation

We improved our approach to finding the correct MBR device, by adding a specific search for the disk where the partition /boot or / (in case /boot does not exist) is located.

Such a change will be released as maintenance update and self-update, and it affects only Leap 42.3 and SLE 12.3, since SLE 15 will use the new storage layer, which does not need this double check for the correct disk.

And talking about the new storage system…

Remove support for ReiserFS

The support of new installations with ReiserFS was removed from YaST in SUSE Linux Enterprise 12 and openSUSE Leap 42 but upgrades were still supported.

With SUSE Linux Enterprise 15 and Leap 15 the support of ReiserFS will be completely removed from YaST and the installer will block the upgrade of systems formatted with ReiserFS.

If some of the entries in the /etc/fstab file of the system to be upgraded is using ReiserFS, the installer will suggest to convert them to another filesystem type before migrating the system to SUSE Linux Enterprise 15 or openSUSE Leap 15.

Preexisting /opt formatted as ReiserFS

A similar blocking error will be reported for ReiserFS root partitions.

Updating a ReiserFS root system

Another Ruby 2.4 fix

This may be interesting for Ruby developers in general. We got a bug report about crashing YaST which in the end turned out to be caused by upgrade to Ruby 2.4. The tricky part was that YaST crashed randomly and it was difficult to reproduce the problem.

It turned out that the crash happened when Ruby wanted to print a warning on the error output, which in some situations failed. We did not fix the race condition, as it likely would be too difficult to debug the Ruby internals, but we at least fixed the code to not produce the warnings anymore.

So if you are a Ruby developer take this free advise from your YaST fellows – if your code crashes randomly with Ruby 2.4 then check for the Ruby warnings first.

A heads-up about network devices names

Two sprints ago we told you about the new possibility of configuring the network with AutoYaST already in the first stage, avoiding an extra restart of the system in most cases.

During this sprint we spent some time trying to test old AutoYaST profiles (with complex network configurations) with the upcoming version of SUSE Linux Enterprise Server, using our suite of automatic AutoYaST Integration Tests. But we found some issues caused by the current architecture of our test suite that may be of interest for some of our readers.

Let’s see some technical background first.

Tumbleweed has been using ‘predictable network interface names’ for some time now and it fits most regular use cases. Inspired or following the scheme idea introduced by ‘biosdevname’, Predictable Network Interface Names was adopted in systemd/udev v197 trying to solve an historical problem with the non deterministic classic naming scheme for network interfaces (eth0, eth1, eth2 …)

Basically it will assign fixed names based on firmware, topology, and location information making them stable between system reboots, hardware additions or removals and also between kernel or drivers updates.

For the upcoming SLE15, we are giving predictable network interface names a try (they are disabled in SLE12 and openSUSE Leap 42.x). For us that turned to be a problem because our AutoYaST testsuite dynamically creates new virtual machines on every system reboot (instead of really rebooting the virtual machine created in the previous step). So from the point of view of the operating system being tested, all the network devices are replaced by new ones in every reboot and that drives the network settings nuts.

That was only our case (arguably “our fault”), but there might be other situations in which going back to the old naming scheme (with names like ‘eth0’) would be more convenient than adapting the preexisting AutoYaST profiles to the new one. In such cases you still can use the old scheme (not fully predictable but very well known by Linux veterans) by just booting the SLE15 installation with this parameters.

biosdevname=0 net.ifnames=0

Disabling predictable network names in SLE15

More to come

In addition to everything reported in this post, we have been working hard to get some new cool features to the upcoming SLE15 and to get the storage reimplementation full-featured enough to substitute the old one in all possible situations.

So, although it would still be summertime (in Europe), stay tuned for more news in two weeks.

Developing with OpenSSL 1.1.x on openSUSE Leap

August 18th, 2017 by

The SUSE OpenSSL maintainers are hard at work to migrate openSUSE Tumbleweed and SUSE Linux Enterprise 15 to use OpenSSL 1.1 by default. Some work remains, see boo#1042629.

Here is how you can use OpenSSL 1.1 in parallel to the 1.0 version on openSUSE Leap for development and run-time:
Read the rest of this entry »

Highlights of YaST development sprint 40

August 10th, 2017 by

Doubtlessly, these are pretty exciting times for the YaST team. The merge of the new storage layer into the main codebase is around the corner and we are working on other features that will debut on the next open(SUSE) major release. So let’s summarize what happened during the last sprint.

New storage layer is coming

As you may already know, the YaST team has invested a lot of time and effort preparing our storage layer for the future and we have started to merge the new layer into the main code base during the current sprint. But that’s something for our next report, right? By now, we will just focus on the stuff that got added and fixed during the last two weeks.

Storage reimplementation: BIOS RAID support

libstorage-ng, the low level library in which our new storage layer relies on, got support for BIOS RAID (handled in Linux via MD devices). Now, YaST could take advantage of such a feature to allow the installation of open(SUSE) systems on this kind of devices, including the bootloader.

BIOS RAID support

Storage reimplementation: managing BtrFS subvolumes in new Expert Partitioner

The new Expert Partitioner is getting a lot of attention these days and, during sprint 40, it got initial support for Btrfs subvolumes management.

Btrfs subvolumes list

Now, when you select the BtrFS section in the general menu placed on the left, all BtrFS filesystems are presented allowing you to edit its subvolumes through a dialog which contains the list of subvolumes that belongs to the filesystem. Apart from the usual stuff, like adding and deleting subvolumes, it is also possible to set the noCoW property when you are creating a new one.

Adding/Removing Btrfs subvolumes

However, some features are still missing. For instance the partitioner will not prevent you to create a subvolume which is shadowed by an already existing mount point. Consider the current implementation as the first step towards a really cool Btrfs subvolume handling.

Dropping SUSE tags support

During installation, YaST uses a mechanism known as SUSE tags as source of information for media handling. For instance, a /content file contains information about the product, languages, etc. Additionally, information like release notes or the slide-show texts are stored in the installation media.

Some time ago, SUSE decided to drop SUSE tags and use RPM metadata and packages to store all that information. To make it possible, the installation media would use REPOMD repositories.

Obviously, YaST needs some adaptation. As a first step, support for the /content has been dropped, cleaning up some old and even unused code.

In the upcoming sprints, YaST will be adapted to retrieve licensing, release notes, etc. from RPM repositories and packages, which is also an opportunity to do some refactoring and to improve test coverage.

AutoYaST support for add-on products on same installation media

Nowadays YaST supports having add-on products on the same media than the base product. The problem is that the EULA for those products is displayed too early, even before AutoYaST had been initialized at all.

To solve this issue, now the EULA acceptance of included add-ons is performed at the same time than other add-ons which are not included in the installation media. As a side effect, now the user needs to define those add-ons on the AutoYaST profile in order to handle the EULA acceptance.

Bug squashing and 80×24 terminals

As developers, we enjoy working on new features and, of course, we are committed to fix critical bugs as fast as possible. But there are many small (and annoying) bugs out there that deserve our attention. Additionally, there are several bug reports that are no longer valid (the bug was fixed, it is not reproducible, it is a duplicate, the affected product is not supported anymore, etc.). In order to reduce the list of open issues, the team decided some sprints ago to reserve one day to do some bug squashing.

Among the bugs we closed during this sprint, we would like to highlight a usability problem in YaST services manager. Bear in mind that, along with the graphical interface, YaST ships a text based one which is supposed to fit in good old-fashioned 80×24 terminals. That’s an interesting constraint when you are designing interfaces for YaST.

Needlessly to say that, from time to time, we get a bug report about some element that just do not fit. In this case, YaST services manager had a problem when the service name was too long as you can see in the screenshot below.

Too long service name

Now, if there is not enough space, the name will be truncated and the rest of the information will be shown in an proper way.

Truncating a too long service name

Do not miss the next report!

As you may have noticed, a lot of interesting things are currently happening in the YaST world and more cool stuff is about to come. So you should not miss our next sprint report.

By now, enjoy openSUSE 42.3 (you already upgraded your system, right?) and see you in two weeks.

Highlights of YaST development sprint 39

July 31st, 2017 by

openSUSE 42.3 is out! Do you need some reading material while you wait for the download of the new release to finish? Don’t worry, we have the solution right here – another YaST team report. 😉

Several products in one installation medium

Obviously, we stopped adding new features to SLE12-SP3 and Leap 42.3 some days ago, because everything needed to be tested properly before the release. So now we are mainly looking into the future. And one of the plans for that future regarding SUSE Linux Enterprise (SLE) is offering several products packed in a single installation medium.

SUSE offers several mission-specific products based on SLE and, so far, every product needs to be installed from its own medium (usually a DVD or a virtual image). So if you use SLE Server, SLE Desktop and SLE Server for SAP, you have to have three DVDs which is a bit cumbersome.

After some discussions about the technical implementation details, we created a first prototype of the installer with an extra dialog that allows to select one of the detected products and continues the installation from there according to the installation workflow of the chosen product. It is still a proof of concept, but we can at least share screenshots showing how it looks for the time being.

The new product selection screen

So far, there are no plans to use the new feature in openSUSE, mainly because the project does not deliver separate mission-specific products in the same way than SUSE does with SUSE Linux Enterprise.

Storage reimplementation: numbers after repatriating the Expert Partitioner

In the Sprint 36 report we presented the rewrite of the YaST Partitioner and we have been informing about its evolution in subsequent reports. We told you back then that we decided to split it in a separate yast2-partitioner package. But time has proved that decision to have too many drawbacks so we decided to bring the Partitioner back home, to yast2-storage-ng. As part of the process, we got rid of an old previous prototype of the Partitioner that was still lying in the yast2-storage-ng repository and some code that was there just to support that old prototype.

You may be asking why is all that relevant. It is because that means the repository (and thus the package) is finally approaching the final structure it will have when released into Tumbleweed. And that implies that all the systems we use to automatically measure the quality and reliability of our repositories are now providing trustworthy results… as trustworthy as automatic quality evaluations can be.

And according to those tools:

  • 93% of the code in yast2-storage-ng is covered with automated unit tests in addition to openQA (this number is expected to raise in close future as we polish the new Partitioner),
  • Code Climate reports a code quality GPA of 3.91 out of a possible maximum of 4
  • and 76% of all the classes, modules and functions, including the internal ones, are properly documented (with that developer documentation being available here, by the way).

If you wonder about the numbers for the old codebase we want to replace, its code quality is 0.94 and only a 31% of it is covered by unit tests. A perfect example of legacy code.

Storage reimplementation: Btrfs subvolumes in AutoYaST

As reported in previous posts, the new storage stack can already process AutoYaST profiles including partitions, LVM and MD arrays, but some details are still missing. The first of those details we wanted to address was the definition and creation of subvolumes in a Btrfs file-system.

Now it works according to the official documentation – both syntaxes for the <subvolumes> section are supported, it never creates subvolumes that would be shadowed by any other mounted file-system and it uses the list in control.xml as fallback for the root partition if Btrfs is used but subvolumes are not specified.

All that, as usual in the re-implemented stack, with fully tested and documented code.

Btrfs subvolumes support in AutoYaST

Storage reimplementation: handle multipath I/O in the proposal

In the previous report we showed you how the support for Multipath I/O looked at the library level, which usually means just geeky graphs. During this sprint, we have taught the installer to use that new library feature, so we now have real screenshots to show!

During the installation, now multipath hardware is detected and the user is asked for activation.

Popup for activating Multipath I/O

If the user agrees, the installer will never use the individual disk devices to propose a partitioning layout and it will not offer them as an option during the guided setup. The installer always works on the final (compound) multipath device, proposing the correct names for the partitions and so on (which, being a devicemapper device, follows a
different pattern when compared to raw devices).

Suggested partitioning with multipath

The resulting system is still not fully bootable because yast2-bootloader has still not been adapted to this scenario. Very likely, something for the upcoming sprint, so stay tuned.

Support for Ruby 2.4

The world changes every day and we are always adapting YaST to remain shiny. The 2.4 version of Ruby is about to land in openSUSE Tumbleweed and is expected to be the default Ruby for SUSE Linux Enterprise 15 and openSUSE Leap 15. We found that some of the YaST packages were not fully ready for this new Ruby, so it was time for some tweaking.

After dealing with quite some details too technical and boring for this blog (but feel free to ask if you want the gory bits), YaST is shining again in Factory, which means we are no longer blocking the adoption of Ruby 2.4 in Tumbleweed.

Add-on Creator and Product Creator

As our team keeps always developing new features, solving bugs, and receiving feedback, we always evaluate our priorities and product. Sometimes, during this evaluation, we see that some YaST modules do not bring enough value or do not shine enough as part of our standard package.

After some evaluation, we come to announce that the modules Add-on Creator and Product Creator will no longer be part of YaST. These packages use Kiwi as backend and we have high competition on UI sides – SUSE Studio and Open Build Service. So it no longer makes sense to have these packages and we recommend for users of these modules to use one of the alternatives or Kiwi directly if you already have an XML definition file for Kiwi.

Adapting YaST to accept 12 digits Service Request Number

As Service Request Numbers can be now composed of 11 or 12 digits, instead of only 11 digits as before, we had to adapt YaST to handle this change. YaST module Support can now accept 11 or 12 digit service request numbers. We implemented such a change for all products dating back from SLE 10 SP3 until the most recent SUSE Linux versions. Updates with this change will be soon released.

Network Setup in the 1st Stage of Autoinstallation

The YaST installation used to have two stages, separated by a reboot. Starting with SLE 12 and openSUSE Leap 42.1 we have eliminated the
second stage. But it was still needed for AutoYaST, controlled by the setting

<profile><general><mode><second_stage>true | false</...>

We have fixed those parts of the networking setup and now you can explicitly set AutoYaST to not use a second stage anymore.

User settings in AutoYaST

An issue that we have found out is that GDM has problems with the system when different users have the same UIDs. If it happens, GDM does not start properly. As a solution, we decided that either UIDs will be defined in the AutoYaST configuration file for ALL users or this tag will not be used at all for ALL users since a mix of both can result into duplicate UIDs.

And we just keep YaSTing!

We hope you liked our report as much as we loved to build all of that. We’ll continue YaSTing so we can reach you again in two weeks with much more cool stuff to show.

By now, enjoy your openSUSE 42.3 and all the cool features that came with it!

Increase the thread/process limit for Chrome and Chromium to prevent “unable to create process” errors

July 25th, 2017 by

Browsers like Chrome, Chromium and Mozilla Firefox have moved to running tabs in separate threads and processes, to increase performance and responsiveness and to reduce the effects of crashes in one tab.

Occasionally, this exhausts the default limit on the amount of processes and threads that a user can have running.

Determine the maximum number of processes and threads in a user session:

$ ulimit -u

The SUSE defaults are configured in /etc/security/limits.conf:

# harden against fork-bombs
* hard nproc 1700
* soft nproc 1200
root hard nproc 3000
root soft nproc 1850

In the above, * the catch-all for all users.

To raise the limit for a particular user, you can either edit /etc/security/limits.conf or create a new file /etc/security/limits.d/nproc.conf. Here is an example for /etc/security/limits.d/nproc.conf raising the limit for the user jdoe to 8k/16k threads and processes:

jdoe soft nproc 8192
jdoe hard nproc 16384

If you want to do that for a whole group, use the @ prefix:

@powerusers soft nproc 8192
@powerusers hard nproc 16384

In either case, this change is effective only for the next shell or login session.