Kernel osrelease string breaks kernel packaging (formerly #6911)

[cerebrate]

Windows Version

Microsoft Windows [Version 10.0.26120.1252]

WSL Version

2.3.11.0

Are you using WSL 1 or WSL 2?

• [X] WSL 2
• [ ] WSL 1

Kernel Version

6.10.0-20240719-1-microsoft-custom-WSL2+ (happens on all versions, though)

Distro Version

Debian sid

Other Software

Linux kernel packaging scripts

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

For further details and discussion please see #6911, of which this is a resubmission per the microsoft-github-policy-service-bot.

Diagnostic Logs

No response

[github-actions[bot]]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute [collect-wsl-logs.ps1](https://github.com/Microsoft/WSL/blob/master/diagnostics/collect-wsl-logs.ps1) in an **administrative powershell prompt**: ``` Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1 Set-ExecutionPolicy Bypass -Scope Process -Force .\collect-wsl-logs.ps1 ``` The scipt will output the path of the log file once done. Once completed please upload the output files to this Github issue. [Click here for more info on logging](https://github.com/microsoft/WSL/blob/master/CONTRIBUTING.md#8-collect-wsl-logs-recommended-method) If you choose to email these logs instead of attaching to the bug, please send them to wsl-gh-logs@microsoft.com with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Closed similar issues:

• Kernel version (osrelease) string breaks packaging of custom kernels (#6911), similarity score: 0.92

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[cerebrate]

Current patch for this issue is over here:

https://open.substack.com/pub/randombytes/p/building-apt-6n-kernel-packages-for

[benhillis]

@cerebrate - so just to clarify, there shouldn't be any upper-case characters in the string? @chessturo - is this something you could look into please?

[cerebrate]

Yeah, apt package names can only include lowercase ASCII letters, digits, plus/minus, and period. Since the scripts/package/mkdebian script bases the package name off the kernel osrelease, any uppercase characters in it will break the packager.

(I haven't checked the compatibility for other packaging systems, as I don't generally use them, but it would not surprise me if they have similar issues.)

Unfortunately, and the reason why I bothered patching the script instead of just renaming my custom kernel "-microsoft-custom-wsl2", there're now a whole bunch of things - including probably most significantly systemd and AppArmor - that have incorporated the assumption that finding a capital WSL in the osrelease string is how to identify that you're running on WSL, as seen here. So just taking the capital letters out of the osrelease string is likely to break more than it will fix.

At this point, maybe the best solution would be to incorporate the patch into the WSL2-Linux-Kernel and try to push it into upstream?

[zcobol]

This is a Debian only rule:

Package names (both source and binary, see [Package](https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-package)) must consist only of lower case letters (a-z), digits (0-9), plus (+) and minus (-) signs, and periods (.). They must be at least two characters long and must start with an alphanumeric character.

See Debian Policy Manual at https://www.debian.org/doc/debian-policy/index.html

[cerebrate]

It also appears to be a technical limitation of the apt packaging tools, insofar as they puke when confronted with nonconforming names, and as such presumably affects every apt-using distribution, not just Debian.

(ETA: Admittedly, I haven't actually checked to see if I can manually assemble a non-conforming-namewise apt package, stick it in a repo, and get it to install, but since the dpkg suite is used to build packages for all those distributions, I think "dpkg-source rejects it" should be enough to qualify.)

[chessturo]

I can confirm that this issue exists as described, but this seems more like a bug in the upstream build scripts, rather than a WSL issue. Details on how to submit a patch upstream can be found here.