** Description changed: + [ Impact ] + + * Since Ubuntu 27.04 plans to reduce the number of supported /boot + configurations, affected users may end up upgrading from an LTS to an + interim release (i.e. 26.10) without the ability to upgrade to the next LTS. + Simply put: these users reach a dead-end release with only 9 months of + support rather than 5 years unknowingly. + + * The fix is to block these users from upgrading beyond 26.04, giving these + users a longer support cycle. + + * It is essential that these upgrades are blocked on 26.04 -> 26.10 as blocking + them later on interim upgrades would mean that the next time to feasibly + change the supported /boot configurations is 28.10. + + [ Test Plan ] + + * Since the intended changes are still in their planning phase, it is not + yet possible to reproduce this behavior. + + * It is however possible to test the fixes by + + (Upgrades assume 26.04 LTS to 26.10 and running against the + proposed pocket using `do-release-upgrade --proposed`, and editing + `/etc/update-manager/release-upgrades` to use `Prompt=normal`) + + Attempt upgrades on a system with /boot configured with... + + 1. ...anything other than ext4 as the filesystem type + 2. ...the "mac" partition table type + 3. ...encryption + 4. ...any software RAID that isn't RAID1 + 5. ...any combination of 1-4 + + Any of these should fail the upgrade pre-maturely with a message explaining + which of these cases the upgrader encountered. + + [ Where problems could occur ] + + * The biggest risk associated with this change is that it's likely more + restrictive rather than permissive on upgrades to 26.10. This is likely for + the best, as if users are using a niche /boot configuration, the risk is + also higher for it to be unsupported in later interim releases. + + [ Other Info ] + + * None. + + [ Original Description ] + The proposal for streamlining boot as mentioned on Discourse [1], means that users on 26.04 would not be able to upgrade beyond 26.10 if they use niche /boot configurations. These upgrades should be temporarily blocked such that a user does not get stuck on 26.10 over 26.04. [1]: https://discourse.ubuntu.com/t/streamlining-secure-boot- for-26-10/79069
** Description changed: [ Impact ] * Since Ubuntu 27.04 plans to reduce the number of supported /boot - configurations, affected users may end up upgrading from an LTS to an - interim release (i.e. 26.10) without the ability to upgrade to the next LTS. - Simply put: these users reach a dead-end release with only 9 months of - support rather than 5 years unknowingly. + configurations, affected users may end up upgrading from an LTS to an + interim release (i.e. 26.10) without the ability to upgrade to the next LTS. + Simply put: these users reach a dead-end release with only 9 months of + support rather than 5 years unknowingly. * The fix is to block these users from upgrading beyond 26.04, giving these - users a longer support cycle. + users a longer support cycle. * It is essential that these upgrades are blocked on 26.04 -> 26.10 as blocking - them later on interim upgrades would mean that the next time to feasibly - change the supported /boot configurations is 28.10. + them later on interim upgrades would mean that the next time to feasibly + change the supported /boot configurations is 28.10. [ Test Plan ] * Since the intended changes are still in their planning phase, it is not - yet possible to reproduce this behavior. + yet possible to reproduce the error modes encountered in 27.04. * It is however possible to test the fixes by (Upgrades assume 26.04 LTS to 26.10 and running against the proposed pocket using `do-release-upgrade --proposed`, and editing `/etc/update-manager/release-upgrades` to use `Prompt=normal`) Attempt upgrades on a system with /boot configured with... 1. ...anything other than ext4 as the filesystem type 2. ...the "mac" partition table type 3. ...encryption 4. ...any software RAID that isn't RAID1 5. ...any combination of 1-4 Any of these should fail the upgrade pre-maturely with a message explaining which of these cases the upgrader encountered. [ Where problems could occur ] * The biggest risk associated with this change is that it's likely more - restrictive rather than permissive on upgrades to 26.10. This is likely for - the best, as if users are using a niche /boot configuration, the risk is - also higher for it to be unsupported in later interim releases. + restrictive rather than permissive on upgrades to 26.10. This is likely for + the best, as if users are using a niche /boot configuration, the risk is + also higher for it to be unsupported in later interim releases. [ Other Info ] * None. [ Original Description ] The proposal for streamlining boot as mentioned on Discourse [1], means that users on 26.04 would not be able to upgrade beyond 26.10 if they use niche /boot configurations. These upgrades should be temporarily blocked such that a user does not get stuck on 26.10 over 26.04. [1]: https://discourse.ubuntu.com/t/streamlining-secure-boot- for-26-10/79069 ** Description changed: [ Impact ] * Since Ubuntu 27.04 plans to reduce the number of supported /boot configurations, affected users may end up upgrading from an LTS to an interim release (i.e. 26.10) without the ability to upgrade to the next LTS. Simply put: these users reach a dead-end release with only 9 months of support rather than 5 years unknowingly. * The fix is to block these users from upgrading beyond 26.04, giving these users a longer support cycle. * It is essential that these upgrades are blocked on 26.04 -> 26.10 as blocking them later on interim upgrades would mean that the next time to feasibly change the supported /boot configurations is 28.10. [ Test Plan ] * Since the intended changes are still in their planning phase, it is not yet possible to reproduce the error modes encountered in 27.04. - * It is however possible to test the fixes by + * It is however possible to test that the following cases do not + upgrade: (Upgrades assume 26.04 LTS to 26.10 and running against the proposed pocket using `do-release-upgrade --proposed`, and editing `/etc/update-manager/release-upgrades` to use `Prompt=normal`) Attempt upgrades on a system with /boot configured with... 1. ...anything other than ext4 as the filesystem type 2. ...the "mac" partition table type 3. ...encryption 4. ...any software RAID that isn't RAID1 5. ...any combination of 1-4 Any of these should fail the upgrade pre-maturely with a message explaining which of these cases the upgrader encountered. [ Where problems could occur ] * The biggest risk associated with this change is that it's likely more restrictive rather than permissive on upgrades to 26.10. This is likely for the best, as if users are using a niche /boot configuration, the risk is also higher for it to be unsupported in later interim releases. [ Other Info ] * None. [ Original Description ] The proposal for streamlining boot as mentioned on Discourse [1], means that users on 26.04 would not be able to upgrade beyond 26.10 if they use niche /boot configurations. These upgrades should be temporarily blocked such that a user does not get stuck on 26.10 over 26.04. [1]: https://discourse.ubuntu.com/t/streamlining-secure-boot- for-26-10/79069 ** Description changed: [ Impact ] * Since Ubuntu 27.04 plans to reduce the number of supported /boot configurations, affected users may end up upgrading from an LTS to an interim release (i.e. 26.10) without the ability to upgrade to the next LTS. Simply put: these users reach a dead-end release with only 9 months of support rather than 5 years unknowingly. * The fix is to block these users from upgrading beyond 26.04, giving these users a longer support cycle. * It is essential that these upgrades are blocked on 26.04 -> 26.10 as blocking them later on interim upgrades would mean that the next time to feasibly change the supported /boot configurations is 28.10. [ Test Plan ] * Since the intended changes are still in their planning phase, it is not yet possible to reproduce the error modes encountered in 27.04. * It is however possible to test that the following cases do not upgrade: (Upgrades assume 26.04 LTS to 26.10 and running against the proposed pocket using `do-release-upgrade --proposed`, and editing `/etc/update-manager/release-upgrades` to use `Prompt=normal`) - Attempt upgrades on a system with /boot configured with... + Attempt upgrades on a system whose /boot is configured with... 1. ...anything other than ext4 as the filesystem type 2. ...the "mac" partition table type 3. ...encryption 4. ...any software RAID that isn't RAID1 5. ...any combination of 1-4 Any of these should fail the upgrade pre-maturely with a message explaining which of these cases the upgrader encountered. [ Where problems could occur ] * The biggest risk associated with this change is that it's likely more restrictive rather than permissive on upgrades to 26.10. This is likely for the best, as if users are using a niche /boot configuration, the risk is also higher for it to be unsupported in later interim releases. [ Other Info ] * None. [ Original Description ] The proposal for streamlining boot as mentioned on Discourse [1], means that users on 26.04 would not be able to upgrade beyond 26.10 if they use niche /boot configurations. These upgrades should be temporarily blocked such that a user does not get stuck on 26.10 over 26.04. [1]: https://discourse.ubuntu.com/t/streamlining-secure-boot- for-26-10/79069 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2170211 Title: [SRU] Systems using niche /boot configurations won't be able to upgrade from 26.10 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2170211/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
