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.
\nThe About apt upgrade and phased updates documentation is the primary reference.
\nUbuntu 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.
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.
\nDSE 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.
\nReview 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.
\nTreat 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.
\nIf 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.
\nProposed 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.
\nCompare 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.
\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "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.\nSource fact: documented behavior\nThe About apt upgrade and phased updates documentation is the primary reference.\nUbuntu 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact package and installed release are involved?\nWhat phasing information does the approved package query show?\nDoes the proposed transaction include removals or other unexpected changes?\nIs the requirement ordinary maintenance, security treatment or a separately planned release upgrade?\n\nDSE recommendation: retain the reason before overriding the result\nDSE 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.\nReview 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.\nTreat 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.\nIf 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.\nVerification and evidence\nProposed 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.\nCompare 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.\nOfficial references\n\nAbout apt upgrade and phased updates — Ubuntu Server.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "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.\n\n## Source fact: documented behavior\n\nThe [About apt upgrade and phased updates](https://ubuntu.com/server/docs/explanation/software/about-apt-upgrade-and-phased-updates/) documentation is the primary reference.\n\nUbuntu 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.\n\n## What the source does not establish\n\nThis 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.\n\n## Applicability questions\n\n- Which exact package and installed release are involved?\n\n- What phasing information does the approved package query show?\n\n- Does the proposed transaction include removals or other unexpected changes?\n\n- Is the requirement ordinary maintenance, security treatment or a separately planned release upgrade?\n\n## DSE recommendation: retain the reason before overriding the result\n\nDSE 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.\n\nReview 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.\n\nTreat 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.\n\nIf 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.\n\n## Verification and evidence\n\nProposed 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.\n\nCompare 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.\n\n## Official references\n\n- [About apt upgrade and phased updates](https://ubuntu.com/server/docs/explanation/software/about-apt-upgrade-and-phased-updates/) — Ubuntu Server.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/", "url": "https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-30" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Cybersecurity", "item": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "ListItem", "position": 3, "name": "Diagnose Ubuntu phased updates before forcing a kept-back package", "item": "https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/#article", "identifier": "https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/", "url": "https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/", "headline": "Diagnose Ubuntu phased updates before forcing a kept-back package", "description": "A kept-back package can require more investigation than a phased rollout; check the documented phasing information and proposed package changes first.", "abstract": "A kept-back package can require more investigation than a phased rollout; check the documented phasing information and proposed package changes first.", "articleBody": "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.\nSource fact: documented behavior\nThe About apt upgrade and phased updates documentation is the primary reference.\nUbuntu 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.\nWhat the source does not establish\nThis 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.\nApplicability questions\n\nWhich exact package and installed release are involved?\nWhat phasing information does the approved package query show?\nDoes the proposed transaction include removals or other unexpected changes?\nIs the requirement ordinary maintenance, security treatment or a separately planned release upgrade?\n\nDSE recommendation: retain the reason before overriding the result\nDSE 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.\nReview 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.\nTreat 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.\nIf 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.\nVerification and evidence\nProposed 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.\nCompare 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.\nOfficial references\n\nAbout apt upgrade and phased updates — Ubuntu Server.\n\nSource review completed October 30, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-30T06:46:36+00:00", "dateModified": "2026-10-30T06:47:30+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/diagnose-ubuntu-phased-updates-before-forcing-a-kept-back-package/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Diagnose Ubuntu phased updates before forcing a kept-back package" }, "articleSection": [ "Cybersecurity", "IT" ], "keywords": [ "Cybersecurity", "IT", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 526, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Ubuntu Server — About apt upgrade and phased updates", "url": "https://ubuntu.com/server/docs/explanation/software/about-apt-upgrade-and-phased-updates/" } } ] } }