Ubuntu-Archive/wsl-setup
1
0
Fork 0
mirror of https://github.com/ubuntu/wsl-setup.git synced 2026-03-25 00:05:04 +01:00
Code Issues Projects Releases Packages Wiki Activity
No description
195 commits 3 branches 17 tags 743 KiB
Find a file
Exact
Carlos Nihelton 2dcaa1ecf0
 fix(CI): Shutdown the WSL VM before validating the instance state in integration tests (#48) 
It looks like a shutdown of WSL before validating the image is
beneficial in CI, we had three successful runs in a row after replacing
`wsl --terminate instance` with `wsl --shutdown`, see
[1](https://github.com/ubuntu/wsl-setup/actions/runs/23439953757),
[2](https://github.com/ubuntu/wsl-setup/actions/runs/23440423370) and
[3](https://github.com/ubuntu/wsl-setup/actions/runs/23441471549).

Some historical facts to get started:

- Last in-sequence successful integration test happened on Jan 20th,
2026
- WSL was upgraded in GH runners on Jan 9th, we had at least one
successful in-sequence run with that version of WSL. Since then no
changes to WSL in GH hosted runners.
- The version of cloud-init on the last successful and the first failed
runs were the same: v25.3.
- Recent images of resolute come with cloud-init v26.1
- The last CI failure was already running with that image.

So it doesn’t seem a particular issue with a version of cloud-init or
WSL.

The symptom is always the same (not easily reproducible locally):

```
 UNIT              LOAD   ACTIVE SUB    DESCRIPTION
● user@1001.service loaded failed failed User Manager for UID 1001

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

1 loaded units listed.
```

My small historical analysis since a little before the failure trend
started until now didn't reveal any culprits or even suspects, but I
realized that it would be nice to have kept the image manifests over
time to compare the packages and versions. This doesn't seem the
particular case where having that would help, but future problem solving
might benefit from this idea, so I'm modifying the `get-wsl-image`
action to download the image manifest and upload it as a CI artefact.

---

UDENG-9298
2026-03-23 13:56:34 -03:00
.github Allows saving the image manifest for future troubleshooting 2026-03-23 11:07:10 -03:00
cloud/cloud.cfg.d fix(cloud-init): DS List should contain one additional datasource in order to skip running cloud-init when there is no user-data file 2024-07-19 11:33:36 -03:00
debian fix(d/changelog): Edit entry to include LP bug 2026-03-06 12:53:11 -05:00
systemd/system/multipathd.socket.d Disable timesyncd by default 2026-01-08 12:04:44 -03:00
test Comment about the reasoning 2026-01-08 12:46:13 -03:00
update-motd.d Check if cloud-init log is readable by the current user in 99-wsl 2024-09-17 09:57:33 -03:00
wsl Fix terminal profile syntax 2024-12-04 18:03:27 -03:00
.shellcheckrc Add ubuntu insights integration 2025-12-02 13:52:34 -05:00
CONTRIBUTING.md Add contributing guidelines to the repository 2025-12-17 14:37:10 -05:00
LICENSE Initial commit 2021-10-11 11:19:27 +02:00
README.md New readme description 2024-02-05 11:57:33 +01:00
SECURITY.md Stick with "wsl-setup" as the project name 2025-12-17 15:44:33 -03:00
ubuntu-insights.sh Update the Ubuntu Insights prompt to match the wording of GNOME control center 2026-03-05 10:34:10 -05:00
wait-for-cloud-init Format scripts with shfmt for consistency 2025-12-02 13:52:38 -05:00
wsl-setup Implement shellcheck fixes 2025-12-17 09:33:56 -05:00

README.md

wsl-setup

WSL integration setup. This project helps setting up a working WSL environment with systemd enabled by default.