[SOLVED] Locating WSL2 Variants of Kernel Packages

[RandomDSdevel]

Where can I find:

• a package that satisfies `virtual/linux-sources` using Microsoft's WSL2 kernel sources
• a variant of `sys-kernel/linux-headers`*

for my WSL2 Gentoo installation? I'm not seeing them anywhere, at least not from `::gentoo`. Is there an overlay that contains these ebuilds? I tried searching for one, but I couldn't find any.

(Naturally, I don't actually need to build a kernel; WSL2 provides that itself as an injected binary distribution outside of Portage. Support for custom builds of the WSL2 kernel is outside the scope of this thread.)

(* Currently, the version of `sys-kernel/linux-headers` that I have installed as available from `::gentoo` doesn't match the version of the kernel I'm running.

Code: Select all

… ~ # uname -srv
Linux 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023
… ~ # equery list sys-kernel/linux-headers
 * Searching for linux-headers in sys-kernel ...
[IP-] [  ] sys-kernel/linux-headers-6.6:0

Note: The Microsft WSL2 kernel is based on mainline upstream LTS kernels. There isn't an official non-preview WSL2 kernel release based on upstream's 6.1 LTS kernel with rebased downstream patches yet, though; that's still being worked on in this branch.)

[Phoenix591]

It's just fine to use a new version of linux-headers while running an older kernel. See these sources from the wiki's FAQ on that: Glibc mailing list and Glibc FAQ

You don't need virtual/linux-sources at all unless you plan to install a package that builds a kernel module for it, and if you do then you might want to just build the kernel for yourself and set wsl to use your custom built kernel ( avoids potential issues with building modules with different compiler versions than their prebuilts kernel) ( and if you still want to build from their sources stick an entry in /etc/portage/package.provided )

[RandomDSdevel]

It's just fine to use a new version of linux-headers while running an older kernel. See these sources from the wiki's FAQ on that: Glibc mailing list and Glibc FAQ

Ah, so the kernel headers do build- and run-time feature tests and enable code conditionally; thanks for pointing that out.

You don't need virtual/linux-sources at all unless you plan to install a package that builds a kernel module for it, …

I'm `emerge`ing `x11-drivers/nvidia-drivers`.

…and if you do then you might want to just build the kernel for yourself and set wsl to use your custom built kernel ( avoids potential issues with building modules with different compiler versions than their prebuilts kernel)…

That changes the kernel that WSL uses with all distribution installations on your machine, regardless of distribution, though; WSL2 doesn't (yet) support the use of a different kernel per distribution installation.

…( and if you still want to build from their sources stick an entry in /etc/portage/package.provided )

All right, then, if that's sufficient and I don't need a full ebuild for this, I'll consult the documentation for doing that; thank you.

[RandomDSdevel]

…( and if you still want to build from their sources stick an entry in /etc/portage/package.provided )

All right, then, if that's sufficient and I don't need a full ebuild for this, I'll consult the documentation for doing that; thank you.

Actually:

1. WSL2's binary kernel distribution doesn't come along with its sources, and
2. It doesn't look like `/etc/portage/package.provided` can take a bare URI next to a package atom as a source for it,

so I'm going to have to need a full ebuild for this. I don't know if I can write a kernel sources ebuild myself, but I might try to.

[Hu]

package.provided lists the atoms you want Portage to pretend are installed. You could leave comments next to them, but there is no need to give a URI of anything because the atom is solely a directive to pretend. It does not actually install anything, so it does not need an origin for an installation.

Why do you need Portage to pretend that any particular kernel sources are installed?

[RandomDSdevel]

package.provided lists the atoms you want Portage to pretend are installed. You could leave comments next to them, but there is no need to give a URI of anything because the atom is solely a directive to pretend. It does not actually install anything, so it does not need an origin for an installation.

I'm `emerge`ing `x11-drivers/nvidia-drivers`.

and that actually needs the sources, not just for Portage to pretend to have them.

Why do you need Portage to pretend that any particular kernel sources are installed?

To match my running kernel; since it's the WSL2 one, it has Microsoft's Hyper-V VM guest patches applied.

[Phoenix591]

It's just fine to use a new version of linux-headers while running an older kernel. See these sources from the wiki's FAQ on that: Glibc mailing list and Glibc FAQ

Ah, so the kernel headers do build- and run-time feature tests and enable code conditionally; thanks for pointing that out.

You don't need virtual/linux-sources at all unless you plan to install a package that builds a kernel module for it, …

I'm `emerge`ing `x11-drivers/nvidia-drivers`.

…and if you do then you might want to just build the kernel for yourself and set wsl to use your custom built kernel ( avoids potential issues with building modules with different compiler versions than their prebuilts kernel)…

That changes the kernel that WSL uses with all distribution installations on your machine, regardless of distribution, though; WSL2 doesn't (yet) support the use of a different kernel per distribution installation.

…( and if you still want to build from their sources stick an entry in /etc/portage/package.provided )

All right, then, if that's sufficient and I don't need a full ebuild for this, I'll consult the documentation for doing that; thank you.

You don't need nvidia-drivers, WSL 2 is a virtual machine, it doesn't directly expose your real hardware. It does have some special sauce I can get back to you on more later that lets you passthrough some stuff, like you'll want to set VIDEO_CARDS to d3d12 for their special passthrough stuff that's in mesa.

[Phoenix591]

Alright, the other special sauce wsl 2 does is ship in some libraries for this passthrough stuff, as well as the nvidia-smi binary. wsl automatically generates the /etc/ld.so.conf.d file needed to add its directory to the search path, but they also add it ( /usr/lib/wsl/lib/ ) to PATH (in Ubuntu's wsl anyway) which isn't done automatically for us (presumably for nvidia-smi which they put in the same directory as the libraries for whatever reason)

These libraries it ships include libcuda.so and other nvidia cuda related libraries normally found with nvidia-drivers, so it seems safe in this instance to add a version of nvidia-drivers (maybe the nvidia drivers running on your windows host, since thats what version nvidia-smi is reporting) to /etc/portage/profile/package.provided : doing so and then installing and using nvidia-cuda-toolkit to compile and run a simple test program works

[RandomDSdevel]

…you'll want to set VIDEO_CARDS to d3d12 for their special passthrough stuff that's in mesa.

Mesa's `video_cards_d3d12` `USE` flag currently breaks `emerge`ing the package due to Gentoo bug #914905. (At least I think that's the right issue…)

Alright, the other special sauce wsl 2 does is ship in some libraries for this passthrough stuff, as well as the nvidia-smi binary. wsl automatically generates the /etc/ld.so.conf.d file needed to add its directory to the search path, but they also add it ( /usr/lib/wsl/lib/ ) to PATH (in Ubuntu's wsl anyway) which isn't done automatically for us (presumably for nvidia-smi which they put in the same directory as the libraries for whatever reason)

These libraries it ships include libcuda.so and other nvidia cuda related libraries normally found with nvidia-drivers, so it seems safe in this instance to add a version of nvidia-drivers (maybe the nvidia drivers running on your windows host, since thats what version nvidia-smi is reporting) to /etc/portage/profile/package.provided : doing so and then installing and using nvidia-cuda-toolkit to compile and run a simple test program works

OK, this'll work, but fixing my `PATH` is currenlty blocked on https://github.com/Leo3418/leo3418.gith ... cussions/6. (That user's guide is what I originallly used to set my Gentoo WSL 2 instance up.)

[Phoenix591]

…you'll want to set VIDEO_CARDS to d3d12 for their special passthrough stuff that's in mesa.

Mesa's `video_cards_d3d12` `USE` flag currently breaks `emerge`ing the package due to Gentoo bug #914905. (At least I think that's the right issue…)

Alright, the other special sauce wsl 2 does is ship in some libraries for this passthrough stuff, as well as the nvidia-smi binary. wsl automatically generates the /etc/ld.so.conf.d file needed to add its directory to the search path, but they also add it ( /usr/lib/wsl/lib/ ) to PATH (in Ubuntu's wsl anyway) which isn't done automatically for us (presumably for nvidia-smi which they put in the same directory as the libraries for whatever reason)

These libraries it ships include libcuda.so and other nvidia cuda related libraries normally found with nvidia-drivers, so it seems safe in this instance to add a version of nvidia-drivers (maybe the nvidia drivers running on your windows host, since thats what version nvidia-smi is reporting) to /etc/portage/profile/package.provided : doing so and then installing and using nvidia-cuda-toolkit to compile and run a simple test program works

OK, this'll work, but fixing my `PATH` is currenlty blocked on https://github.com/Leo3418/leo3418.gith ... cussions/6. (That user's guide is what I originallly used to set my Gentoo WSL 2 instance up.)

That mesa bug seems to be talking about an error that's specific to lld, llvm's linker, if you're having the same issue try with ld.bfd from binutils instead.

Nothing stopping you from tweaking your path in your user's bashrc or similar.

[RandomDSdevel]

I got `x11-base/xorg-drivers` to `emerge` with its `video_cards_nvidia` `USE` flag set using WSL2's filesystem guest/host interop and the Windows Nvidia graphics drivers. I'm marking this thread as having been solved. I can deal with solving the `PATH` issue later.