Hi @niranjuv, we are working to get this solved and the fix published on several levels.
Since this is a bug that also needs to be fixed in Ubuntu releases that are already out and in service, we are required to follow the Ubuntu SRU "stable release update" process that is pretty strict (by intention). It requires the completion of quite significant (and of course successful) testing - without this the updated package is not acceptable by our SRU team and cannot be rolled out and published. The SRU process is in place to take as much care as possible on such SRU updates, since what we (all) want to avoid are regressions. And in case of Ubuntu (and especially Ubuntu LTS releases) that can quickly affect multi-millions of installations. And that's also the reason why the fix needs to be rolled out from newest (current development) release to oldest affected release, just to avoid any regression in case of Ubuntu release upgrades. The SRU process for packages is unfortunately queue based (in contrast to kernel SRUs, which happen in more or less fixed cycles - every 2 / 4 weeks). And over the YE break packages in the queue pilled up a bit. Canonical's Ubuntu distro teams are working on this backlog. But since it's queue based, it's difficult to give an ETA. The so called "aging period" is a fixed part of the SRU process and is in place to allow not only our testing to be completed, but also other people's testing in their particular environments. With that let me point out two more things: i) An updated package with a fix included is already available now, but via the so called -proposed archive pocket. Nevertheless, everyone who enabled or opted-in to use -proposed can install, test and use that package. But until the testing is completed and the aging period is over, it will stay in -proposed, means it will not be visible for default installations (where -proposed is disabled). At the end of the aging period - and in case no regressions were found - this exact same package will transition from the -proposed to the -updates (respectively -security) pocket, and will become available as regular update for everyone. Since I'm unsure if our automated SRU messages/comments here in Launchpad (like https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/2091099/comments/13) are detailed enough, let me quickly list the steps on how to get the updated package installed from proposed: sudo add-apt-repository -y "deb http://ports.ubuntu.com/ubuntu-ports/ $(lsb_release -sc)-proposed main universe" sudo apt -y update # if not automatically done by the previous command sudo apt -y -t=$(lsb_release -sc)-proposed install qemu-system # or maybe more fine grained 'qemu-system-s390x' ii) One may think that this SRU process is a bit lengthy and there must be a quicker way to get a fixed package more quickly into production environments. And that is true, in such cases, Ubuntu users that have a subscription in place (called 'Ubuntu Pro'), are eligible to open a SalesForce (support) case at Canonical. With that our service and support colleagues (rather than we, development) will pick this up. And they have the option to bridge the gap/time that is caused by the SRU process with the help of a hot fix package. However, the SRU process as such will still be needed. I hope that shows the overall effort that is required for such SRUs and helps a bit. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2091099 Title: [UBUNTU 24.04] OS guest boot issues on 9p filesystem To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/2091099/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs