Repository navigation
fix: mask systemd units discouraged in WSL images - #18565
Conversation
Muhammad Falak R Wani (mfrw)
left a comment
There was a problem hiding this comment.
Requesting Jeremy Cline (@jeremycline) to please take a look :)
Thanks
There was a problem hiding this comment.
Pull request overview
Aligns Azure Linux WSL images with WSL validation and branding requirements.
Changes:
- Disables or masks WSL-discouraged systemd units.
- Configures the correct WSL registration name and Azure Linux icon.
- Refreshes component definitions, rendered outputs, and locks.
Reviewed changes
Copilot reviewed 9 out of 11 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
base/comps/azurelinux-release/azurelinux-release.spec |
Packages WSL presets and masks. |
base/comps/azurelinux-release/80-wsl.preset |
Disables conflicting systemd units. |
base/comps/wsl-setup/wsl-setup.comp.toml |
Defines branding overlays. |
base/comps/components.toml |
Moves wsl-setup to dedicated configuration. |
specs/a/azurelinux-release/azurelinux-release.spec |
Rendered release package changes. |
specs/a/azurelinux-release/80-wsl.preset |
Rendered WSL preset. |
specs/w/wsl-setup/wsl-setup.spec |
Sets registration name and icon. |
specs/w/wsl-setup/wsl-oobe.sh |
Updates OOBE branding. |
specs/w/wsl-setup/wsl-distribution.conf |
Updates the example artifact name. |
locks/azurelinux-release.lock |
Refreshes release-component inputs. |
locks/wsl-setup.lock |
Refreshes WSL setup inputs. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Jeremy Cline (jeremycline)
left a comment
There was a problem hiding this comment.
I've not tested it myself, but the change looks correct. It would be good to have note if the cleaning services really can't be run, but my understanding was that it wouldn't break anything if the sockets are set up via tmpfiles. Is it that there's a shared tmp across distros or something?
05ef474 to
3caed15
Compare
There was a problem hiding this comment.
🟡 Changes recommended
Existing installations do not apply the new presets during upgrade, and the linked WSL manifest still uses a different registration name.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Review details
- Files reviewed: 12/14 changed files
- Comments generated: 3
- Review effort level: Balanced
3caed15 to
303657e
Compare
There was a problem hiding this comment.
🟢 Approval recommended
The implementation, rendered outputs, locks, documentation, and assembled-image tests are consistent, with no unresolved blocking issues.
Review details
- Files reviewed: 12/14 changed files
- Comments generated: 0 new
- Review effort level: Balanced
303657e to
bf9d68b
Compare
bf9d68b to
af7798a
Compare
and also, you should upstream it (meaning, add the conditional into the unit files in an upstream systemd PR) so future azl releases (and all future systemd-based distros) won't need to carry any wsl-specific drop-in override files. |
Ack - Dan Streetman (@ddstreetmicrosoft) |
00e0870 to
df97b89
Compare
| install -Dm0644 %{SOURCE35} \ | ||
| %{buildroot}%{_prefix}/lib/systemd/system/"${unit}".d/wsl-disable.conf |
instead of adding a 'refactor' onto the existing patches can you please rebase this into a set of logical commits? it would help to separate things as well - a commit for systemd service modifications, commit for wsl rebranding, commit for test addition, etc. Also, the drop-in files should probably go right into the systemd package itself. It would be even better if you opened a PR with upstream systemd to add the conditionals directly into the unit files, then if it's accepted we can simply apply a backported patch to systemd, instead of using drop-in files. |
| @@ -0,0 +1,15 @@ | |||
| # Azure Linux WSL variant: WSL provides networking, DNS and the console, so | |||
There was a problem hiding this comment.
if you're adding !wsl conditional to these units, you don't also need to provide a preset to disable them, right?
| RemovePathPostfixes: .wsl | ||
| Provides: azurelinux-release-identity = %{version}-%{release} | ||
| Conflicts: azurelinux-release-identity | ||
| Requires(meta): azurelinux-release-container = %{version}-%{release} |
There was a problem hiding this comment.
not sure i'm in agreement on renaming this, maybe we should have a azurelinux-release-wsl in addition to azurelinux-release-container; though i think we don't need to add anything specifically for wsl to azurelinux-release-* anymore, so this can be removed, right?
Use the stable os-release-derived AzureLinux-4 registration name for every Azure Linux 4.x release and pass the real Azure Linux icon to wsl-setup instead of relying on Fedora's default compatibility path. Move wsl-setup to a dedicated component definition so overlays can update the package without forking its Fedora spec. Drop Fedora branding from the installed OOBE script and use the Azure Linux artifact name in the wsl-distribution.conf example. This keeps the registration name aligned with the AzureLinux entry proposed for microsoft/WSL#41120 while minimizing divergence from upstream. Signed-off-by: Muhammad Falak R Wani <[email protected]>
…n=!wsl Install vendor drop-ins (/usr/lib/systemd/system/<unit>.d/) setting ConditionVirtualization=!wsl for systemd units that conflict with WSL's networking, DNS, console, and /dev initialization. Placing these drop-ins directly in the systemd package leaves /etc/systemd/system untouched for administrator overrides and avoids needing a separate WSL preset file while an upstream systemd PR is pursued. Signed-off-by: Muhammad Falak R Wani <[email protected]>
Fix a copy-paste bug in %package identity-wsl where Requires(meta) referenced azurelinux-release-container instead of the existing azurelinux-release-wsl subpackage (%package wsl), which caused the container release package to be pulled into WSL images. Signed-off-by: Muhammad Falak R Wani <[email protected]>
Document how the systemd package uses ConditionVirtualization=!wsl vendor drop-ins to skip units that conflict with WSL's networking, DNS, console, and /dev management, while keeping systemd-tmpfiles-setup.service and systemd-tmpfiles-clean.timer enabled for WSLg and /tmp cleanup. Signed-off-by: Muhammad Falak R Wani <[email protected]>
Add static image tests verifying that the WSL image installs only the WSL release variant, registers as AzureLinux-4 with the Azure Linux ICO file, configures ConditionVirtualization=!wsl vendor drop-ins without masking units under /etc/systemd/system, and keeps systemd-tmpfiles setup and cleanup active for WSLg. Signed-off-by: Muhammad Falak R Wani <[email protected]>
df97b89 to
051aeec
Compare
|
Hi Dan Streetman (@ddstreetmicrosoft) - I am not an expert at systemd - so please excuse if i might have done any silly mistakes. |
Dan Streetman (ddstreetmicrosoft)
left a comment
There was a problem hiding this comment.
lgtm
|
/azp run |
|
Azure Pipelines: 2 pipeline(s) were filtered out due to trigger conditions. |


feat(azurelinux-release): disable WSL-discouraged systemd units
WSL provides networking, DNS resolution, the console and /tmp for the
distribution, so units that duplicate that management should not run.
WSL's image validator (distributions/validate-modern.py) flags them via
DISCOURAGED_SYSTEM_UNITS, and the Azure Linux WSL image currently trips
seven of those checks plus getty@tty1.
Add an 80-wsl.preset to the identity-wsl subpackage disabling the units
that can be preset (systemd-networkd*, systemd-resolved* and
getty@*.service). The 80- prefix sorts before both azurelinux-release's
90-default.preset and systemd's 90-systemd.preset, and systemd applies
the first matching line, so it overrides both.
Presets only act on units with an [Install] section. The remaining units
are static -- systemd-vconsole-setup.service is pulled in by a udev rule
and the rest by *.target.wants directories systemd ships in /usr/lib --
so mask them with /etc/systemd/system symlinks to /dev/null, which is
also exactly what WSL's validator looks for.
systemd-tmpfiles-setup.service is deliberately left enabled: wsl-setup
relies on it to materialize the WSLg X11/Wayland/PulseAudio socket
links, so masking it would break GUI application support. It remains a
non-fatal warning.
Verified with a wsl-dev image build against the locally built RPMs:
discouraged-unit findings drop from seven (plus getty@tty1 enabled) to
the single intentional systemd-tmpfiles-setup.service warning.
config.sh; owning the policy in the -release package keeps it with the
variant definition, as suggested in review of Add AzureLinux official WSL image to the distribution manifest WSL#41120.
feat(wsl-setup): use Azure Linux name and branding for WSL registration
wsl-setup's %post invokes /usr/bin/wsl-setup with no arguments, so
/usr/lib/wsl-distribution.conf is generated from Fedora's defaults:
WSL maintainers flagged both while reviewing the Azure Linux image for
Add AzureLinux official WSL image to the distribution manifest WSL#41120: the icon path does not exist in a plain image, and
the registered name does not match the "AzureLinux-4.0-BETA" entry in
WSL's distributions/DistributionInfo.json, so
wsl --installand adouble-click install would register two differently-named distributions.
Upstream's guidance (jeremycline) is for downstream distros to pass
non-default values to the post-install script rather than fork the spec,
which is also what RHEL does.
Promote wsl-setup to a dedicated comp.toml and overlay %post to pass
--name and --icon explicitly. Pointing at azurelinux-logo.ico directly
also drops the reliance on the fedora-logo.ico compatibility symlink.
Strip Fedora branding from the two files the package installs onto the
running system: the OOBE script header and the example command in the
wsl-distribution.conf template.
The upstream ICON_PATH default in the wsl-setup script is deliberately
left alone; it is inert now that --icon is always passed, and leaving it
keeps the divergence from Fedora to the spec file only.
Verified in a mock chroot: /etc/wsl-distribution.conf reports
defaultName = AzureLinux-4.0-BETA and icon = azurelinux-logo.ico, the
icon resolves to a real 256x256 Windows ICO, and no Fedora strings
remain in the installed configs or OOBE script.