openSUSE Lizards

Archive for the ‘Distribution’ Category

YaST Squad Sprint 59 & 60

August 22nd, 2018 by Yast Team

We know, we know… we owed you a report for the 59th sprint! But you know what? We are now delivering this summary which covers sprints 59 and 60 so we are now up to date again.

During these weeks, we have been working mainly in two different areas. On one hand, we have improved YaST services management capabilities, adding support for on demand services and making the user experience slightly better. On the other hand, we are still working in the new storage layer, extending it to support Xen virtual partitions and fixing BIOS MD devices handling, among other things.

Last but not least, our bug fighting squad (do you remember squads, right?) have fixed quite some bugs accross our full stack.

So let’s have a tour to recap some highlights from these sprints.

Services Management Gets Some Love

The team is investing quite some time improving the services management area. In the past, YaST was adapted to play nicely with Systemd (which replaced the old runlevel-based init system). However, there was a lot of room for improvement, as Systemd added some new features when it comes to services management that were not supported in YaST at all.

To explore these changes, let’s start by having a look at the new services manager user interface.

At first sight, you may have spotted some changes: there is an Start Mode menu button where the Enable/Disable used to be; new Apply or Show Logs buttons have been added; the Start/Stop button has been replaced by an Start (or Stop) one… Ok, let’s describe these changes one by one.

Perhaps the most relevant update is the support for socket activated services. But you may be asking what a “socket activated service” is, right? In a nutshell, these are services that are started on demand. For instance, the printing service could be started only when you want to use the printer. And that’s what the Start Mode button is all about. For instance, you may want the printing services to be started only when needed (On Demand) and YaST will take care of setting up Systemd units in order to do so.

Another interesting feature is browsing services logs. Beware that this button will be available only if yast2-journal is installed because it uses the browser provided by this package.

And browsing the logs brings us to the new Apply button. Sometimes, it may be useful to Start a service and check the logs looking for potential problems. In the past, the changes were applied when the OK button was pressed but, unfortunately, the services manager was then closed. Now, with the Apply button, you can ask YaST to made those changes for real without closing the services manager (and check the logs or keep adjusting services).

But that’s not all! Among other small changes (like fixing bug #1080738) we are still improving the UX for this services manager.

Make the Xen virtual partitions great again

Rewriting a piece of YaST that is 20 years old is a never-ending source of surprises. When we though that Storage-ng did already support all the storage technologies handled by the old storage stack, we just found that we had left something behind.

When setting a Xen virtualization environment, it’s possible to define block devices that are seen and named like partitions in the Xen guest, but are in fact disks (or almost-disks, since they cannot be partitioned by regular methods). In other words, the Xen guest can see some block devices called e.g. /dev/xvda1 and /dev/xvda2 without a corresponding /dev/xvda.

From the YaST point of view, you can do whatever you can do with a partition (format it, mount it, etc.), except you can’t delete them or create more (since they are not backed by a disk, from the perspective of the Xen guest). We call those devices “Xen virtual partitions”. The old storage stack used to pretend those devices were just plain partitions of a made-up /dev/xda disk that was not there in the system but still appeared in the Partitioner and in the AutoYaST profile. The new stack simply contained no support at all for Xen virtual partitions.

We fixed that during the last sprint, making the feature available on the SLE-15 installation process thanks to the installer self-update feature. So either if your Xen guest runs a fully up-to-date version of SLE-15, Leap 15.0 or Tumbleweed or if you are installing SLE-15 with access to the installer self-update repositories, virtual partitions are visible in the Hard Disks section of the Partitioner.

It works in a in a similar way to the old (pre Storage-NG) Partitioner, but without artificial disks to group the virtual partitions. See the following screenshots in which xvda is a DVD, xvdb a real disk and xvdc1 a XEN virtual partition (there is no bogus xvdc added by YaST).

Only the Edit button really works as expected, allowing the user to mount and/or format the virtual partition. The other buttons just show the appropriate error for the different unsupported operations.

I want that on my Leap 15.0 installer

As a side note on the Xen partitions topic, it’s worth mentioning that the self-update feature of the installer is always available for all YaST-based distributions. But, unlike SLE, openSUSE doesn’t offer an official self-update repository, implying the feature is effectively disabled by default in openSUSE Leap. Does it mean that if you want to install Leap on top of a Xen virtual partition you will have to wait for Leap 15.1 or switch to Tumbleweed? Not exactly.

If you really want to use the latest YaST features during the openSUSE Leap 15.0 installation process, there are a couple of ways to achieve it. For example, to install (or upgrade) using the Leap 15.0 Live images. The live images are refreshed once in a while, so they can contain an installer that is more up-to-date than the installer in the Leap 15.0 normal ISO. There are also ways to use the self-update feature with unofficial (and unsupported) repositories. For a summary of all the options, check this comment at Bugzilla. Users of SLE should not need any of these hacks, since there is an official repository for the installer self-update mechanism ensuring SLE15 can always be installed with updated version of all the crucial packages.

Did you think that services management were confined to the services manager? Of course no 🙂 As you may know, there are serveral YaST modules that allow our users to set up several services like DNS, DHCP, Samba, etc. All these modules offer a way to configure how and when those services should be started.

So as part of the effort to improve the services management experience, we have rolled out a new widget which offers some benefits:

Allows setting a service to be started On Demand.
Offers a consistent an unified interface accross all modules.
It is able to handle cases where several services are involved (like yast2-samba-server or yast2-iscsi-client).

By the way, we have adapted all these modules to use the new and shiny widget.

Better Handle Large File Systems in libyui

We fixed an issue with disks larger than 8EiB in the last sprint. However, the fix was intended for SLE12 and SLE15 maintenance update so we could not do big changes and we fixed only the most important parts.

For SLE15-SP1/Leap 15.1 and openSUSE Tumbleweed we can do more changes so we did some backward incompatible improvements.

Originally the size was implemented using long long data type which is a 64-bit signed integer (with the maximum value 8EiB). We switched to the Boost multiprecision C++ library which implements arbitrary precision integers. It works like the Integer class in Ruby which adds more bits to the data when needed.

Of course, it still depends on the limits in the underlying libzypp library which uses a 64-bit signed integer but with 1KiB unit, so the limit should be 8ZiB. With this change we are prepared even for more.

Additionally we added more units for converting to a string representation. Originally it used TiB units which resulted in too big numbers, now the EiB sizes are displayed using the EiB units as expected.

Moreover we added support for writing unit tests, evaluating the code coverage and reporting the it to coveralls.io. With this support we were able to write the very first unit test in libyui! The code coverage is now at the embarrassing 2% but we have just started!

Rubocop Check Speed Up

In the previous blog post we reported that we had improved running the unit tests in the yast2-storage-ng package. The speed up was based on parallelizing the execution and using all processors. This time we have improved the Rubocop check.

Normally Rubocop scans the directory for the files to check and then processes found files sequentially. And this might take very long time if there are hundreds of files to check.

Similarly as in the previous speed up we take advantage of the available processors and run multiple Rubocop instances in parallel. The implementation is a bit more complicated as Rubocop itself does not support parallel scan at all. But it is possible to evaluate the checked files, split them into the groups according to the number of processors and start a separate Rubocop instance for each group in parallel.

If you are interested in the details or you want to use parallel Rubocop also in your project then check the implementation in the yast-rake Ruby gem.

Of course, this improvement has an important impact in the yast2-storage-ng package where Rubocop needs to check over 600 files. Here you are the numbers:

Running Rubocop locally (with hyperthreading enabled):
- ~3.6x faster on an older quad core CPU (from 44s to 12s)
- ~6x faster on a new eight core CPU (from 35s to 6s)
At Travis: ~1.5x faster (from 69s to 47s), that’s the maximum possible because Travis has about 1.5x CPU build power

As you can see, for big projects the speed up is very good on local system and even at Travis it is still nice.

What’s next?

Sprint 61 is already running and the new storage layer and services management are again the areas where we are focusing an important part of our resources. Hopefully, in around two weeks, we will publish what we have achieved this time.

Stay tunned!

Posted in Factory, Systems Management, YaST | Comments Off on YaST Squad Sprint 59 & 60

YaST Squad Sprint 58

July 23rd, 2018 by Yast Team

Squads in the Team

In the previous post we explained the squads idea and said we would tell more in this report. Thus, we should mention that we finally did three squads for this sprint:

The Sockets & Services Squad working on supporting systemd sockets properly and other systemd related tasks (all in the YaST context, of course).
The Qt and UI Squad working on user interface things like adding a new view to the package selection to show packages managed by a service, and also some control center improvements.
The Bug Fighting Squad handling bugs that are coming in on a daily basis and in our backlog.

Fixed Issues with Disks Larger than 8EiB

It’s quite unlikely that you have at home a disk storage larger than 8EiB (eight exbibytes, 2⁶³). But in enterprise or cloud world it might be possible.

And it turned out that the YaST package manager does not handle such large disks well. At the start you would see this false error message:

The Problems

There are two problems:

There definitely is a lot of free space on the disk, the error telling the user the space is running out is simply lying.
The disk sizes are displayed as wrong negative values.

It turned out that the problem was caused by using the signed 64-bit integer data type which overflows for values bigger than 8EiB and the number becomes negative.

The Fix

We had to fix several places, each required some different solution.

Use unsigned 64-bit integers where possible, that obviously avoids overflow.
The numbers from libzypp use KiB units, at some places we need to convert that number to MiB. But first we converted to plain bytes (by multiplying by 1024) and then divide by 1MiB. And this first multiply step might cause overflow. Instead we simply convert KiB to MiB directly by dividing by 1024 without risk of overflow in the middle.
Use floating point double data type for converting the values to a human readable text or to percents. The double has wider range and in these cases we do not need exact precision so rounding in floating point operations does not matter.
Ignore a negative number in the free space check. At one place the value goes through the YaST component system which uses signed integer and this cannot be easily changed. In that case we consider negative free space as enough for installing any package, more than 8EiB free space should be enough for any package™.

There is still some minor issue with the large numbers. The highest supported unit is TiB so even very big numbers are displayed in TiB units as on the screenshot above. The fix is planned to be released as a maintenance update and this change would break the backward compatibility so we will improve it later but only for the future releases.

Testing

But the problem was how to test the behavior? You could fake some numbers in the code but for full testing or QA validation it would be nice to test on a real disk. But you usually do not have such a large storage for testing…

Fortunately in Linux it is possible to fake such large file system quite easily using sparse files and loop devices. Here is a short how to:

# create two big sparse files
truncate -s 6E /tmp/huge_file1
truncate -s 6E /tmp/huge_file2

# create block devices via loopback
losetup -f /tmp/huge_file1
losetup -f /tmp/huge_file2

# get the loop back device names, the names might be different
# if the system already uses some other loop back devices
losetup -a
/dev/loop1: [0056]:1171324 (/tmp/huge_file2)
/dev/loop0: [0056]:1171323 (/tmp/huge_file1)

# create a btrfs file system over both "disks"
mkfs.btrfs -K /dev/loop0 /dev/loop1

# mount it on /mnt2 (or whatever else, do no use /mnt, that is ignored by libzypp!)
mkdir /mnt2
mount /dev/loop0 /mnt2

# verify the size
df -h /mnt2
Filesystem      Size  Used Avail Use% Mounted on
/dev/loop0       12E   17M   12E   1% /mnt2
# voila! you have a 12EiB file system! enjoy 😉

Note: Obviously even if you have a 12EiB filesystem you cannot save there more data than in the real file system below (in /tmp in this case). If you try you will get write errors, there is no prepetuum mobile…

Speeding Up Unit Tests and Travis Builds in yast2-storage-ng

The new yast2-storage-ng package has a quite large set of unit tests. That’s good, it allows to have less buggy code and make sure the features work as expected.

On the other hand the drawback is that running the tests take too much time. If you have to wait for 3 or 4 minutes after any small change in the code then either you waste too much time or you do not run the tests at all. So we looked into speeding up the tests.

Running Tests in Parallel

The main problem was that all tests were executed sequentially one by one. Even if you have a multi CPU system only one processor was used. It turned out that using the parallel_test Ruby gem allows easily running the tests in parallel utilizing all available processors.

The only possible problem is that there must not be any dependencies or conflicts between the tests otherwise running them in parallel would fail. Fortunately there was only one small issue in the yast2-storage-ng tests and we could enable the parallel tests without much work.

Running Travis Jobs in Parallel

Also the Travis job took quite a lot of time. Running the tests in parallel helped a bit at Travis but still was not good enough.

Fortunately Travis allows running multiple jobs in parallel. Therefore we split the single CI job which runs the tests, builds the package, runs syntax check, etc… into three independent groups which can be started in parallel.

Documentation

If you are interested in details you might check our updated Travis documentation and the Parallel tests documentation. Or check the announcement on the YaST mailing list.

Results

Here are some real numbers to see the speedup:

Running the test suite locally (rake test:unit): from 2:44 to 0:38 (4.3x speed up on a quad core CPU with hyper-threading enabled)
Building the package locally (rake osc:build): from 137s to 49s (with cached RPM packages but includes chroot installation)
Package build in OBS: from 323s-505s to 102s-235s (it highly depends on the speed of the used worker)
Travis speed up: from 8-10 minutes to 3-4minutes (using both parallel Travis jobs and parallel tests)

This allows us to continue with adding even more tests into the package. :smiley:

What Packages are Provided by a Product Extension/Module?

In the Software Management module we have a Repositories view where you can see the packages grouped by the repository that provides them. But this is not really helpful if you want to see what is delivered with a product Extension or Module, because each product module is composed of several repositories: the originally released packages, the updates, the sources, the debuginfos.

Fortunately, the repositories for each product module are grouped together in a repository Service, and we have added a Services filter to Software Management.

Qt Service filter:

ncurses Service filter:

(Reference: https://fate.suse.com/320573)

Posted in Factory, Systems Management, YaST | Comments Off on YaST Squad Sprint 58

Update on YaST Development Status

July 5th, 2018 by Yast Team

Five weeks without blogging is certainly a quite an hiatus for the YaST Team. But fear no more, we are back! This is the first time in quite a while in which our post is not titled “Highlights of YaST Development Sprint” and there are good reasons for that.

Adapting the YaST Team Structure the Agile Way

Now that openSUSE Leap 15.0 is out and SUSE Enterprise Linux 15 is ready to be shipped, we felt it was time to rethink our activities. For the duration of the storage-ng development, we had split the YaST team into two sub-teams: Team S for Storage and Team R for the Rest. But now new challenges await us; there are some things that were pushed aside because getting storage-ng into an acceptable state had top priority.

We decided we’d try an approach that other development teams in SUSE have already been using successfully: split up the YaST team into “squads” of 3-5 people each for the duration of a couple of sprints. Each squad is centered around a big topic that needs to be addressed. There is no long-term fixed assignment of anyone to any squad; the idea is to shuffle people and thus know-how around as needed, of course taking each developer’s interests into account. So the squads and the topics will change every few weeks.

Is this the pure spirit of Scrum and the agile bible? We don’t know. And we don’t care. The agile spirit is to adapt your work based on what makes sense in every moment. We work the agile way, so the way of working also has to be agile.

The next sprint’s report will contain more information about the first set of squads and the results they are delivering. But meanwhile we have done much more than just reorganizing our forces. While the sprint-based work was suspended (thus the blog title not containing the word “sprint”), the YaST team still managed to put out of the door quite some features, improvements and bug fixes targeting mainly Tumbleweed.

Expert Partitioner: Moving Partitions

After quite some effort, the YaST team has completely rewritten the Expert Partitioner from scratch using the new storage stack (a.k.a. storage-ng). And although this new Expert Partitioner already offers practically all the same features than the old one, some last options are still coming. One them in the button for moving partitions, which saves us of a lot unnecessary work in many cases. For example, imagine you are installing openSUSE Tumbleweed and the installer automatically proposes you to create a partition for root and, just following it, a second partition for home. In case you don’t like the default proposed sizes (e.g. because you want a bigger root), you have to use the Expert Partitioner to fix the situation. You have to completely remove the home partition, resize root for enlarging it and then create home again with the same options than before.

Now, with the “Move” button, this kind of modifications are much easier. For that example, you can accomplish exactly the same by simply resizing home (without deleting it completely) and moving the resized home closer to the end of the disk (by using Move button). After moving the home partition, you have enough free space for enlarging the root partition. In the following screenshot you can see this dialog for moving partitions.

One important thing to take into account is that the movement of partitions is only possible for new partitions, that is, it is not possible to move partitions that already exist on disk.

YaST Masking Systemd Mount and Swap Units

And speaking about the Partitioner and its relationship with the rest of the system, the transition from SysVinit to Systemd changed the behavior of (open)SUSE concerning mounting devices. Systemd generates mount units for various file systems, e.g. those listed in /etc/fstab. The result is that Systemd may automatically mount any file system, even if that file system has been manually unmounted before. This can be problematic when the user needs the file system to be unmounted for certain operations, like resizing or unplugging.

Thus, now the Partitioner uses a new mechanism to prevent that to happen during its execution. Starting with version 4.0.194, the yast2-storage-ng package includes and uses the script /usr/lib/YaST2/bin/mask-systemd-units to mask all mount and swap units one by one. The script might also be useful for direct use of system administrators. So… profit!

Showing Logs the Systemd Way

And since we speak about how Systemd has changed the way the overall system works, it’s also worth noticing how more and more services has been adopting the Systemd journal for its logging purposes.

Some of the existing YaST modules to configure a given service include a button to show the logs of such service. In the past, they used to display the content of /var/log/messages with some basic filtering to ensure only the information relative to the service (e.g. tftp) was shown. But that didn’t work out of the box for services already using the Systemd journal, and we had gotten quite some bug reports about it.

Fortunately, the solution is really at our fingertips. You surely know by now that there is a YaST module for viewing the journal content with powerful queries for filtering, searching and so so on. The obvious solution is to use that YaST journal module also within other YaST modules, in order to show domain specific logs.

So far we adapted the YaST tftp module, but it will be easy to fix also other places that use the old approach that no longer works. And this is how it looks when you click the “Show Logs” button in the YaST module to configure tftp.

Usability Improvement in the Repositories Manager

The YaST repositories manager displays the repositories sorted by priority. But some people have a lot of repositories in their system and make no use of the priorities. Since there was not a clear second criteria, the order of the repository list looked quite arbitrary in those cases. Now all the repositories with the same priority are sorted by name, which makes more sense. See how it looked before the improvement.

And compare to how it looks now.

Handling Inconsistent Boot Methods During Upgrade

We got a rather interesting amount of bug reports for openSUSE Leap 15.0 about collisions between the grub2 and grub2-efi bootloaders during the upgrade process. The root cause was that the installation medium used a different booting mode than the installed system being upgraded. For example, the installed system uses EFI boot but the upgrade is executed from a DVD booted via legacy mode (i.e. disabling EFI). In that case, the kernel running from the DVD does not expose some devices that are needed to write to the EFI boot manager. Moreover, it causes troubles to the updater itself, which does not expect this situation.

Looking at the majority of the bug reports, it is obvious that in most cases it happens by accident rather than the user consciously trying to mix both boot modes. So to improve the user experience we added a warning that will be displayed when this situation is detected, before starting the upgrade. That gives the user the possibility to fix the problem or to continue if the situation is really intentional.

Below you can see how it looks, both in graphical and text mode, in a patched openSUSE Leap 15.0 installation media, since the feature was developed too late to be included in the official installation images.

What’s Next? Hack Week!

As commented at the beginning of the post, we have restarted the sprint-based work, although with a little twist to try out the squads approach. But before we come back to you to show the results of the first squad-based sprint, we have something else to do – Hack Week 17!.

Again it’s the time of the year for all SUSE Engineers (and any Open Source enthusiast willing to join) to innovate and learn new stuff. So please forgive us if we go too deep into playing and we are less responsive next week. See you again soon!

Posted in Distribution, Factory, Miscellaneous, Programming, Systems Management, YaST | 2 Comments »

Highlights of YaST Development Sprint 57

May 31st, 2018 by Yast Team

Three weeks from our last update on this blog. Time flies when you are busy! As you know, openSUSE Leap 15.0 was released in the meantime, which also means the active development of SLE15 is coming to an end… so time to look a little bit further into the future.

That’s why we had a face-to-face workshop with the whole YaST Team at the beautiful city of Prague during several days right before joining the openSUSE Conference 2018.

But we have done much more in three weeks than attending workshops and conferences. Apart from last-minute fixes, here you have a list of some interesting changes we have done in YaST in this period. Take into account that some of these changes didn’t make it into Leap 15.0, although all will be available in SLES15 and are probably already integrated into openSUSE Tumbleweed.

Fine tuning installer behavior in small disks

As you may know, the default installation of SLE and both openSUSE distribution enables Btrfs snapshots in the root partition alongside separate partitions for /home and swap. That means a default installation needs quite some space. In SLE12 and openSUSE Leap 42.X, if such disk space was not there the installer silently tries to disable the separate /home and even the snapshots in order to be able to create an initial proposal.

That behavior has become configurable for each product and role with Storage-ng and during the last sprint there was some controversy about what the configuration should be, both for openSUSE and the SLE family. It may look like a minor problem, but it becomes very relevant in virtualization environment (where virtual disks smaller than 10 GiB are not uncommon) or certain architectures with special storage devices like s390 and ARM.

The final decision was to never disable snapshots automatically in the case of openSUSE, so the user will be forced to manually go through the Guided Setup and explicitly disable snapshots to install in a small disk. In the SLE case, it was decided to keep the traditional behavior (automatically disabling snapshots if really needed) but making the situation more visible by adding a previous sentence to explain how the initial proposal was calculated.

So the installation in a normal disk would look like this.

While the installation in a very small disk displays some information similar to the following screen (the wording was slightly improved after taking the screenshots).

The explanatory text preceding the list of actions will be available in all products based on SLE15, but will not be there for Leap 15.0, since the modification to the installer was not ready on time for the deadline and, moreover, would have been impossible to get the translations on time.

By the way, if you are interested in a more in-depth explanation on how the partitioning proposal adapts to all kind of situations like small disks and other scenarios, don’t hesitate to check Iván’s presentation at openSUSE Conference 2018 detailing its internals.

More parameter passing for s390

And talking about uncommon scenarios and the s390 architecture, you may remember that in the latest sprint we improved the handling of the persistent network device names kernel parameter for such systems. Shortly after, we found out a similar improvement was needed also for the FIPS parameter.

FIPS is a military encryption standard in USA. If the installation is started using the corresponding parameter, YaST will enforce strong encryption and will install an specific FIPS pattern. Moreover, after the recent fix, a system installed in hardened mode s390 will continue operating in this mode after the installation.

Fun with MD RAIDs

As SLE15 comes closer, future users start testing the system with more exotic and complex hardware setups. Same applies to openSUSE Leap 15.0 right after the official release. As a result of all that testing, we found several scenarios in which Storage-ng got confused about MD RAIDs defined by some specific hardware or manually by the user before starting the installation.

By default, the old storage didn’t handle partitions within software RAIDs and it didn’t handle software RAIDs directly on top of full disks (with no partitions in the physical disks). For the first version of Storage-ng present in Leap 15.0 and SLE15, we tried to implement the same behavior with the intention to rethink the whole thing and open new possibilities in the close future. Check more about the present and future of Storage-ng in Ancor’s talk at openSUSE Conference 2018.

Unfortunately, while trying to replicate the old storage behavior with software-defined MD RAIDs, we overlooked some heuristic that was hidden in the old implementation to recognize some special setups in which a given RAID device currently detected as regular software-defined RAIDs should be treated like hardware RAIDs. That’s the case of Software RAID Virtual Disks defined on a S130/S140 controller on DellEMC PowerEdge Servers through the BIOS Interface. We also found that some users used to produce a similar situation by manually creating software MD RAIDs and creating partitions within them before starting the installation.

With the preparation of SLE15 already in the final stages and with openSUSE Leap 15 already out, it was too late to introduce drastic changes in how MD RAIDs are detected and used. To mitigate the problem while limiting the potential breakage, we reintroduced an ancient installer parameter. Now, when we run the installer using LIBSTORAGE_MDPART=1, all existing software-defined RAIDs will be considered as BIOS RAIDs.

The new parameter is not available in Leap 15.0 (we added it too late) and will hopefully not be necessary anymore in future versions of SLE and openSUSE, since the short term plan is to redesign everything about how MD RAIDs are handled during installation.

And even more fun with MD RAIDs

Another example of RAID that looks like defined by software but is indeed assembled by BIOS is the Intel RSTe technology. In this case, the usage of LIBSTORAGE_MDPART is not needed, but still we found the bootloader installation to be broken because YaST was once again getting confused by the mixed RAID setup.

Fortunately it was possible to fix the issue and verify the solution in only two days, despite the YaST Team not having direct access to the hardware, thanks to the outstanding help of the user reporting the bug. Connecting users and developers directly always produces great results… and that’s one of the reasons open source rocks so much!

Improved error reporting for wrong bootloader in AutoYaST

That was not the only improvement in the bootloader handling done during this sprint. We also invested some time improving the user experience in AutoYAST, since the error message displayed when using an EFI variant not supported in the system architecture was far from being useful or even informative.

So alongside a more clear message, AutoYaST will now list all the possible values supported on the given architecture to better guide the user.

Setting the default subvolume name in AutoYaST

AutoYaST also received improvements in other areas, like making use of the new possibilities offered by Storage-ng. The new storage layer allows the user to set different default subvolumes (or none at all) for every Btrfs file system. As shown in the example below, a prefix name can be specified for each partition using the subvolumes_prefix.

<partition>
  <mount>/</mount>
  <filesystem config:type="symbol">btrfs</filesystem>
  <size>max</size>
  <subvolumes_prefix>@</subvolumes_prefix>
</partition>

To omit the subvolume prefix, set the subvolumes_prefix tag:

<partition>
  <mount>/</mount>
  <filesystem config:type="symbol">btrfs</filesystem>
  <size>max</size>
  <subvolumes_prefix><![CDATA[]]></subvolumes_prefix>
</partition>

As a consequence of the new behaviour, the old btrfs_set_default_subvolume_name tag is not needed and, therefore, it is not supported in Leap 15.0 and SLE15.

Skipping Btrfs subvolume creation

And more changes in AutoYaST that arrived just in time for SLE15 and openSUSE Leap 15.0. Recently, we have introduced a new flag in AutoYaST partition sections to skip the creation of Btrfs subvolumes because, due to a known limitation of our XML parser, it is not possible to specify an empty list.

So from now on, setting create_subvolumes to false will prevent AutoYaST from creating any Btrfs subvolumes in a given partition.

<partition>
  <mount>/</mount>
  <filesystem config:type="symbol">btrfs</filesystem>
  <size>max</size>
  <create_subvolumes config:type="boolean">false</create_subvolumes>
</partition>

Keep it rolling!

As usual, the content of this post is just a small part of everything we did during the sprint. There were also many other fixes and improvements, from auto-repairing wrong partition tables (with different sizes than the underlying disk) during installation to better interaction with other components like udisk or mdadm auto-assembling and many other things in between.

But it’s time to go back to work and start implementing all the new ideas that emerged from the YaST Team Workshop and the openSUSE Conference. See you in the next report!

Posted in Distribution, Events, Factory, Miscellaneous, Programming, Systems Management, YaST | Comments Off on Highlights of YaST Development Sprint 57

Highlights of YaST Development Sprint 56

May 8th, 2018 by Yast Team

LEAP/SLE 15 is getting more stable and closer to be released, but to keep this process flowing, our team of bug killers is having a lot of work to do!

This last sprint we had several fixes for really special scenarios. The kind of problems that you can find once ~~most of~~ things are working fine! So let’s take a look at some of these cases and how we’re working to stabilize this upcoming release.

Keep predictable network devices settings on S390x

A not well-known feature in YaST is that many specific boot parameters for installation are also used on the target system. However, this approach has one exception: the S390 mainframe. In this case, many installation specific parameters should not go to the target system and, therefore, we ignore all installation parameter for this system.
In the last sprint, we worked on a bug, which reported that at least systemd predictable names for network devices should be also used for S390 systems, otherwise the configuration done during the installation won’t be valid in a running system as network names will differ. So, from SLE15 we start to keep the settings of predictable network names for S390 systems.

Fun with console configuration of GRUB2

Another report that helped us to learn about other not well-known features was the one reporting that bootloader module does not support multiple console outputs of GRUB2. After digging into some code, we found out that YaST bootloader takes only native terminal, gfxterm or serial console in consideration, but not a mix of them.
Once we looked at the manual of GRUB2, we learned that it supports some funny outputs such as morse code, PC beeper or simple data protocol using system speaker. Of course, YaST2 bootloader does not support all these options and when it gets one of them, it is treated as an unexpected value and bootloader fails.

As we are really close to Leap/SLE 15 release, we want to avoid big changes in the system. So we decided to handle this issue by showing a popup, which informs that the configuration contains an unexpected value and asks if the whole proposed configuration should be proposed again or if YaST should quit and let the user edit it manually.

If you are curious about how it looks like:

For Leap 15.1 / SLE 15 SP1 we plan to extend the values that we support to provide a nicer experience for the user.

Bootloader configuration during upgrade

Another reported issue in bootloader was also solved this last sprint. When upgrading from Leap 42/SLE 12 to Leap/SLE 15, if the user clicks on booting on the proposal, the system crashes. The reason is that usually on openSUSE 13.2/SLE 11 it needs to repropose bootloader during the upgrade. This is no longer required for the latest upgrade and, therefore, YaST does not expect that the user will click on it. We would like to remove this option completely, but YaST still support upgrade from SLE11 to SLE15, so we still need it there. In the end, the solution is to show a popup informing the user that the modification of bootloader is not supported during upgrade.

In short, take a look at the screenshot:

Fixing kdump on Xen

We got a report about kdump breaking when it is used in Xen. To explain the problem, we need to go back to how we configure a parameter and the reasons we implemented it in this way: In current versions (before this fix) when a user wants to use kdump, we configure the crashkernel kernel parameter for all targets, for the common kernel, Xen PV0 domain and also Xen guests. This approach worked very well in the past because traditional xenlinux ignores crashkernel for PV0 and just pass it to Xen VMs. However, the current pvops implementation of Xen no longer ignores this parameter and consequently, it results in breaking the Xen virtualization. The solution for this issue was pretty simple: YaST stopped to propose using crashkernel for Xen PV0 and everything works again. This is a perfect example to show how to understand the issue, sometimes, takes much more time than to fix it!

Improving the upgrade from SLE11/12 to SLE15

We are still improving the migration from SLE11 or SLE12 to SLE15 and this sprint we were focused on the automated registration upgrade using AutoYaST. If you are not familiar with the autoupgrade feature you can find more details in the documentation.

We already supported manual registration upgrade from the old products, but the automated way was still not adapted to the new SUSE Customer Center (SCC) API and it did not work correctly. This sprint we have adapted the registration upgrade code to correctly work in the interactive mode and also in the automatic upgrade.

The code was adapted to skip the user interaction and do everything manually when running in the autoupgrade mode. The only problematic part was how to handle multiple migration targets, which in the interactive upgrade we ask the user to choose one. To have a simple solution we decided to take the first migration, later (SP1) we might allow configuring this as well. But as now there is only one migration possible anyway, this looks like a good enough solution.

Falling back to the guided proposal

During this sprint, we were informed that AutoYaST was unable to display a proper error message when no partitioning section was specified and there was not enough disk space. The bug was rather easy to solve, but we wanted to take the opportunity to highlight how AutoYaST works when the partitioning section is missing from the profile.

In the past, AutoYaST implemented its own logic, different from the one used during a normal installation. Fortunately, as part of the adaptation to the new storage layer, AutoYaST relies now on the same code than the regular installation in order to propose a partitioning layout when the partitioning section is not specified. What is more, you can override some values which are defined in the product’s control file by setting them in the general/storage section from the AutoYaST profile.

Leap /SLE 15 is closed, but Tumbleweed is still rolling

We are really close to release Leap/SLE 15 and we are more focused on minimal changes that fix only critical stuff. On the other hand, Tumbleweed users are looking always for the latest and greatest features. In order to satisfy both groups, YaST separated Leap 15.1/SLE 15 and Tumbleweed in two different git branches. In this way, we can easily start adding new features, bug fixes and other improvements for Tumbleweed while we keep SLE15 stabilized. Besides that, there is another planned Service Pack for SLE12, and once we start to work at it, we’ll also create a new separated branch to include these changes. We also adapted all related infrastructure around the branches, such as CI, docker testing images, among others.

This way, we are able to allow you to enjoy the stable Leap 15 or the latest and hottest Tumbleweed.

Conclusion

We’re now working on our last sprint before the openSUSE Conference 2018. In two weeks we’ll come back with the highlights of Sprint 57 and until there we hope that you have already everything planned to enjoy the conference that will occur in Prague this year (we hope that you enjoy the city too). We’re looking forward to seeing you there!

Posted in Distribution, Factory, Localization, Systems Management, YaST | Comments Off on Highlights of YaST Development Sprint 56

Highlights of YaST Development Sprint 55

April 24th, 2018 by Yast Team

Time flies. We are almost in May and the openSUSE Conference ’18 is around the corner. So after booking your flights (if you need to) and your acommodation, you might want to know what happened in the YaST world during the Development Sprint 55th.

The YaST team is currently polishing the upcoming release, introducing some improvements and fixes. There are no breaking changes but still we have a lot of things to blog about.

Updating NFS Version Handling

Once upon a time, back in 2008 to be precise, the Large Hadron Collider (LHC) was finally ready, Raúl Castro replaced Fidel as President of Cuba, the TV show Phineas and Ferb was previewed… and yast2-nfs-client added support to configure NFSv4 mounts. Back then, the proper way of doing that was using “nfs4” as type for mounting the NFS share, i.e. writing “nfs4” in the vfstype column of the /etc/fstab file. Some time later, NFS4.1 (also known as pNFS) came out, and a new mount option “minorversion=1” was added. Very soon it was clear that such solution was not scaling and was not the way to go.

So at some point “nfs4” was deprecated as acceptable value for vfstype and “minorversion” was ditched in favor of “nfsvers”. Since the old deprecated way of doing things was still working, yast2-nfs-client was never updated to reflect this. But starting with the upcoming Leap 15 and SLE 15, some things will change in NFSland (in fact, the change landed in openSUSE Tumbleweed some time ago already). The type “nfs4” will be considered identical to “nfs” and “minorversion” will be completely ignored, so your old NFS mounts may not work as you expect them to do it. Time to refresh yast2-nfs-client!

During this sprint, yast2-nfs-client was not only fixed internally to produce valid entries in /etc/fstab, it also got a slightly revamped form to create and edit NFS mounts that should be less confusing than the old one and also more explanatory about how NFS versioning really works when defining a mount.

To ensure our users don’t get fooled by old entries that seems to be enforcing a particular NFS version (because they use “nfs4” as mount type, for example), but are in fact not doing it due to the new behavior in SLE 15 and openSUSE 15, yast2-nfs-client is now able to detect such circumstance, mark such entries in the list and offer a safe migration path to users.

As you can infer from the screenshot above, all these improvements are available when yast2-nfs-client runs standalone, as well as when it runs embedded within the YaST Partitioner. Enjoy!

Fixing Broken Translations

Recently we got some bug reports about YaST crashing at some points when running in some specific locales. It turned out that the problem was caused by broken translations.

A lot of translated texts contain placeholders like %s, %{text} or %1. These tags are replaced by the real values by YaST. But that requires that the translated text contains the same tags. If they are missing the value will not be included and, what is even worst, if they are invalid the Ruby interpreter throws an exception which means YaST aborts making our users unhappy. And that’s really bad, right?

Unfortunately the Ruby gettext does not support format tags and the GNU gettext does not support Ruby at all. As a quick solution we wrote a script which checks whether all tags are included in the translated text and reports broken translations.

The script found about 160 broken translations. The most common problems were usually just typos (s% instead of %s, {%foo} instead of %{foo}, or extra space in %␣1). But some cases were not that trivial. Translators by mistake also used the Unicode ٪ instead of the ASCII % or even translated the tags, which must stay untouched (%{مساعدة}).

Some translations were obviously wrong or even contained the original English texts – we removed them. In some cases the tags were wrong but we were not sure whether the whole translation is valid. In that case instead of fixing the tags we removed the translated text completely. It is better to ask the translators for translating again than have a completely invalid translation.

In the future we plan to improve these checks, so the tags are properly handled by Ruby and/or GNU gettext directly and we do not need a separate script for that.

Installing Over VNC Using the Browser

You are surely accustomed to remote administration using SSH. And, as you may know, the (open)SUSE installation can be done over SSH too. But, additionally, YaST also have support for installing over VNC.

When using VNC for installation, you can choose between using a native VNC viewer or a web browser based one. The cool thing about the second option, is that you can follow the installation just pointing your browser to http://IP-ADDRESS:5801.

Until now, YaST was using a Java applet based implementation, which is no longer supported in browsers. But during this sprint, we have completed the switch to a JavaScript based solution.

Unfortunately, that has resulted in losing an encryption layer: the HTTP connection on port 5801 is unencrypted, but the typical VNC port (5901) continues to be encrypted.

Asking Once About Equivalent Licenses

After splitting SUSE Linux Enterprise in several modules, it was pretty common that the user had to accept a couple of equivalent licenses during the installation process. Given that the content for those licenses was pretty much the same, it was quite confusing. Actually, we got a bug report about the installation process being stuck asking the user to accept the license over and over (it was just the same license being shown for different modules).

In order to make our users happy, YaST is now able to decide whether two licenses are the same and, in that case, it will only ask once for acceptance. For the time being, YaST applies a hash function to license contents and compare the result, but most likely this mechanism will be refined in the future.

License Confirmation in CaaSP 3.0

And talking about licenses, another small change about how they are handled was introduced in CaaSP 3.0. As you know, CaaSP features a One Dialog Installer and there was no room for the license to be shown. Now, before proceeding with the installation, YaST will show the license in the confirmation screen if needed.

Improving the `addon` Boot Option Handling

Back in February, we improved the addon boot option to handle the SUSE Linux Packages DVD properly. However, during testing, we found out that if you are using a system which only has one DVD drive, the installation DVD will be automatically used as an addon.

In order to fix this conflict, if the installation media and the Packages DVD are going to use the same drive, YaST will ask the user to change the DVD before using it as an addon.

Additionally, we improved the documentation of the addon boot option adding new examples to clarify how the dvd:/// URLs are handled.

Echoes of Winter: White Text on a White Background

These days we fixed a bug that only allowed clairvoyant users to finish the installation of openSUSE Kubic.

The bug is pretty unremarkable but may we draw your attention to the related CSS styling engine? It powers the high-contrast color mode that you can select with F3 or with Y2STYLE:

and if you press Ctrl-Alt-Shift-S (for style) you can change the styling on the fly, as in this example of changing the background color:

Conclusions

openSUSE Leap 15.0 release is approaching and, as usual, we need help from our dear users to give testing versions a try and report bugs. Thanks in advance!

Posted in Distribution, Factory, Localization, Systems Management, YaST | Comments Off on Highlights of YaST Development Sprint 55

Highlights of YaST Development Sprint 54

April 11th, 2018 by Yast Team

We were in the middle of ~~rewriting~~ no, ~~refactoring~~ recompiling all of YaST into Visual Basic when we found that it was April 2nd already and had to scratch the entire project. Next year for sure. So you are left with a report of enterprise grade stabilization and we hope that your servers will be very bored running our software.

Installation and Upgrade

Clearer Description of Migration Targets

Life goes through various roads and it is same for SLE life. SLE15 is now split into multiple modules and during the upgrade it can be quite complex to pick the desired upgrade target. We have to react to this issue as customers start complaining that the upgrade overview starts to be hard to understand and we should improve it. So we did it and now you can check the changes on the attached screenshots. We modified the overview label from listing all products to just a summary with the details displayed below as it was before. Be aware that in the future and for some products or extensions/modules more migration targets will be possible.

Old screenshot:

and the new one (for a slightly different system, so it is not an exact match for the previous screenshot):

Importing the SMT Server SSL Certificate at Upgrade

We are still improving and fixing bugs in the migration from the SLE11 or SLE12 products to the new SLE15 line. One issue we fixed this sprint was importing the SSL server certificate from the old system at upgrade.

For registration you can use a local SMT server (Subscription Management Tool) instead of the usual SCC server (SUSE Customer Center).

The SMT servers usually use a self-signed SSL certificate to save some money for buying a real certificate signed by a well-known certificate authority. This self-signed certificate is imported to the system by YaST during the initial registration so the registration process and the repositories from the server can be properly accessed.

But during the offline upgrade to SLE15 the old system is not running, the installer runs from the installation medium. In that case we need to import the SSL certificate from the old system to the installer so it can properly access the registration server and do the upgrade.

The certificate import is quite easy, we just need to be careful as SLE11 uses a different (old) path for storing the imported certificates than in SLE12 or SLE15.

As the result you should be now able not only to upgrade the systems registered against the SCC server but also the systems registered against your local SMT server.

Many System Roles

Various products that we’re able to install have grown so many groups of presets, called System Roles, that they no longer fit on the screen. We applied some dark gray magic to make them fit in a scrollable box, at the expense of losing the keyboard shortcuts, sorry.

Storage

Better Message for Multipath (and other) Problems

While scanning the storage hardware, or at a later stage while manipulating it, there is always a chance of finding problems in the system that make it very hard to continue with the installation or the execution of YaST. In that case, previous versions of storage-ng used to show you a pop-up message with some technical details about what went wrong (for example, the command that failed and its output) and with options to abort YaST or continue despite the error.

But we found that for some situations we could do better in trying to understand what went wrong and explain it to you, instead of directly showing those raw technical details. One clear example is finding the same LVM physical volume twice, something that should never happen. Apart from double vision problems (libstorage-ng doesn’t drink alcohol), the most likely cause is that a multipath system is not being correctly detected and thus every one of the connections to the disk is being detected as a different disk, duplicating the content in the eyes of YaST.

Now such a circumstance is detected and explained to you, advising to use LIBSTORAGE_MULTIPATH_AUTOSTART (see linuxrc documentation) or the corresponding entry in the AutoYaST profile if it has not been used. By the way, during this sprint we also instructed storage-ng about LIBSTORAGE_MULTIPATH_AUTOSTART, since it used to ignore that ancient libstorage modifier.

The technical details are still available under the "Details" button, as you can see below. They are simply not displayed at first sight, which should make the whole experience less daunting for less-experienced users. That change applies to all the severe errors found during the three critical phases of storage-ng: hardware activation, system probing, and commit (when the partitions and other devices are created).

Of course, the new pop-up messages have full support for AutoYaST. The most appropriate default option (continue or abort) is automatically selected depending on which one of the mentioned phases is being executed and, if AutoYaST is configured to display pop-ups, the usual countdown is displayed before doing such selection. See below the new generic error (for a different, unidentified problem) in action in AutoYaST.

AutoYaST is now Able to Reuse Encrypted Devices

As you may know, AutoYaST is quite flexible when it comes to partitioning, so we are still writing the final bits of the adaptation with the new storage layer. And this time, we were working on teaching AutoYaST how to reuse encrypted devices properly.

However, the implementation was not that straightforward, as the hardware probing occurs even before the partitioning section of the profile has been analyzed. And, in some scenarios, it is not clear which key should be used to unlock a device (for instance, this can happen when more than one encryption key is defined). To solve this problem, AutoYaST will try all defined keys on all encrypted devices until a working key is found.

Of course, this behavior is properly documented now in the AutoYaST handbook.

Miscellaneous

Fixed AutoYaST profiles validation issues.

In our previous blog entry we already mentioned that there are significant changes between SLE12 and SLE15 profiles which have been documented in this appendix.

It is very common to adapt the profiles by hand which is error-prone and sometimes it is also hard to identify where the errors are just running an installation and looking deeply into the logs. That is why profiles validation using xmllint or jing is recommended (more info here).

During this sprint we have fixed some errors with the cloned profiles after installation which were not validating.

Translation Issues

We are receiving quite a lot of bugs regarding the translations. The usual problem is that some text is not translated at all and the original English text is displayed. This sprint we fixed several issues in this area, two of them are worth sharing in the blog.

The XSL File Format

The first problem was reported for missing translations in the role descriptions in the SLES4SAP product. The SLES4SAP installation basically behaves like the standard SLES installation just with changed few defaults. To avoid the duplication and make the SLES4SAP maintenance easier we simply take the original SLES XML control file, which describes the installer behavior and the defaults, and change just few values using a XSL transformation into the resulting SLES4SAP installer control file.

It turned out that the roles with missing translations were located in that XSL file. And unfortunately YaST did not support extracting the translatable strings from XSL files. However, we support translations in XML files and because a XSL file is actually a valid XML file we could easily extend the translation support in YaST to also cover the XSL files. So now the SLES4SAP roles are correctly translated.

Missing `textdomain` Call

We fixed several bugs with missing translations which were caused by missing textdomain call in the code. This call defines which POT file should be loaded and searched for the translations. If the YaST code does not use this call then obviously no text can be translated as YaST does not know which POT file should be used and it silently used the original untranslated text.

That means it was quite difficult to find why some text was not translated. And because that was quite common bug we had a nice idea to improve the situation by logging a warning into the YaST log with the exact message which could not be translated. And more importantly the log now also contains the location of the code which was trying to use the translation wrongly. See the pull request for more details.

With the openQA team we discussed also the possibility to add a new check to openQA which would scan the YaST log for this particular warning and report a problem. Which means we should not overlook this quite important warning in the future.

Posted in Factory, Systems Management, YaST | 1 Comment »

Highlights of YaST Development Sprint 53

March 23rd, 2018 by Yast Team

As the release dates for SUSE Linux Enterprise 15 and openSUSE Leap 15 approach, we keep adapting YaST to make easier for our users to take advantage of all the new features that these rock-solid operating systems will bring.

During the last two weeks that has implied, apart from regular bug fixing that we usually don’t cover here, working on AutoYaST, improving Storage-ng and polishing several aspects related to modules and extensions, like their registration and licenses.

Let’s start with the rewritten Partitioner that is part of yast2-storage-ng.

Partitioner: more flexibility with the partition id

Setting the right partition id (also known as partition type) for each partition is an important part of the system setup that is often overlooked. Our Partitioner has always displayed in a prominent place the widget allowing to set that id, suggesting always the best value based on the selected role and the chosen file system type. But in many cases, that was more than a simple suggestion. In the old Partitioner (and in the new one until this sprint) the value of the partition id field (Linux, swap, Linux LVM, etc.) could only be manually edited in case the user had selected to not format the partition. When the option “Format device” was selected, the automatically chosen value could not be changed.

In SLE15 and openSUSE Leap 15 (and quite soon in openSUSE Tumbleweed), it will be possible to modify the id, no matter if the partition is going to be formatted or not. Of course, the logic to propose the best option every time the user selects a file system type is still there, but now it can be always overridden if the user wish. That change resulted in a small rearrangement of the widgets in that screen, as you can see below (remember we are trying to be very conservative with the UI changes in the Partitioner).

Partitioner: better support for DASD

In our previous report we explained some of the aspects in which the Direct-access storage devices (DASD) used in s390 mainframes are different from regular hard disks. But as you can imagine, there are more differences… and we know our readers love to learn new stuff while enjoying our reports. 😉

In short, there are two possible kinds of DASDs devices: Extended Count Key Data (ECKD) and Fixed Block Architecture (FBA). As explained in the previous report, the ECKD devices need to be formatted at low-level in order to be used by the operating system and, moreover, there are two possible low-formats for them: Compatible Disk Layout (CDL) and Linux Disk Layout (LDL).

And now the fun – ECKD devices formatted as LDL do NOT have a partition table. FBA devices can potentially have one, but it’s also often skipped. To manage those DASDs without partition table, the Linux kernel simulates an implicit single partition taking the whole disk. Of course, working with such implicit partitions implies some restrictions, and we have introduced several controls to make sure things stay under control in the storage-ng Partitioner. For example, an error message is now shown if the user tries to remove an implicit partition.

For curious readers, there is more information about DASD available in this link.

Partitioner: can’t resize a partition… but why?

In SLE15 and openSUSE Leap 15 we will report very detailed reasons why a partition or a file system cannot be resized, as you can see in this screenshot.

This used to be just a very simplistic message “Device cannot be resized”. But there may be many reasons for that, and sometimes different restrictions might contradict each other: While some type of file system only lets you grow, not shrink (e.g. XFS), the partition that the file system is on might not be able to grow, for example because there is another partition right next to it. We want to minimize user frustration that might happen when we only report the first reason, and when the user somehow managed to fix that problem, show another one that can’t be fixed.

As usual, this feature will be available in Tumbleweed in a matter of days.

Handling registration rollback in SLE15 Migration

Of course, the Partitioner was not the only YaST area to get attention during this sprint. Several aspects related to products, modules and extensions were also worked, with all the implications they have about registration, migration and licenses.

For the offline migration to SLE15 we reused some parts from the online migration which handles service pack upgrade. But it tuned out that the reused part was not correctly integrated into the installer and in some corner cases (registration errors) it did not behave correctly.

Moreover if the upgrade failed early then the system still contained a SLE12 installation but was registered as a SLE15 system on the SCC server. After booting the original SLE12 system the access to the online repositories was broken.

This sprint we fixed that so in case of registration error or when going back the original registration is restored. Now you can go back and choose a different system to upgrade and it will work as expected.

Additionally we fixed some small issues with custom repositories (add-on or driver updates) used at upgrade.

More fun with hiding/showing beta versions in SLE15

Usual readers of our blog already know that SUSE is taking extensions and modules to a whole new level in SLE15, making them a cornerstone of the system installation and upgrade process. As already explained in previous posts, that implies more complex dependencies between extensions and modules. All those mechanisms usually work nice… except a small problem we found out with beta versions.

If a given extension was in beta phase and some of its dependencies were also in beta, if the “Hide Beta Versions” checkbox was unchecked the system was displaying only the extension selected by the user, but not the auto-selected dependent beta extensions. Our SLE testers found that quite confusing. So to make everyone’s life easier, we fixed the behavior as shown in the following screenshot.

A look into the future: analyzing how we display licenses

Currently there are many different ways to handle and display licenses. That can happen during the installation or upgrade process, while adding additional products to an installed system and, last but not least, while using YaST2 Firstboot to perform additional installation steps on the first system execution.

Additional there are 3 different locations from which these licenses come from. They can be provided by the SUSE Customer Center, be provided by libzypp or come from a repository using a legacy approach.

To simplify and unify all that in a close future, the first step was researching all those possibilities and how they are handled in (Auto)YaST. The result of such research can be found in this document hosted on Github.

AutoYaST product selection and installer update improvements

As you probably already know, starting with SLE-15, all products are distributed using one medium and you need to choose explicitly which product to install. Of course, if the medium only contains one product that would not be needed.

In AutoYaST profile the product is selected using the /software/products/product XML node:

<software>
  <products config:type="list">
    <product>SLED</product>
  </products>
</software>

Due to a bug, the cloned system exported the product short_name instead of the name, resulting in an internal error reported by the installer update and a later error during the auto-installation which aborted it because no product was selected.

So, during this sprint we have made improvements for both scenarios.

The installer update will not rely in the product selection at all (the installer is the same for all the products) but will use the self_update_id from the control file and the version and architecture from the first product available on the media. The installer update documentation has been also updated according the last changes and it is probably the best place for knowing more about its behavior.
The wrong product selection error reported was not very useful and it was decided to provide more information about the list of available products from the media. Just see the image below with the latest implementation:

Document main differences in AutoYaST profiles between SLE12 and SLE15

The need to select a product is not the only relevant change affecting AutoYaST profiles for SLE15. There are many other significant changes in SLE15 compared to SLE12. Like the new modules concept, replacing SuSEfirewall2 with firewalld, replacing ntp with Chrony… Users wanting to reuse existing SLE12 profiles with SLE-15, will probably need to adjust them.

We have created this summary describing some of the most important changes in order to help with the conversion.

That document is just a preliminary and temporary work that is currently being reviewed and improved by the awesome documentation team at SUSE. Very soon (probably already done at the time you are reading this) the content will be merged and a new section titled “Main differences between SLES 12 and 15 profiles” will be available in the current guide for AutoYaST. Have we ever mentioned how much the doc team rocks? So please, use that last link as final reference instead of our temporary summary.

Cron config for NTP client

It is possible to setup the YaST-ntp-client module to sync the system clock at regular intervals. If that feature is used, YaST writes the needed configuration to a cron.d config file. We were still using “novell” as part of the name of such file, which was reported as a bug. It turned to be a good opportunity to take a look to a module that, as you can guess from that bug, we don’t update very often. 😉

First of all, we made sure that newly written files will have a more up-to-date name. Straightforward and easy.

The second part was to provide an upgrade path if the file already existed. We integrated that with the existing ntp to chrony conversion. That means the existing configuration is updated when a new version of the yast2-ntp-client package is installed, so the user does not need to run the module again to start using chrony with an existing configuration.

Last but not least, the third part was to adapt the package to be a better citizen in the RPM world, marking that file as ghost file in RPM spec. Now this command can recognize that yast2-ntp-client is responsible for that configuration file.

  rpm -qf <file>

Two months… and counting

Only two months of countdown until the release date of openSUSE Leap 15! That means a lot of hard work ahead of us, so stay tuned for more updates.

Posted in Distribution, Factory, Miscellaneous, Programming, Systems Management, YaST | Comments Off on Highlights of YaST Development Sprint 53

Highlights of YaST Development Sprint 49

January 25th, 2018 by Yast Team

Time goes by and the YaST wheel keeps rolling. So let’s take a look to what have moved since our previous development report.

More flexible NET installation ISOs

Network installation media for Tumbleweed or Leap only work properly with the exact repository they have been built for – which for Tumbleweed may mean they could be outdated after just one day.

You would then run into this message:

To improve the situation the installer can now offer to download matching boot files (kernel and initrd, to be precise) from the repository if it detects this situation:

Of course, you can say ‘No’ here – but then you’re back to the red dialog. 😀

Technically, what’s done is to download a new kernel/initrd pair from the repository and restart the installation process with them (using kexec). So be prepared for a slight déjà vu.

This feature is controlled by the kexec boot option.

Storage-ng lands into Tumbleweed: handle with care

But that’s not the only news we have about openSUSE Tumbleweed. Our usual readers already know about Storage-ng, our effort to rewrite the whole YaST storage stack from scratch. And they also know it’s still a work in progress. But since there were too many valuable changes blocked by the adoption of Storage-ng, it was decided it was time to push the red button. So we are glad to announce the Storage-ng era has started with its inclusion in the first official (open)SUSE product – starting with snapshot 20180117, libstorage-ng has replaced libstorage and, thus, yast2-storage-ng has replaced yast2-storage.

They say forewarned is forearmed, so an article was published in advance in news.opensuse.org to set the expectations and to provide and overview of the current status. We would like to encourage all openSUSE Tumbleweed users to (re)visit the article to get a better picture of the situation.

Alignment of partitions in the expert partitioner

An important part of that work in progress is the re-implementation of the Expert Partitioner with Storage-ng technologies. As mentioned many times in previous posts, this is mainly a 1:1 clone, with the same functionality presented in exactly the same way than the classic YaST partitioner. But some times we take the opportunity to introduce some improvement here and there, as we did this week with a topic that can have a very noticeable impact in the system performance: partitions alignment.

Although many people is not aware of it, the partitions in a system must be properly aligned to avoid the performance drop caused by excessive read-modify-write cycles. For details please refer to the great article at Wikipedia explaining the topic, especially the sections titled “4 KB sector alignment” and “SSD page partition alignment”. Moreover, leaving performance considerations aside, some partition tables require alignment to simply work, like DASD partition tables which need alignment to tracks (usually 12 sectors).

The new expert partitioner takes all that into consideration when creating and resizing partitions, ensuring always the required alignment (like the DASD tracks) and encouraging the optional performance-related one, avoiding undesired gaps between partitions in the process.

Above you can see the dialog for choosing the size for a new partition that, unsurprisingly, looks very much like the same dialog in the pre-storage-ng Expert Partitioner. If a size is specified by the user in that dialog (any of the two first options in the form), the start and end of the partition will be aligned to ensure optimal performance and to minimize gaps. That may result in a slightly smaller partition (with the difference being usually less than 1MiB). If a custom region is specified, the start and end will be honored as closely as possible, with no performance optimizations (although mandatory alignment, like DASD tracks, still will take place). This third option is the best to create very small partitions.

The same considerations for optimal alignment will also be taken into account while resizing an existing partition and calculating the minimal and maximal sizes suggested by the partitioner during that process.

Sanity checks for the storage setup

The possibility of bypassing the performance optimizations in the Expert Partitioner is just one example of the (potentially unleashed) power that tool provides. As a consequence of that flexibility, sometimes the user can overlook some important setup configurations or even make mistakes. To help with that, the Expert Partitioner recovered this week its ability to check the entered storage setup.

Once the user has set partitions, LVM volumes, file systems, mount points, etc. and decides to proceed, the Partitioner will validate that setup to ensure it fulfills all necessary requirements for booting and running the system. When some issue is detected, a popup message is presented to show what the problem is, offering the option to ignore the warning and move forward.

Two kind of checks are carried out to ensure the partitioning setup validity. First, the presence of needed partitions for booting is checked. Booting requirements depends on the current architecture (x86, PowerPC, AArch, etc.) and other technical details like the partition table type (GPT vs MS-DOS). Then, the mandatory volumes for the current product are checked. The mandatory volumes are defined in the revamped partitioning section of the control file. Typically, only a volume for root and another for swap used to be mandatory, but now this is totally configurable by anyone defining the product (SLE, Leap, Tumbleweed, your own custom openSUSE derivative…).

As a bonus, all the sanity checks are now centralized (they used to be scattered around the YaST source code) and it’s easier to add new ones (you will miss some old checks at this moment) and to use them from other parts of YaST (like the bootloader module or AutoYaST).

More improvements in the Expert Partitioner

The new warnings and the alignment improvements commented above are not the only news on the evolution of the Expert Partitioner clone this week. Resizing of LVM devices has also been brought back to life, both for volume groups and logical volumes. In the case of logical volumes, the functionality is not much different, at least in the surface, from the partition resizing that was already present and that you can see in the screenshot of the alignment section.

On the other hand, in the context of the Partitioner, resizing a volume group actually means adding or removing physical volumes. Actions that are now possible again, including the corresponding checks. For example, a physical volume cannot be removed if it already exists on disk (that could destroy your data) or if the resulting size of the volume group is not enough to cover all its logical volumes.

Apart from the mentioned functionality, there has also been improvements in how the Expert Partitioner presents the information. For example, now the “type” column shows the correct label and icon for each device instead of that useless TODO label. Moreover, similar TODO marks were replaced by proper data in the device overview tab.

Minimize changes between the SLE15 “Installer” and “Packages” DVDs

The SUSE Enterprise Server 15 (SLES15) product can be installed from a bootable “Installer” DVD medium which contains the installer and a subset of packages needed for a very minimal system. The other packages are available either from a registration server (after registering the SLES product) or via a separate “Packages” DVD medium.

Due to the structure of those DVDs (with some packages being in present in both) the SLES installer was asking the user to change the medium several times during the installation process. Ideally the installer should use all packages from the “Packages” medium without changing the media.

In addition, there is yet another requirement for preferring the packages from the installation DVD to the packages available via a remote repository. Downloading a package from the internet is usually much slower than the DVD and can be problematic in network connections with a download limit or with a price based on the bandwidth usage.

Now the installer properly adjust the priority of all the repositories to achieve the desired behavior. To avoid possible side effects we decided to change the repository priority only when more than one repository is used and all repositories are local (e.g. DVD, hard disk, USB flash disk…). That means in some less common cases (2 DVDs + a remote repository) you will still need to change the medium but this is a safer solution.

Add On products in AutoYaST

For those using SLE Add On products, we have improved the error message if an Add On Product cannot be added during an AutoYaST installation. The user can see now which wrongly configured Add On Product has produced the error.

This will be specially useful with the upcoming SLE15, in which the concepts of Add Ons and Modules will become more relevant than ever.

Fixed a crash when shutting down the YaST user interface

And now it’s time for the corresponding dose of technical insights for those who enjoy that part of our reports.

When UI::OpenDialog() and UI::CloseDialog() calls didn’t match when shutting down the UI (user interface YaST component), you’d get a segmentation fault with a core dump. Well, you did want to shut down YaST, but probably not like that. This is now fixed.

After tracking this down, it was surprisingly simple to reproduce: Just use the YaST version of the trivial “Hello, World” program and comment out the UI::CloseDialog() call.

This was a case of providing additional error reporting causing more problems than the original error: leaving dialogs open while terminating the program is an error, of course. But fixing this little problem by cleaning up the remaining dialogs lead to handling widgets after some of the underlying infrastructure (in this case the QApplication) was already destroyed, so all the QWidgets were also destroyed (because the QApplication takes care of that), but YaST’s generic UI layer was still unaware of that fact and tried to destroy them again.

This is now fixed by properly cleaning up the widget tree in YaST’s generic UI layer first which will also clean up the associated QWidgets so there is nothing left to clean up for the QApplication.

This might also fix a number of similar segfaults in other situations where the YaST Ruby engine would need to shut down because of other problems, e.g. when there is an unhandled Ruby exception.

Surprisingly enough, this must have been a very old (10+ years?) bug, but it never became quite obvious, or at least nobody was ever annoyed enough to try to track it down.

If you want even more details, check the conversation in the bug report.

More to come

The end of this sprint caught up with a lot of almost finished stuff. But following the Scrum principle of “nothing is done until it fits the Definition of Done”, we don’t blog about such stuff. Fortunately, that means the next report will likely be quite juicy. So, see you again in a couple of weeks!

Posted in Distribution, Factory, Programming, Software Management, Systems Management, YaST | 1 Comment »

Encrypted installation media

November 17th, 2017 by Steffen Winterfeldt

Hackweek project: create encrypted installation media

You’re still carrying around your precious autoyast config files on an unencrypted usb stick?
You have a customized installation disk that could reveal lots of personal details?
You use ad blockers, private browser tabs, or even tor but still carry around your install or rescue disk unencrypted for everyone to see?
You have your personal files and an openSUSE installation tree on the same partition just because you are lazy and can’t be bothered to tidy things up?
A simple Linux install stick is just not geekish enough for you?

Not any longer!

mksusecd can now (well, once this pull request has been merged) create fully encrypted installation media (both UEFI and legacy BIOS bootable).

Everything (but the plain grub) is on a LUKS-encrypted partition. If you’re creating a customized boot image and add sensitive data via --boot or add an add-on repo or autoyast config or some secret driver update – this is all safe now!

You can get the latest mksusecd-1.54 already here to try it out! (Or visit software.opensuse.org and look for (at least) version 1.54 under ‘Show other versions’.

It’s as easy as

mksusecd --create crypto.img --crypto --password=xxx some_tumbleweed.iso

And then dd the image to your usb stick.

But if your Tumbleweed or SLE/Leap 15 install media are a bit old (well, as of now they are) check the ‘Crypto notes’ in mksusecd --help first! – You will need to add two extra options.

This is how the first screen looks then

Tags: booting, Hackweek, openSUSE, Security
Posted in Distribution, Factory, Hackweek, Security, Uncategorized | Comments Off on Encrypted installation media

Advertisement
Tags
11.3 11.4 12.1 12.2 12.3 13.1 13.2 amd ARM ATI Beta buildservice Build Service C-Language cloud Collaboration Community conference Education event Events Factory fglrx fun GNOME gsoc Hackweek KDE Kernel Kraft Linux LXDE obs openSUSE Package PostgreSQL radeon raspberry Raspberry Pi rpm Ruby Tumbleweed XML xorg YaST
Lizards
- Adrian Schröter (12)
- Agustin Chavarria (6)
- Alessandro de Oliveira Faria (13)
- Alex Barrios (12)
- Alexander Naumov (10)
- Alexander Orlovskyy (3)
- Alin M Elena (5)
- Andrea Florio (27)
- Andreas Jaeger (70)
- Andreas Stieger (12)
- Andrew Wafaa (31)
- Arvin Schnell (9)
- Atri Bhattacharya (3)
- Bernhard Wiedemann (31)
- Bonnie Kurniawan (1)
- Bruno Friedmann (98)
- Calumma Brevicorne (29)
- Carl Fletcher (1)
- Christopher Hobbs (17)
- Ciaran Farrell (3)
- Stephan Kulow (17)
- craig gardner (2)
- Stephan Barth (2)
- Thomas Schmidt (2)
- Dinar Valeev (1)
- Dirk Mueller (2)
- Dmitry Serpokryl (7)
- Efstathios Iosifidis (21)
- Fabio Mucciante (5)
- Federico Lucifredi (9)
- Greg Freemyer (1)
- Holger Sickenberg (2)
- Hubert Mantel (1)
- Ilya Chernykh (5)
- Ismail Donmez (1)
- J. Daniel Schmidt (2)
- James Tremblay (7)
- Jan Blunck (4)
- Jan Loeser (3)
- Jan Madsen (1)
- Jan-Christoph Bornschlegel (3)
- Jan-Simon Möller (20)
- Javier Llorente (12)
- Jigish Gohil (85)
- Jiri Srain (1)
- Jiří Suchomel (3)
- Johan Kotze (5)
- José Oramas M. (6)
- Josef Reidinger (16)
- Juergen Weigert (1)
- Julio Vannini (9)
- Dinar Valeev (5)
- Kevin "Yeaux" Dupuy (11)
- Klaas Freitag (55)
- Lars Vogdt (11)
- Ludwig Nussel (13)
- M. Edwin Zakaria (4)
- Marcus Hüwe (39)
- Marcus Meissner (2)
- Marcus Moeller (3)
- Marcus Schaefer (4)
- Martin Lasarsch (8)
- Martin Mohring (11)
- Masim "Vavai" Sugianto (20)
- Michael Andres (1)
- Michael Löffler (7)
- Michal Marek (7)
- Michal Vyskocil (12)
- Miguel Angel Barajas Hernandez (2)
- P Linnell (2)
- Nelson Marques (55)
- Nenad Latinović (1)
- Nikanth Karthikesan (2)
- Przemyslaw Bojczuk (1)
- Peter Pöml (4)
- Petr Gajdos (2)
- Petr Mladek (60)
- Petr Uzel (5)
- Ray Wang (1)
- Raymond Wooninck (1)
- Ricardo Chung (7)
- Ricardo Varas Santana (7)
- Richard Bos (11)
- Robert Schweikert (16)
- Rossana Motta (1)
- Rupert Horstkötter (10)
- Sascha Manns (66)
- saydul akram (3)
- Sebastian Siebert (6)
- Shawn Dunn (2)
- Stanislav Visnovsky (7)
- Stefan Haas (1)
- Stefan Hundhammer (5)
- Stefan Schubert (7)
- Steffen Winterfeldt (8)
- Suresh Jayaraman (3)
- Susanne Oberhauser (3)
- Thomas Göttlicher (6)
- Thomas Schraitle (26)
- Togan Muftuoglu (3)
- Tuukka Pasanen (36)
- Will Stephenson (22)
- YaST Team (90)
Archives
- March 2020 (1)
- February 2020 (2)
- January 2020 (1)
- December 2019 (3)
- November 2019 (2)
- October 2019 (4)
- September 2019 (3)
- August 2019 (3)
- July 2019 (4)
- June 2019 (2)
- April 2019 (4)
- March 2019 (3)
- February 2019 (5)
- January 2019 (1)
- December 2018 (2)
- November 2018 (2)
- October 2018 (3)
- September 2018 (1)
- August 2018 (3)
- July 2018 (2)
- May 2018 (2)
- April 2018 (2)
- March 2018 (2)
- February 2018 (2)
- January 2018 (2)
- December 2017 (1)
- November 2017 (2)
- October 2017 (2)
- September 2017 (3)
- August 2017 (4)
- July 2017 (4)
- June 2017 (2)
- May 2017 (4)
- April 2017 (2)
- March 2017 (3)
- February 2017 (3)
- January 2017 (2)
- December 2016 (5)
- November 2016 (3)
- October 2016 (6)
- September 2016 (2)
- August 2016 (3)
- July 2016 (4)
- June 2016 (2)
- May 2016 (2)
- April 2016 (1)
- March 2016 (2)
- February 2016 (4)
- January 2016 (4)
- December 2015 (6)
- November 2015 (2)
- October 2015 (3)
- September 2015 (2)
- August 2015 (2)
- July 2015 (2)
- June 2015 (3)
- May 2015 (12)
- April 2015 (7)
- March 2015 (6)
- February 2015 (6)
- January 2015 (7)
- December 2014 (5)
- November 2014 (3)
- October 2014 (5)
- September 2014 (3)
- August 2014 (5)
- July 2014 (5)
- June 2014 (7)
- May 2014 (9)
- April 2014 (2)
- March 2014 (9)
- February 2014 (9)
- January 2014 (10)
- December 2013 (9)
- November 2013 (10)
- October 2013 (10)
- September 2013 (6)
- August 2013 (7)
- July 2013 (3)
- June 2013 (7)
- May 2013 (4)
- April 2013 (4)
- March 2013 (7)
- February 2013 (6)
- January 2013 (3)
- December 2012 (3)
- October 2012 (6)
- September 2012 (6)
- August 2012 (5)
- July 2012 (12)
- June 2012 (6)
- May 2012 (4)
- April 2012 (4)
- March 2012 (5)
- February 2012 (2)
- January 2012 (5)
- December 2011 (10)
- November 2011 (6)
- October 2011 (5)
- September 2011 (9)
- August 2011 (12)
- July 2011 (14)
- June 2011 (11)
- May 2011 (18)
- April 2011 (15)
- March 2011 (26)
- February 2011 (16)
- January 2011 (23)
- December 2010 (27)
- November 2010 (18)
- October 2010 (21)
- September 2010 (16)
- August 2010 (21)
- July 2010 (20)
- June 2010 (33)
- May 2010 (29)
- April 2010 (24)
- March 2010 (29)
- February 2010 (22)
- January 2010 (20)
- December 2009 (15)
- November 2009 (21)
- October 2009 (17)
- September 2009 (22)
- August 2009 (28)
- July 2009 (36)
- June 2009 (38)
- May 2009 (40)
- April 2009 (30)
- March 2009 (20)
- February 2009 (21)
- January 2009 (27)
- December 2008 (23)
- November 2008 (12)
- October 2008 (23)
- September 2008 (40)
- August 2008 (24)
- July 2008 (12)
- June 2008 (28)
- May 2008 (26)
- April 2008 (1)