linux-headers-4.4.0-43-Microsoft for Nvidia Driver

[andys0975]

As the screenshot below :

I tried to install Nvidia driver on my Ubuntu subsystem, however it request me "linux-headers-4.4.0-43-Microsoft" package.
I use
$ sudo apt install linux-headers-4.4.0-43-Microsoft
and the result said:

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package linux-headers-4.4.0-43-Microsoft
E: Couldn't find any package by glob 'linux-headers-4.4.0-43-Microsoft'
E: Couldn't find any package by regex 'linux-headers-4.4.0-43-Microsoft'

So I wonder how I could install this package, or is it any other simple way to install Nvidia Driver?
Thank you!

[therealkenc]

E: Unable to locate package linux-headers-4.4.0-43-Microsoft

Interesting. The package script is picking up uname -r. It can't locate the package because that name does not exist.

or is it any other simple way to install Nvidia Driver?

No. If you are looking for OpenGL there are some instructions for llvmpipe here.

[chenhao1umbc]

The same problem here when I tried the same thing...

[fpqc]

Of course you're hitting the same problem. The graphics driver can't be compiled because there are no kernel headers for WSL's "kernel" (actually a Windows driver), and currently no way to send ioctls to the nvidia device in the first place (it's not visible to WSL in lspci, which doesn't even complete due to missing procfs information).

DKMS is actually interesting, and I hadn't thought about it much, but it could be the case that in the future, maybe DKMS and "kernel headers" could allow for the recompilation of some drivers to work with WSL. DKMS was actually created in order to solve the problem of the lack of stability of the Linux Kernel ABI for proprietary drivers, and it might be flexible enough to allow Microsoft to provide their own headers for such drivers.

On the other hand, a bigger problem in this case is that Windows will load its own drivers for these devices automatically. Linux device drivers are meant to be run on a kernel running on bare metal, that is to say, with unrestricted access to devices at a low level (modulo a hypervisor, which can assign low-level device access to different kernels running atop the hypervisor). Even if Microsoft made low-level device access available to WSL, you would have to assign the device to either control by the Windows driver or the DKMS'd Linux driver.

A better way for this to happen is what was discussed elsewhere, namely some kind of generic thing that looks like a driver to LXSS but really is a layer that forwards things onwards to the NT drivers in an abstracted/hardware independent fashion. Anyway, it's not a priority now and will definitely not be in the next release in FCU in september.

[therealkenc]

A better way for this to happen is what was discussed elsewhere

That was #882.

[fpqc]

Yep!

[therealkenc]

Closing this out as by-design (the discussion has run its course). The OP related to NVIDIA drivers is n/a on WSL, because there is no Linux kernel in WSL.

This said, the by-design reality here has one dangling consequence. Doing a uname to figure out what kernel header package dependency to grab seems to be a common idiom in some aptitude scripts (eg #2649). Those scripts don't "handle" the -Microsoft string appended to /proc/version, which the authors of those scripts would call a bug in our version string. We call it a feature per #423, and there is no turning back on that now.

It is mostly academic, I think, because I can't think of a case where whatever apt package being installed with such a dependency would have any hope of running on WSL. But if such a case exists (?), those scripts would have to be patched upstream to "strip trailing cruft from uname", because the -Microsoft string is not going anywhere in the foreseeable future.