Make Windows Green Again (Part 4)

While we discovered in part three of this blog series how to run graphical openSUSE Linux programs within WSL, a lot of readers, including myself, started exploring this new opportunity. Given the feedback we received (either through comments or direct emails/chats), it seems that many of us (and by that, I have to count myself in) hit a road block at some point. Things didn’t work out as expected.

I have one piece of good news, and two pieces bad news for you. The good news is, it’s not really openSUSE related, however, the first bit of bad news is that it’s not only affecting graphical programs but command line tools as well, and the second piece of bad news is that it’s because of WSL itself not providing a 100% compatible environment that Linux is expecting. So any Linux within WSL, including the default one, that we replaced, is going to face very similar issues. But SUSE to the rescue!

Lscpu

Lcspu is a neat command line tool that gathers information like CPU architecture, number of CPUs, threads, cores from sysfs, and /proc/cpuinfo, among other sources (you might compare it to a section of Windows’ Control Panel -> System). It is part of the util-linux package. Running the default version of lscpu within openSUSE Linux shows surprisingly … nothing (while it actually shows something on the default Linux, which we replaced). Here’s the output on my x230 laptop:

OpenSUSE:

hkuehnemund@X230:~$ lscpu
hkuehnemund@X230:~$
hkuehnemund@X230:~$ rpm -q util-linux
util-linux-2.28-7.1.x86_64

Default Linux:

hkuehnemund@X230:~$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) pro Kern:    2
Kern(e) pro Socket:    2
Socket(s):             1
Anbieterkennung:       GenuineIntel
Prozessorfamilie:      6
Modell:                58
Stepping:              9
CPU MHz:               2901.000
BogoMIPS:              5802.00
Virtualisierung:       VT-x
hkuehnemund@X230:~$
hkuehnemund@X230:~$ dpkg -l util-linux
[...]
ii  util-linux                  2.20.1-5.1ubuntu20 amd64
hkuehnemund@X230:~$

So a newer version of util-linux (2.28) isn’t showing anything, whereas an older one (2.20) works? Isn’t that strange? Well, sort of – but not really. The following explanation has been provided by my colleague Stanislav Brabec, our SUSE maintainer for util-linux.

In util-linux > 2.20, a new function has been implemented: vmware_bdoor() (or WMWARE_BDOOR()), which is an assembler code inside is_vmware_platform(). It is expected to crash on all systems except VMware. That is why lscpu installs SIGSEGV handler segv_handler() and sets sigaction(SIGSEGV,) to catch this crash.

On a standard Linux, SIGSEGV is caught and the code continues. WSL is halfway toward implementing this. Rt_sigaction(SIGSEGV,) succeeds, but the signal handler is not installed. That causes the application to fail:

rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
rt_sigaction(SIGSEGV, {0x403a40, [], SA_RESTORER|SA_SIGINFO, 0x7f8ffde54950}, {SIG_DFL, [], SA_RESTORER, 0x7fcf159e4950}, 8) = 0
+++ exited with 1 +++

And now?

Well, two things where SUSE contributed:

1. We reported the issue to Microsoft – and it is going to be fixed with Windows 10 Insider build [15002+].

2. For everyone not running Windows 10 Insider build [15002+] (like me), Stanislav proposed a fix upstream, and a soon to be released update to openSUSE Leap is going to ship a new version of util-linux that has the fix included. Just make sure to run ‘sudo zypper up’ now and then to trigger the update.

To keep this article a quick 5-minute read, let’s move the topic of issues with graphical tools to the upcoming blog, part 5.

Table of contents:

• Part 1: Install openSUSE Leap 42.2 in WSL
• Part 2: Ensure proper user setup
• Part 3: Enable Graphics
• Part 4: This article
• Part 5: Coming soon