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

Reply via email to