-
Notifications
You must be signed in to change notification settings - Fork 852
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kernel osrelease string breaks kernel packaging (formerly #6911) #11814
Comments
Logs are required for review from WSL teamIf this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. How to collect WSL logsDownload and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
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 View similar issuesPlease 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:
|
Current patch for this issue is over here: https://open.substack.com/pub/randombytes/p/building-apt-6n-kernel-packages-for |
@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? |
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? |
This is a Debian only rule:
See |
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.) |
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. |
Windows Version
Microsoft Windows [Version 10.0.26120.1252]
WSL Version
2.3.11.0
Are you using WSL 1 or WSL 2?
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
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:
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
The text was updated successfully, but these errors were encountered: