Home Home > Uncategorized
Sign up | Login

Archive for the ‘Uncategorized’ Category

Highlights of YaST Development Sprint 51

February 22nd, 2018 by
  1. Can you perform an online offline migration?
  2. Will you understand the license better if you display a different translation?
  3. Is your /home mounted or haunted?

Welcome back to our linguistic blog disguised as a YaST team sprint report.

Installation and Upgrade

Offline Upgrade Using Bootable Media via SCC

The last few weeks we spent quite some time implementing the offline migration from the old SUSE Linux Enterprise products (versions 11 and 12) to the upcoming version 15.

Note: the offline migration term actually means that your production system is not booted and running, it is not about the network status. At offline migration a different system is booted (usually from a DVD). See more details in the official SUSE documentation.

We implemented and tested the upgrade from SLE 12 SP3. The offline migration workflow is similar to the online migration as implemented in SLE 12 release. The only difference is that you boot the SLE 15 medium, select Upgrade in the boot menu and then select the disk partition to upgrade. The rest should be the same as in the online migration.

The migration from SLE 11 is a bit more complex as it is registered against the older Novell Customer Center and requires some additional changes in the installer. This is work in progress.

And the last note: for testing the offline migration to SLE 15, your system needs to be registered using the Beta registration keys. For regular SLE 12 and 11 registrations, the migration to SLE 15 is blocked. It will be unblocked after the SLE15 has been officially released.

Made the addon Linuxrc Option Work Well with the Packages DVD

In SLE 15 there are numerous modules and extensions, such as the Live Patching module, or the Web Scripting module. On physical DVDs, we are putting all of them on a single Packages DVD.

When you are installing SLES and choose to add such a module during the installation from the DVD, you will be presented with a screen to select from all the modules found on the DVD.

You can also automate this step by passing the addon=dvd:/// option at the installation boot prompt. (See the Linuxrc reference). Formerly this worked only with single-product media. Starting now, the addon option will work also with multi-product media such as the Packages DVD.

Improve Licenses Translations Support

Some months ago, YaST started to use libzypp to get product licenses, instead of using the old SUSE Tags approach. However, until this sprint, this feature was somehow incomplete.

On one hand, the complete list of supported languages was shown, no matter whether a translation was available for a given language or not. On the other hand, the "Licenses Translation" button was missing (it is still used in single product media).

Now both problems are solved and, as soon as new translations are included in the installation media, they should be handled gracefully in the installer.

Replaced Components

Finalize Xinetd Conversion to Systemd Sockets

This sprint we finished our change from xinetd to systemd sockets for starting services on demand. To finalize it there is basically two main tasks.

The first one was dropping the YaST module for xinetd. That required a conversion of yast2-ftp-server that used this module and also adding a note to AutoYaST that xinetd configuration is no longer supported, so if you have it in your AutoYaST profile, it won’t be applied. The FTP server part was harder because, as mentioned in the last report, one of the two backends does not support systemd sockets, but we found that this backend is a bit ancient and support for us was quite painful. The result is that we dropped pure-ftp and kept only vsftpd backend, which makes the code much simplier and our life better (the final diff-stat is +1100/-3700). And then we converted the usage to systemd sockets. Then we could proceed to dropping yast2-inetd because there was no dependency anymore.

The second task was xinetd usage directly, with an API for starting on demand. It is not used too often and in the end the biggest parts were dropping xinetd usage for VNC based installation and yast2-inst-server which is now converted to use systemd sockets. And here we can give you a nice trick we discovered during the implementation: If a systemd service has a parameter (often the case with services started by a systemd socket) you can stop all of them with a wildcard, e.g. systemctl stop vnc@*.

So here is a happy end – after this sprint there is no xinetd usage and we can support only one tool for starting on demand, allowing us to focus on improving other parts.

Added support for exporting firewalld AutoYaST configuration

In the previous blog entry we announced AutoYaST support for configuring firewalld but cloning the firewall configuration was not supported yet and also the AutoYaST summary concerning the Firewall module needed some love and that is basically what we have implemented during this sprint.

It should be noted that editing of the AutoYaST Firewall configuration is not allowed since the firewall configuration is now done with the firewalld graphical configuration tool (firewall-config)

Storage and Partitioner

Added the Format Options Dialog to the Partitioner

One of the missing things in the new partitioner was the format options dialog letting you tune the file system a bit when it is created.

The options itself are more or less the same as in the old partitioner. This feature is intended more for the experts. As an average user you will rarely find a need to fine-tune file system parameters. But in case you do, the dialog is there to aid you (remember the help button).

Here is a screenshot of the ext4 options:

Removed the Empty Views in the Partitioner

In the process of rewriting the YaST storage stack, we also rewrote the partitioner. Some views in the partitioner were taken over from the old one, but not filled with any functionality so far – they only showed empty pages. We now removed those empty pages:

  • Crypt Files
  • Device Mapper
  • Unused Devices
  • Mount Graph
  • Settings (this one will be back soon with content)

This is what it looks like now:

Compared to the previous version with the empty views:

See also Bug #1078849.

Installation Summary in the Partitioner

One of the sections that survived the Partitioner sifting mentioned above was the Installation Summary. During this sprint we re-implemented this useful view that shows the changes that would be performed in the system, including packages to install in order for the system to work with the chosen technologies. One image is worth a thousand words.

Of course, the information in both lists is updated with every change done in the Partitioner and, as usual, everything works as a charm also in text mode. Including the possibility of collapsing or extending the (usually lengthy) list of operations on subvolumes.

Blocker Errors in Partitioner

A few sprints ago we implemented warnings in the partitioner that inform you if something looks like probably not working, but with expert knowledge it can be made working. Now we add also blocking errors where we are sure it won’t work. It is just a first draft so it will be adapted as needed and as problems appear. Some checks are already moved from the bootloader to the partitioner, so you can fix the partitioning quickly. But enough words, check out the screenshots, where the first one is an error which prevents continuing and the second one is just a warning.

Extending the AutoYaST <device> Element

When defining a <drive> section in an AutoYaST profile, the <device> element should determine to which disk you want to apply that partitioning schema. Usually, it is a device kernel name, like /dev/sda, or a link which resolves to a disk (for instance, /dev/disk/by-id/*, /dev/disk/by-path, etc.).

However, AutoYaST supports specifying other names, like by-partlabel, by-label, etc. Those links won’t resolve directly to a disk, but the storage layer will be able to find out which disk they belong to.

Although SLE 12 supported this behaviour, it was missing from SLE 15 until this sprint.

Fine-tuning of the Requirements to Boot a System

In some situations, an extra partition or a given disk layout is needed to boot an (open)SUSE operating system. Like the separate /boot partition needed in some corner-case legacy scenarios, the ESP partition that must be mounted at /boot/efi in EFI systems or the PReP partition needed by some PowerPC systems. The partitioning proposal performed by the installer tries to ensure those booting requirements are met (so does AutoYaST in some cases) and our beloved Partitioner also includes some checks to warn you user if you forget to create or mount any of those partitions.

But in some situations, the installer was suggesting partitions with a suboptimal size or even partitions that were not strictly needed. On the other hand, the Partitioner was sometimes being too picky, warning about situations that were not such a big problem. So during this sprint we refined our list of booting requirements, updating the corresponding documentation, relaxing the partitioner checks and fine-tuning the proposal outcome. Specifically the PowerPC requirements were revamped based on the input from several experts and bug reports from manufacturers of some systems.

So no matter if you usually trust the installer proposal, if you like to handcraft stuff with the Partitioner or if you install using AutoYaST, the experience should be more smooth now, which fewer (if any) ugly surprises at boot time.

Mount Options Revisited: When the Old Demons Come back to Haunt You

Recently, we reintroduced per-filesystem-type defaults for mount options. We thought this would be a great chance to clean up old code that had become messy over time; we thought we could provide a clean, well-structured and easy-to-understand way to do this.

Then people began to test some more scenarios, and we found out the hard way that in some situations, those mount options depend on the mount point for various reasons: Some quirks of underlying kernel modules like the VFAT filesystem or the way systemd handles mounting the root filesystem during booting made this necessary.

So we had to bite the bullet and reintroduce some of that old code which was kind of messy; for example, for ext4 or ext3 root filesystems, we no longer specify any data=... mount options because this might make remounting the root filesystem read/write at boot time fail; in another case, a mkdir -p /boot/efi/EFI (when installing the boot loader) on a VFAT partition failed despite VFAT technically being case-insensitive (omitting iocharset=utf8 fixed this).

Lesson learned: Some messy old code is messy for a reason. Trying to streamline it may break some scenarios.

Conclusion

The answers to the initial questions are

  1. Yes.
  2. 说不定.
  3. Most of the time.

As the SLE release cycle is shifting from the "all features are mandatory" phase to the "all bugs are top priority" phase, expect less of feature news and more bugfix news in the next report, due in two weeks.

Highlights of YaST Development Sprint 48

January 9th, 2018 by

The YaST team finished its 47th Sprint right before the Christmas break but, sadly, we had not published the corresponding report… until now. The last sprint of the year brought some interesting changes, like Chrony support for AutoYaST, better multi-products medium handling, etc. So let’s recap those changes.

Chrony support in AutoYaST

As part of our effort to support Chrony as the default NTP service for (open)SUSE, we have revamped how AutoYaST handles the configuration of such a service. The first noticeable change is that we have redesigned the schema which, instead of containing low level configuration options, is now composed of a set of high level ones that are applied on top of the default settings.

And here is how the new (and nicer) configuration looks like:

<ntp-client>
  <ntp_policy>auto</ntp_policy>
  <ntp_servers config:type="list">
    <ntp_server>
      <iburst config:type="boolean">false</iburst>
      <address>cz.pool.ntp.org</address>
      <offline config:type="boolean">true</offline>
    </ntp_server>
  </ntp_servers>
  <ntp_sync>15</ntp_sync>
</ntp-client>

Updating the Remote Administration Capabilities

During this sprint, the remote administration client has been deeply modified. To begin with, as xinetd is being replaced by systemd sockets, we have dropped that dependency (adjusting the code accordingly).

Additionally the VNC handling have been improved too. Until now, YaST offered the possibility to connect through a web browser using a Java applet. Now YaST allows the user to enable/disable this feature (check the screenshot below to see how it looks now). It is worth to mention that Michal Srb has replaced the old viewer with novnc, a JavaScript based one. Thanks a lot for that, Michal!

And last but not least, we have seized the occasion to do some code cleaning, reimplementing some dialogs using the Common Widget Manipulation object oriented API.

Modifying AutoYaST Profile During Installation

AutoYaST offers a cool feature that allows the profile to be modified during the initial stages of the installation using an user script. So you can run a script which adjusts the profile and AutoYaST will read it again. If you are interested in such a feature, you could find more information in the official documentation.

On the other hand, in our previous report, we mentioned that AutoYaST was able again to use multipath devices using the new storage stack. But we didn’t count that it was possible to modify the profile on runtime so the initialization happened too early.

Now the bug is fixed so you can again adjust any storage setting using the aforementioned feature.

Properly Handling Selected Modules

As you may know, some time ago we added a support for the multi-product media (DVDs which contain more than one repository/product in separate subdirectories). This time we fixed some issues regarding this functionality.

Originally after selecting several products only one of them was actually selected to install and only one product was displayed in the installation proposal. Fortunately, those issues have been addressed now.

Unified Look & Feel for Multi-Product Selection Dialog

For the multi-product DVD media we used this selection dialog:

The functionality is very similar to the on-line product selection dialog displayed after registering the system:

As you can see the look & feel is quite different, but from the usability point of view the dialogs should look the same regardless whether the products are added from a DVD medium or from an on-line source (a registration server).

This sprint we improved the DVD media dialog to better match the registration dialog:

.

The dialog is still not exactly the same, but now it looks more similar so users should feel more familiar with it. There is also displayed an additional note about not handling the product dependencies automatically. This note was already present in the help text but that is hidden by default. As we got quite a lot of bug reports about this issue we decided to make this fact more prominent.

(Note: The dialogs actually cannot look the very same as the DVD media currently lack some information like the dependencies, beta status, detailed descriptions…).

Dropping SYSTEMCTL_OPTIONS Variable Support

We have been using the environment variable called SYSTEMCTL_OPTIONS (which is SUSE-specific) in our systemd services to prevent locks in dependencies. As this hack will not be necessary for upcoming the (open)SUSE 15 version, it will be dropped from systemd and, therefore, we already removed it from our systemd services.

Unifying Disklabel Handling in AutoYaST

When specifying an AutoYaST partitioning schema, you can select which partition type you want to use for each device (MSDOS, GPT, DASD, etc.). In the past, AutoYaST implemented its own logic to select which one to use in case that it was not specified by the user. After this sprint, AutoYaST relies on the new storage stack in order to decide which option fits better when the user does not specify one.

Bonus: Automatically Checking the Defined Systemd States

Some time ago we had serious issues with service management in YaST (see bug#1012047 and bug#1017166). The problem was caused by introducing a new systemd service state which was not expected by YaST. We fixed the problem by correctly handling the new state.

But the main problem was that we (as the YaST developers) were not notified about this major system change and we found this change later after we got bug reports in Bugzilla. To avoid this problem again in the future we decided to implement a script which would regularly check the defined systemd states notifying us if a unknown state was detected.

To implement the regular check we use the Travis cron job feature which allows running continuous integration builds not only after a change is pushed into the repository but also in regular intervals, even when there is no change in the code.

Alternatively you can use any CI service, but we chose Travis because it is easy to use and we already use Docker for normal CI jobs which allows us to run the latest systemd from openSUSE Tumbleweed in an easy way.

In this case we could possibly run the script in OBS when building the yast2-services-manager package, but that would need adding systemd to BuildRequires which does not sound as a good idea…

So if you also need to run some check scripts regularly you can see more details in this pull request.

Conclusion

2017 was an exciting year with a lot of interesting stuff: a new storage layer, multi-product installation medium, integration of new components (firewalld, chrony, etc.). And it looks like 2018 will not be different and we will have a lot of fun.

Thanks for your support and happy new year!

Encrypted installation media

November 17th, 2017 by

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

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.

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
1200

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.

Fun things to do with driver updates

March 16th, 2017 by

Today: But what if I need a new kernel?

A driver update (DUD) can of course update a single driver. But if that’s not enough and you need a whole new kernel to run an installation?

There are two parts to solve:

  1. replace the kernel used during installation and
  2. get the new kernel installed

We’ll need two tools for this (both available in Tumbleweed or here: mksusecd and mkdud).

1. Replace the kernel used during installation

For this it’s important to know which kernel packages you’ll actually need. Typically it will be kernel-default and kernel-firmware. But older SUSE distributions (SLE 11 comes to mind) had the kernel packages split into kernel-default and kernel-default-base – you’ll need them both.

To make things confusing, modern SUSE distributions also have kernel-default-base – but it’s an alternative to kernel-default. In this case we don’t need it.

If unsure, check kernel-default. If it contains the actual kernel (e.g. /boot/vmlinuz) then you don’t need kernel-default-base.

On some architectures modules are also taken from xen-kmp-default. If that’s important for you, you can add this package to the kernel list as well.

In fact you can add any number of kernel packages or kmps you like.

In the past, sometimes a different kernel flavor was used. For example PowerPC had kernel-ppc64 for a while. Simply use the flavor you need.

It’s a good idea to gather all the kernel rpms into a single directory for easier use:

> mkdir k
> cp kernel-default.rpm kernel-firmware.rpm k
> cp kernel-default-base.rpm k    # only if needed
# add any kernel-related rpms you need

Then, take your SUSE installation iso and run

> mksusecd --create new.iso \
  --kernel k/* -- \
  original_dvd1.iso

Note that the --kernel option accepts a variable number of arguments, so you have to add an isolated -- to terminate the argument list properly.

The output could look like this:

> mksusecd --create new.iso \
  --kernel k/* -- \
  SLES-11-SP4-DVD-ppc64-GM-DVD1.iso
kernel version: 3.0.101-63-ppc64 --> 3.0.101-94-ppc64
CHRP bootable (ppc64)
building: 100%
calculating sha1...

The command above will actually get the list of required modules from the old installation iso. If you are missing some driver or the new kernel comes with some additional driver, the module will not be added to the new iso.

But there’s the --modules option. It will add the listed modules together with any implicitly required modules via module dependencies.

For example, let’s add the airport wifi-module to our PowerPC iso:

> mksusecd --create new.iso \
  --kernel k/* \
  --modules airport -- \
  SLES-11-SP4-DVD-ppc64-GM-DVD1.iso
kernel version: 3.0.101-63-ppc64 --> 3.0.101-94-ppc64
kernel modules added:
  airport, cfg80211, orinoco
CHRP bootable (ppc64)
building: 100%
calculating sha1...

As you can see, it automatically adds orinoco and cfg80211 as well.

2. Get the new kernel installed

This is relatively simple. A driver update can do this:

> mkdud --create foo.dud \
  --dist sle11 \
  --install repo \
  k/*

This creates a driver update for SLE 11 (which also applies to SP4) and the kernel rpms are installed via an auto-generated add-on repo (--install repo).

Now we have the driver update that installs our kernel packages. But how do we use it?

We integrate it into our iso above!

> mksusecd --create new.iso \
  --initrd foo.dud \
  --kernel k/* -- \
  SLES-11-SP4-DVD-ppc64-GM-DVD1.iso

mksusecd has an --initrd option that directly accepts driver updates and integrates them into the iso.

3. Can I have a choice?

Maybe you just want to test this new kernel or sometimes need the old one and sometimes the new one. Can you make an installation iso that lets you choose the kernel?

Oh yes! 🙂

> mksusecd --create new.iso \
  --add-entry 3.0.101-94 \
  --initrd foo.dud \
  --kernel k/* -- \
  SLES-11-SP4-DVD-ppc64-GM-DVD1.iso

This does not replace the old kernel but adds a new boot entry Installation - 3.0.101-94.

So you can install with old or the new kernel.

TOSprint or not to sprint?

February 27th, 2016 by

TOSprint Paris 2016

Report of a week of sprint

TOSprint in Paris has just ended (wiki page).

What a week!

First of all I want to warmfully thank the sponsors, especially Olivier Courtin from Oslandia for the organization, and Mozilla France for hosting us.

What is TOSprint?

Once a year a bunch of hackers from projects under OsGeo umbrella, meet in a face to face sprint.
This year it happenned in Paris with great number of participants (52).

There was globally five big groups, and if each community was running its own schedule,
there was a lot of cross echanges too.

TOSprint Mozilla

Mateusz Łoskot

Personal objectives

My main objective, except being enough luckly to be a sponsor, was to go there and be in direct contact with upstream.

This can help a lot to improve packages, and create new ones.

Moreover, as one of my openSUSE’s Application:Geo peer maintainer, Angelos Kalkas was also participating, we decided to make somes changes, and improve the situation of the repository.

(more…)

Cleanup on OBS – Bacula packages to adopt

October 25th, 2015 by

I was one of the creator and maintainers of bacula packages on obs (Story started 4 years ago).
Since then (+3 years) I’m using another tool called Bareos, and have no more interest
nor time to maintain those packages.

Since sometimes, bacula project has released two main major version. (7.0 and 7.2).
Nobody has taken care of the packages available on obs Archiving:Backup, nor have
proposed an update. [1]

Those packages have never been submitted to Factory, and proposed to any released openSUSE version.
From one of the last upstream announcement Bacula project will deliver directly prebuild packages for major distributions.

So if you’re interested to take ownership of those, raise your hands now (ask maintainer status with obs interface).
I will let a grace period of one month before sending a delete request.

Have fun!