This bug was fixed in the package wsl-setup - 0.5.4~24.04
---------------
wsl-setup (0.5.4~24.04) noble; urgency=medium
* fix(cloud-init): DS List should contain one additional datasource in
order to skip running cloud-init when there is no user-data file.
* Deliver warnings via MotD if cloud-init doesn't succeed. (LP: #2080223)
-- Didier Roche-Tolomelli <didro...@ubuntu.com> Tue, 10 Sep 2024
12:50:13 +0200
** Changed in: wsl-setup (Ubuntu Noble)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/2080223
Title:
Ensure WSL instances do not rely on the Windows launcher by using the
new build pipeline
Status in cloud-images:
New
Status in livecd-rootfs package in Ubuntu:
Fix Released
Status in ubuntu-meta package in Ubuntu:
Fix Released
Status in wsl-setup package in Ubuntu:
Fix Released
Status in livecd-rootfs source package in Jammy:
Fix Released
Status in ubuntu-meta source package in Jammy:
Fix Released
Status in wsl-setup source package in Jammy:
Fix Released
Status in livecd-rootfs source package in Noble:
Fix Released
Status in ubuntu-meta source package in Noble:
Fix Released
Status in wsl-setup source package in Noble:
Fix Released
Bug description:
Note: all changes are related to each other and need to land together
before next WSL image rebuild.
Previously, WSL instances relied on a very lightweight build pipeline which
was using the CPC image.
In 22.04 we did a first step to have WSL has its own project in
livecd-rootfs, with its own seed and image to produce a rootfs.
However, a lot of ubuntu differentatior (enabling systemd by default,
managing upgrade policy based on the distribution name, cloud-init
enablement) were relying on an .exe file, ran on first launch, to
ensure that those policies were modified.
Microsoft is going to remove soon those launcher, and so, we won’t
have an entrypoint to modify those policies. We thus needs to ship
between one and three rootfs, varying on the upgrade policy (we
produce multiple Windows applications on the store).
This work has started on 24.04, and rely on cloud-init, (shipping pro client
too for future wsl pro service offering). We thus needs to align our previous
LTS on the latest state of art for WSL.
Note that 20.04 will be more involved and will be treated separately. This is
about aligning 22.04 and 24.04.
What is needed in 22.04:
- ensure livecd-rootfs can create between one and 3 tarballs, with different
upgrade policy and enable systemd by default as a non conffiles.
- ensure we ship the same set of default application (aligning the seed), to
include cloud-init and other tools that developers expect on a WSL system.
Also, the landscapes is shipped as it will be required with our new Pro on WSL
offering. The only difference then with 24.04 is that we don»t ship
wsl-pro-service in this SRU, but only when the beta launches.
- ship wsl-setup:
* it will drop some systemd experimentation (that was never enabled by
default),
* it’s moving all the systemd units adjustements to take into account a WSL
environment (Microsoft kernel, being a distro inside its own namespace running
in parallel to other distros…)
* enable cloud init WSL datasource
* remove core 22.04 support and installer wrapper script as we don’t ship
snaps by default anymore nor installer.
* report the status of cloud-init in MoTD if it fails
What is needed in 24.04:
- ship wsl-setup:
* it’s moving all the systemd units adjustements to take into account a WSL
environment (Microsoft kernel, being a distro inside its own namespace running
in parallel to other distros…)
* enable cloud init WSL datasource
* remove core 22.04 support and installer wrapper script as we don’t ship
snaps by default anymore nor installer.
* report the status of cloud-init in MoTD if it fails
[ Impact ]
The impacts are primarly on new rootfses produced by our build pipeline with
CPC. It allows CPC also to not special case 24.04 for rootfs publication.
So, only new images could see an impact on 24.04 and 22.04 setup, which is
easily spottable.
The other set of impacts is on systemd units, ensuring that we have the
systemd units executed with success as expected and have a working system in
the end.
Finally, aligning the set of components update in 22.04 which are the
defaults tool installed by default, will ensure we are aligning with
24.04.
[ Test Plan ]
1. Build new rootfses (with CPC), publish them on cloud-images.ubuntu.com
-> we should see one image ending up with "ubuntults" for 22.04 image
-> we should have 2 images for 24.04: "ubuntu" and "ubuntults".
2. Build the Ubuntu (24.04), Ubuntu24.04 and Ubuntu22.04 windows package
A. New installations:
1. Ship a cloud-init file to touch a file on disk on
`%USERPROFILE%\.cloud-init\default.user-data`
2. For each ubuntu application, install them on the machine and create an
user on disk
-> Check that basic shell commands works
-> Check that no MoTD messages complains about cloud-init failure
-> Check that the file from the cloud-init profile was applied
-> Run systemctl --failed and ensure nothing is listed related to WSL
specific configuration itself
-> Pro attach the machine and check that it’s attached
B. Upgrade testing:
Have a 22.04 and 24.04 WSL application installed. On each of them, do the
following:
1. apt update && apt full-upgrade
2. wsl --shutdown
3. restart the instance
4. Check the A.2 items all pass.
[ Where problems could occur ]
Most of the issues could happen on initial boot. It will be really easy to
spot any issues there with the previous test plan.
On upgrade, the main difference will be in that we replace already shipped
systemd unit overrides created by the launcher with some coming from a package.
So, the override should still be applied, just in a cleaner way. This is also
easily detectable thanks to the previous test plan.
The set of updated default tools in 22.04 will show a bigger update
than usual, but as we expect most of people to use the "ubuntu" image
and also ubuntu24.04 Windows store application, the alignements is
risk-less and will give coherence from an user perspective.
[ Other info ]
We are already building and testing special Pro for WSL images which are
using this build pipeline and properties (+ shipping wsl-pro-service + new
golang which will be treated separately) in those PPA:
- https://launchpad.net/~ubuntu-wsl-dev/+archive/ubuntu/ppa
- https://launchpad.net/~ubuntu-wsl-dev/+archive/ubuntu/livecd-rootfs
The 22.04 ubuntu meta seed alignement has been committed (the meta package
has not been refreshed):
-
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?h=jammy&id=6123a79d7abdf3f55f1440985a0ed7379a4683e0
-
https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?h=jammy&id=20deab4ec797ac54f91b40799ecf4146efc50316
As said, the alignement on 20.04 will be more complex on the build
pipeline front, and will be treated separately.
We will have separate SRU for the backport of golang 1.23 and the
backport of wsl-pro-service + seeding it by default.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2080223/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
