[Bug 2154822] Re: Upgrades to resolute with armhf foreign arch fail

[Utkarsh Gupta]

Hm, thinking a bit more as how to fix this -

It's worth splitting this into two, because only one half is ubuntu-
release-upgrader's problem to deal with.

The fresh-install case (install Resolute, add armhf, apt update as Dave
mentioned above) never touches do-release-upgrade at all, so the
release-upgrader can't do anything about it. That one's really an apt
question: nothing today teaches apt that a ports-only arch should come
from ports.ubuntu.com rather than the archive URI it inherited from the
stanza.

@Julian, do you have any plans or suggestions on how to deal with this?
The best we can do from our side is document it, point people at adding
an [arch=armhf] ports source by hand, or take it upstream to apt.
Flagging it here mostly so we don't end up on the hook for fixing it in
the upgrader.

The upgrade case is for u-r-u to fix, and there are two ways to go:

Option 1/ leave it on ports. When we migrate arm64 from ports to
archive, and we spot a ports-only foreign arch enabled, just keep the
whole stanza on ports.ubuntu.com. arm64 is still served from ports for
Resolute and Stonking, so nothing 404s, and it's about the smallest
change we can make.

The catch is it's a stopgap: once arm64 is dropped from ports in 6-10
months, that machine is back to pulling arm64 from a host that no longer
has it, and if the user hasn't upgraded again by then, they break with
no warning.

Option 2/ split the stanza. arm64 points at archive, armhf (or whatever
ports arch is enabled) stays on ports, each one pinned with
Architectures:. So upgrading from Questing turns this:

Types: deb
URIs: http://ports.ubuntu.com/ubuntu-ports
Suites: questing questing-updates questing-security questing-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

into this:

Types: deb
URIs: http://archive.ubuntu.com/ubuntu
Suites: resolute resolute-updates resolute-security resolute-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
Architectures: arm64

Types: deb
URIs: http://ports.ubuntu.com/ubuntu-ports
Suites: resolute resolute-updates resolute-security resolute-backports
Components: main restricted universe multiverse
Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg
Architectures: armhf

My vote is Option 2. The whole reason we're here is a sources file that
quietly assumed one host could serve every arch, and Option 1 just kicks
that same assumption down the road to the day ports drops arm64. The
split is the layout these machines should have had all along, so I'd
rather write it once and be done. Thoughts, Dave, Julian, Nick, Oliver,
others?

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dpkg in Ubuntu.
https://bugs.launchpad.net/bugs/2154822

Title:
  Upgrades to resolute with armhf foreign arch fail

Status in dpkg package in Ubuntu:
  Confirmed
Status in ubuntu-release-upgrader package in Ubuntu:
  Invalid
Status in dpkg source package in Resolute:
  Confirmed
Status in ubuntu-release-upgrader source package in Resolute:
  Confirmed

Bug description:
  On a Pi running Ubuntu questing, with armhf added as a foreign
  architecture, upgrades to resolute fail immediately after updating the
  sources because the updated ubuntu.sources file now points at
  archive.u.c which only supports arm64, but the source applies to
  *both* arm64 and armhf.

  To reproduce:

  * Flash ubuntu-25.10-preinstalled-server-arm64+raspi.img.xz to spare SD card
  * Boot Pi and login
  * sudo dpkg --add-architecture armhf
  * sudo apt upgrade
  * sudo do-release-upgrade

  After confirming "y" to proceed, upgrade fails when attempting to
  refresh apt sources for resolute.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2154822/+subscriptions