SUSE Blog

Make Windows green again – Part 4

Hannes Kühnemund

By: Hannes Kühnemund

February 20, 2017 1:16 pm

Reads:2,215

Comments:0

Score:5

Print/PDF

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:

2 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 52 votes, average: 5.00 out of 5 (2 votes, average: 5.00 out of 5)
You need to be a registered member to rate this post.
Loading...

Tags: , , ,
Categories: Chameleon, Free Tools, openSUSE, Technical Solutions

Disclaimer: As with everything else at SUSE Conversations, this content is definitely not supported by SUSE (so don't even think of calling Support if you try something and it blows up).  It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.

Comment

RSS