[Bug 2110301] Re: [SRU] Backport u-boot 2025.01-3 to Noble

[Nick Rosbrook]

Some of this has been discussed offline, but here are my thoughts on the
current state of this.

I understand the justification of this to be "give users of recently-
enabled RVA20 boards access to 24.04 for LTS, because they will not be
able to upgrade to 26.04 LTS." It's unfortunate, because that means
someone on 25.04 w/ RVA20 will have to re-install 24.04 LTS to get
continued support. Or, they stay stranded on 25.04 when it eventually
becomes EOL.

In the future, I think bumping the ISA baseline should not be done in
this way. It would be better for this to happen in LTS+1 releases only,
so that hardware first enabled in an interim release does not get
stranded in this way again.

However, given that we enabled new hardware in 25.04 that will not be
supported in 25.10, we need to give those users *something*, so SRU'ing
that HWE to 24.04 LTS seems like the least bad option. Hence, in
principle I think this is OK for noble.

Now, for plucky, I don't think this is acceptable. As noted above, this
is not actually enabling new hardware. That was already done. It appears
to me that the plucky upload was done to preserve the upgrade path given
the version string numbers (2025.01-3ubuntu0.24.04.1 in noble unapproved
is greater than 2025.01-1~0ubuntu2 in plucky).

For oracular, I am also not convinced this is appropriate to SRU. Why
enable another interim release that a user will ultimately be stranded
on? Would they not need to later re-install to 24.04 LTS to remain
supported? Or am I missing something?

It also seems to me that an ubuntu-release-upgrader quirks is needed
alongside this SRU so that 24.04 users that install on this newly-
enabled hardware do not then upgrade to an interim, and later become
stranded.

My concrete requests are as follows:

1. Re-upload noble with a version of 2025.01-0ubuntu0.24.04.1. This is
less than the current plucky version, and upgrades will be possible
without bumping the plucky version number.

2. Re-consider oracular. I understand that the current version string
becomes an issue for noble -> oracular upgrades. But, EOL is fast
approaching. Could we wait it out? Or is this needed sooner?

3. Consider upgrades. I think we need to have the ability to block
upgrades on RVA20 hardware before/when this lands.

I am rejecting all uploads based on the above.

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

Title:
  [SRU] Backport u-boot 2025.01-3 to Noble

Status in u-boot package in Ubuntu:
  Invalid
Status in u-boot source package in Noble:
  Confirmed
Status in u-boot source package in Oracular:
  Confirmed
Status in u-boot source package in Plucky:
  Confirmed

Bug description:
  [ Impact ]

  With the release of Ubuntu 25.04 (Plucky) we support new RISC-V
  hardware:

  * Pine64 Star64
  * DeepComputing FML13V01

  In the 25.10 cycle we will upgraded the ISA from RVA20 to presumably
  RVA23. This implies that hardware that is not RVA23 compliant will
  only be supported on 24.04 in the long term.

  We therefore need to backport the hardware support to 24.04. This
  includes:

  * U-Boot
  * Kernel 6.14 (already completed)

  With this SRU we will backport U-Boot 2025.01-3 to Noble.

  [ Test Plan ]

  For each $board:

  * DeepComputing FML13V01
  * Microchip Icicle Kit
  * Milk-V Mars
  * Pine64 Star64
  * StarFive VisionFive 2
  * SiFive Unmatched

  If the $board was originally supported on the affected $series:

  * Flash the pre-installed image from cdimage for the $series and $board combination
  * Boot the image
  * sudo apt install -t $series-proposed u-boot-$board (e.g. u-boot-starfive)
  * Note that flash-kernel should run during the u-boot upgrade
  * sudo reboot
  * Interrupt the boot sequence
  * echo $fdtfile (check that u-boot's fdtfile variable shows the value matching the board)
  * Exit to allow boot to continue
  * Check boot succeeds

  See the descriptions in the Ubuntu manual tests
  (https://iso.qa.ubuntu.com/) for the respective boards.

  If $board was *not* originally supported on the affected $series:

  * Build test image incorporating proposed version (this may require PPA usage); instructions for this omitted for brevity
  * Boot the image
  * echo $fdtfile (check that u-boot's fdtfile variable shows the value matching the board)
  * Exit to allow boot to continue
  * Check boot succeeds

  Check that booting via GRUB into Ubuntu works.

  [ Where problems could occur ]

  Updating the bootloader always carries the risk of breaking boot on
  user's machines. That said, a bootloader is necessarily a standalone
  binary (when running at boot time). The particular upstream version we
  are backporting is already in successful use in plucky, giving us a
  reasonable degree of confidence that this version is fundamentally
  sound.

  The backport in plucky's case simply incorporates changes to the
  debian/ directory which occurred after plucky's release (we sync'd
  from Debian's experimental branch during plucky).

  The backport for oracular and noble is an actual upstream version
  bump; the risk here is that the build acts differently (e.g. due to
  differences in the build dependencies). To guard against that, the
  test plan covers all potentially affected boards (for which we produce
  official images), not just those on which we hope to enable boot.

  [ Other Info ]

  N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/2110301/+subscriptions