Note:
This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.
6 Likes
The first time I got it, I thought I had broken something in my system and I was trying to fix it until I realize it was on purpose. I think the message in the terminal could be more explicit. For example:
āThe package is in a phased update state and will be available to you in the coming days. If you wish to disable phased updates, please use etcā¦ā
5 Likes
Thanks for commenting! I think a lot of people have unfortunately had the same experience (at least, judging by the bug that was reported about it), so fixing that message to make it more helpful is definitely something thatās being looked into.
Hi, nice write up. Thereās a few things that Iām not clear on and havenāt seen addressed on AskUbuntu or any of the usual info sources.
Currently, Iām running 22.04.1 desktop and Iāve noticed that there are few packages that have been at set at 0% progress for an extended period of time. Looking at https://people.canonical.com/~ubuntu-archive/phased-updates.html you can see that gnome-remote-desktop has been at 0% for almost a month now after being reset from 70%. So obviously errors have been found in the update and further deployment is halted, but no information is available to general users about the nature of the bug(s) as error reports are only able to be viewed by specific members of a group granted access to the error reports.
Is there anyway to tell if the bugs found in the update packages are being addressed? Whatās the policy for how long updates should be held at 0% before its removed and another update is offered to revert the changes in the buggy one? Have these updates been abandoned by the maintainers? Focal has gnome-software that originally made it to 90% and then was set to 0% where its remained for 99 days! The implication is that a number of Focal systems have a gnome-software buggy update installed on their systems that apparently maintainers have let fall by the wayside.
Generally, I think phased updates are a good idea, but it would be beneficial to allow general users the ability see what errors are associated with the updates to determine if the error is applicable to their system so they can decide whether to proceed with the upgrade or not. For example, if the error(s) with gnome-remote-desktop only affects ARM systems and not amd64, then users with amd64 systems could go ahead and install the update. Thereās no way of knowing as it stands now.
p.s.
$ apt show now will display Phased-Update-Percentage field for packages in a phased update.
$ apt policy ~U will show policy information on all packages available for upgrades, include those with phased update status.
Also the utility grep-aptavail from the dctrl-tools package will show packages with Phased-Update-Percentage.
$ grep-aptavail Phased -sPackage,Phased-Update-Percentage
1 Like
Those are some great questions, Steven!
Thereās an old bit of software tester wisdom that says if you move a piece of furniture and find one bug, then assume thereās more. So with software, if you find a bug itās best to assume more are hiding in the corners and cracks. I think with phasing this is some of the unspoken philosophy - once an update is found to have one defect, thereās a good chance that thereās other bugs that just havenāt been found yet. Some may be hiding behind the first bug, others might be triggered by its fix, or whatever oversight led to the first bug could have missed memory leaks or other issues thatād only reveal themselves over longer time or heavier usage. So, the phasing in a way treats a bad bug as a signal that the update itself needs a full workdown of retesting and analysis.
2 Likes
Ah, thatās why I was seeing many more ākept backā package upgrades since moving to 22.04. Having this IN BIG LETTERS in the release notes would have been nice: it looked like a problem.
Because of that, Iād added aptitude safe-upgrade to the update script - it turns out that ignores the phasing.
Now I know whatās going on, I might remove it, but I would be slightly more convinced that security updates were never phased if that didnāt happen to snap packages, where updates with security patches can be delayed for a day or two. Oh, thatās rationing them (because of under resourcing the snap store?) not phasing them, isnāt it?
This isnāt quite true - if multiple packages are phasing all at once and only some of them finish phasing for a particular user, they will stop being displayed, but the old ones will still be there. Also the message will eventually come back. As a suggestion, maybe rather than āthe message will disappear when the phasing has reached 100%ā, perhaps it could read something similar to āthe packages will not be held back once itās ready to be installed on your systemā would work better? That way users wonāt be confused when the message comes back or only part of it disappears.
This is awesome, by the way, thanks!
1 Like
Phased Updates have served me with the best security and user
updates for a while with no complaints. It is seamless on time with each update before each CVE came out after Bionic Ubuntu. Thus I applause our Ubuntu Security Team for this. Along with the entire Ubuntu Team for this effort, Foundations & Desktop.
1 Like
Thanks for commenting, thatās a great point and an excellent suggestion ā Iāve edited the post now.
And thanks for the original post! 
1 Like
You mention that security updates are never phased, yet in my experience that doesnāt seem to be the case. For example, right now Iām seeing shim-signed and grub-efi-amd64 both phasing on my system with both of them having security-related updates. Iām also noticing cryptic messages for certain packages on the āReleased Ubuntu SRUsā status page with notices like āThe phasing of this update was manually stopped by an AAā for grub2-signed (and it has been like that for nearly a week). I applaud the effort of your team to create a system where packages are tested in a controlled manner to increase reliability but there still are a number of areas where there is a lot of confusion. Resolving the bug report about clarifying the āheld backā notices would be a great first step to removing some of this confusion.
Hello @number-one, I can confirm security updates are not phased. The grub2-signed which you report being phased is likely version 1.187.3~22.04.1, which is available via jammy-updates, and not jammy-security. In other words the package has not been released as a security update. You can check the publication history of the package from this page: https://launchpad.net/ubuntu/+source/grub2-signed/+publishinghistory. In the Pocket column you can check if a given version has been released to -updates or -security.
4 Likes
@paride Thanks for the clarification. Itās a bit confusing because there can apparently be some security-related updates coming from the āstandardā update channel (the notes reference CVE IDs and security issues). So I guess the phasing is really just channel-based, though Iām not clear on what criteria is used to determine the channel/pocket through which an update is released.
EDIT I should also note that some of the confusion may be coming from the cockpit console (for which Ubuntu is not responsible). It appears that cockpit may label package updates as security-related because previous versions had security-related changes even if the current update in question does NOT contain any security-related patches.