Kernel version (osrelease) string breaks packaging of custom kernels

[cerebrate]

Windows Build Number

Microsoft Windows [Version 10.0.21364.1011]

WSL Version

• WSL 2
• WSL 1

Kernel Version

5.10.16 (custom)

Distro Version

Debian sid

Other Software

No response

Repro Steps

1. Fetch the WSL kernel source from GitHub.
2. Copy the default config file from Microsoft/config-wsl to .config
3. make deb-pkg

Expected Behavior

The kernel packages should have been properly built as described here:

https://debian-handbook.info/browse/stable/sect.kernel-compilation.html

Actual Behavior

The build fails as follows:

sh ./scripts/package/mkdebian
  TAR     linux-5.10.16.3-20210504-1-microsoft-custom-WSL2+.tar.gz
origversion=$(dpkg-parsechangelog -SVersion |sed 's/-[^-]*$//');\
        mv linux-5.10.16.3-20210504-1-microsoft-custom-WSL2+.tar.gz ../linux-5.10.16.3-20210504-1-microsoft-custom-WSL2+_${origversion}.orig.tar.gz
dpkg-buildpackage -r"fakeroot -u" -a$(cat debian/arch)  -i.git -us -uc
dpkg-buildpackage: info: source package linux-5.10.16.3-20210504-1-microsoft-custom-WSL2+
dpkg-buildpackage: info: source version 5.10.16.3-20210504-1-microsoft-custom-WSL2+-2
dpkg-buildpackage: info: source distribution bullseye
dpkg-buildpackage: info: source changed by Alistair Young <avatar@arkane-systems.net>
 dpkg-source -i.git --before-build .
dpkg-buildpackage: info: host architecture amd64
dpkg-source: error: source package name 'linux-5.10.16.3-20210504-1-microsoft-custom-WSL2+' is illegal: character 'W' not allowed
dpkg-buildpackage: error: dpkg-source -i.git --before-build . subprocess returned exit status 255
make[1]: *** [scripts/Makefile.package:77: deb-pkg] Error 255
make: *** [Makefile:1529: deb-pkg] Error 2
zsh: exit 2

NOTE: While it would appear that this could be simply worked around by using a custom osrelease string that does not include uppercase characters, the problem is that various containerization-detecting tools (for example, systemd) have taken as official, or at least "unofficially official", word the instructions on detecting WSL given here:

#423 (comment)

For one example, see systemd source here:

https://github.com/systemd/systemd/blob/8fc1efa88fb935ab4357fa39ed71ccb70df55d7e/src/basic/virt.c#L632

Which means that with the current state of affairs, there is no clean way to build a packageable kernel that these tools will detect as WSL. This poses a significant obstacle to building WSL custom kernels in a packaging-friendly way (for example, for deploying modules or kernel headers in a way that distros will recognize) or distributing said kernels.

Diagnostic Logs

No response

[cerebrate]

@benhillis Does this not count as a bug rather than a feature? I mean, it does break the established kernel-building process.

[benhillis]

Oh sorry I misclicked - should this be posted on the WSL2 kernel github then?

[cerebrate]

I didn't think they took issues over there? (There's no issues tab in the repo, anyway.)

[cerebrate]

Finally managed to hack together a patch to let me build a .deb for a WSL-identifiable kernel by flattening the package name in all the right places:

0001-Case-hack-for-Debian-build.patch.gz

[therealkenc]

What is the WSL ask? There is nothing to investigate.

[cerebrate]

@therealkenc Not breaking the existing kernel-building-and-packaging process?

If WSL is going to support custom kernels, which it does, then the ability to build, package, and deploy said kernels would seem to be an obvious corollary of that.

(While, preferably, continuing to let things that need to identify a WSL environment do so.)

[therealkenc]

This is tag external unless you have a WSL ask. WSL does not control Debian userspace.

[cerebrate]

The definition of "external" is "Issue exists outside of WSL components", correct?

So are you telling me here that if a If a WSL-specific kernel change broke, say, ls, that not breaking ls would not be a WSL ask because WSL does not control ls? Because that makes no sense whatsoever. WSL does control the supplied kernel and kernel source, and it is that kernel source in which the problem lies.

Edited: I mean, sorry, I'm not trying to be obstructive here, but I cannot see any way in which a kernel change that breaks userspace is somehow a userspace problem and not a kernel problem. Especially when it's a change that breaks the kernel's own build process; nothing here is external to the kernel source.

[therealkenc]

I am saying the fail is in userspace.

but I cannot see any way in which a kernel change

That was the question. What is the WSL kernel modification you would like. We can field the request here, but right now there is no actionable to address and nothing to investigate. The kernel string is 5.10.16.3-microsoft-standard-WSL2. That Debian does not support that sting is Debian behavior.

[cerebrate]

(Well, it's non-distro-specific apt behavior; it doesn't support building .deb/apt packages on any system. As I understand it neither RPM nor snap support capitalizing package names either, so the chances are good make rpm-pkg and make snap-pkg will also fail with capital-containing kernel release strings.)

Yes, the fail is in userspace, but it's in userspace in the same way that gcc failing when trying to compile the kernel is in userspace, when a .c file uses invalid syntax. Which is to say, the cause of the fail is not in userspace. It's right there in the config, Makefile and/or build scripts shipped with the WSL kernel. If a build from the WSL kernel source using the unmodified WSL default config file fails, that's a WSL bug. (Or, I suppose, an upstream kernel bug.)

As for the actionable: well, I don't know the best option. At the moment, my personal preference would be patching the kernel build scripts so they don't break when presented with a WSL-style version string (and pushing them upstream, for that matter). Or there's changing the version string to not break the build, although that's obviously less good because there are already dependencies out there on the existing version string, per above. Or at the very least desirable, documenting that using the shipped-with-the-WSL-kernel-source config file will break the build when the instructions on an arbitrarily large number of sites out there for building a Linux kernel are followed and changing the Makefile accordingly so that people aren't left having to chase down this issue for themselves.

[therealkenc]

At the moment, my personal preference would be patching the kernel build scripts

I might be missing something so out an abundance of caution: What is the hypothetical change to the kernel source build scripts. You have a naked pronoun "it's". The "package name 'linux-5.10.16.3-20210504-1-microsoft-custom-WSL2+' is illegal: character 'W' not allowed" is not from the kernel scripts.

[cerebrate]

It's from dpkg-source, invoked by dpkg-buildpackage, invoked by scripts/Makefile.package line 78:

https://github.com/microsoft/WSL2-Linux-Kernel/blob/a571dc8cedc8e0e56487c0dc93243e0b5db8960a/scripts/Makefile.package#L78

The relevant bits of the kernel build scripts that need patching, though, are upstream from there: scripts/Makefile.package includes a section that generates package names from the kernel release, and there are a couple of scripts assisting - scripts/package/mkdebian which writes out the control file used by dpkg-buildpackage (the proximal source of the above error), and scripts/package/builddeb .

The patch above (readable at https://gist.github.com/cerebrate/b9215f99b069946a8e933f26f96c9be1 ) is one possible set of changes that makes the apt-packaged build work by lowercasing the kernel release string in places where it is used as the basis for package names.

(Disclaimer: while it does work , I'm not a kernel developer or even particularly experienced in this area.)

[cerebrate]

Updated patch to match changes to kernel source:

0001-deb-pkg-patches.patch.zip

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!