The verification of the Stable Release Update for wsl-setup has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
-- 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
