Make Windows green again – Part 4 | SUSE Communities

Make Windows green again – Part 4

Share
Share

While we discovered in part 3 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 bad news is, it’s not only affecting graphical programs but command line tools as well and the second bad news is, it’s because of WSL itself not providing a 100% compatible environment Linux is expecting. So any Linux within WSL, incl. the default one which we replaced, is going to face very similar issues. But SUSE to the rescue 😉

lscpu

The command line tool lcspu is a neat tool that gathers information like CPU architecutre, 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 on the other hand. 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 on a half way to implement 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: https://github.com/Microsoft/BashOnWindows/issues/1637 – 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 (https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=7572fb2b8cb69512ca230b7fcfa11577526843f4), 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 blog a quick 5 minutes read (otherwise it doesn’t fit in your morning/afternoon/bedtime schedule), let’s move the topic of issues with graphical tools to the upcoming blog, part 5.

Update:

We just recently released util-linux packages for SLES (2.28-44.3.1) and openSUSE Leap 42.2 (2.28-10.1) containing a lscpu binary being able to detect WSL properly. Thanks to Stanislav Brabec for providing the fixes so quickly.

Table of contents:

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

No comments yet

Avatar photo
9,726 views