# Diagnose Ubuntu phased updates before forcing a kept-back package > A kept-back package can require more investigation than a phased rollout; check the documented phasing information and proposed package changes first. - Canonical URL: https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-10-30T06:46:36+00:00 - Modified: 2026-10-30T06:47:30+00:00 - Last reviewed by DSE: 2026-10-30 - Resource type: Guide - DSE priority: Advisory - Topics: Cybersecurity, IT - Reading time: 3 minutes ## What you need to know A kept-back package can require more investigation than a phased rollout; check the documented phasing information and proposed package changes first. ## Potentially affected Ubuntu systems where APT reports available packages kept back during an upgrade. ## DSE recommendation Check phasing and review the actual proposed transaction before forcing an individual package update. ## Article Bottom line: Establish why a particular package is kept back before overriding its update path. Keep phased rollout information, dependency changes and security treatment as separate parts of the decision. ## Source fact: documented behavior The [About apt upgrade and phased updates](https://ubuntu.com/server/docs/explanation/software/about-apt-upgrade-and-phased-updates/) documentation is the primary reference. Ubuntu describes phased updates as a gradual rollout to subsets of systems, and states that security updates are not phased. The guide warns that individually upgrading a kept-back package can bypass phasing; for other kept-back causes, the proposed transaction may include package removals. The documented apt policy query shows a package’s phasing details, including the rollout percentage in the example. ## What the source does not establish This article does not establish why any particular live package is held back, choose a rollout percentage or recommend bypassing phasing as routine maintenance. It is not an Ubuntu release-upgrade procedure or a substitute for security-update assessment. Treat the guide’s sample versions and percentages as illustrations rather than current host observations. ## Applicability questions - Which exact package and installed release are involved? - What phasing information does the approved package query show? - Does the proposed transaction include removals or other unexpected changes? - Is the requirement ordinary maintenance, security treatment or a separately planned release upgrade? ## DSE recommendation: retain the reason before overriding the result DSE recommends recording the package identity, observed kept-back message and actual phasing information before selecting an intervention. Ask the maintenance owner to distinguish a staged rollout from other causes. Keep an unexplained result open rather than labeling every kept-back package harmless or forcing the entire group. Review the proposed transaction before accepting it. Require the application owner to assess removals and dependency changes relevant to the service. Preserve the intended package list and any reason for an approved exception. Do not turn a desire for a clean upgrade summary into authority to remove an application component. Treat security handling independently. Compare the selected package and update requirement with the organization’s maintenance process instead of using ordinary phasing as a universal explanation for an outstanding security concern. Escalate an uncertain classification to the responsible package or security owner. If waiting is the approved decision, define the next observation and owner. If a targeted override is justified, record the concrete reason and recovery plan before proceeding. Keep release-upgrade prerequisites under their own reviewed workflow; a maintenance exception should not silently become a major operating-system change. ## Verification and evidence Proposed verification: on a representative nonproduction system, collect the package query described above and the actual proposed transaction for a selected harmless maintenance case. Retain the installed release, package identity and observed phasing information without presenting the guide’s sample output as a result. Compare the proposed package additions, upgrades and removals with the accepted maintenance scope before authorizing installation. Where a controlled override is approved, test the representative application afterward and retain the actual outcome separately from the query. Revisit unresolved kept-back causes rather than inferring that one successful targeted update explains the rest of the host. ## Official references - [About apt upgrade and phased updates](https://ubuntu.com/server/docs/explanation/software/about-apt-upgrade-and-phased-updates/) — Ubuntu Server. Source review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change. ## Primary reference - Name: Ubuntu Server — About apt upgrade and phased updates - Authority: ubuntu.com - URL: https://ubuntu.com/server/docs/explanation/software/about-apt-upgrade-and-phased-updates/ - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Diagnose Ubuntu phased updates before forcing a kept-back package,” DSE Security, https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.