[Bug 1980929] Autopkgtest regression report (livecd-rootfs/2.765.6)

[Ubuntu SRU Bot]

All autopkgtests for the newly accepted livecd-rootfs (2.765.6) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

livecd-rootfs/2.765.6 (s390x)


Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/jammy/update_excuses.html#livecd-rootfs

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

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

Title:
  [SRU] Allow to bypass container exit test

Status in flash-kernel package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in flash-kernel source package in Jammy:
  Fix Committed
Status in livecd-rootfs source package in Jammy:
  Fix Committed
Status in flash-kernel source package in Kinetic:
  Fix Released
Status in livecd-rootfs source package in Kinetic:
  Fix Released

Bug description:
  https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1863145
  introduced a test at the beginning of main() to skip flash-kernel
  completely if we are in a container: that logic breaks the creation of
  RISC-V images where we need flash-kernel to run in order to install
  the dtb at the right location for update-grub.

  So introduce a new environment variable that allows to bypass this
  test in such circumstances: FK_FORCE_CONTAINER must be equal to "yes"
  to skip the test and allow flash-kernel to run.

  [Impact]

  RISC-V images build needs to run flash-kernel to install the dtb for
  update-grub to find. Currently, Ubuntu has a delta that prevents
  flash-kernel to run in a container but our infrastructure runs the
  images build inside a container which breaks the installation of the
  dtb on RISC-V images.

  We fix this by adding a new environment variable which will be set to
  "yes" only when building a RISC-V image.

  [Test Plan]

  To reproduce this bug, we need to launch livecd-rootfs inside a LXC
  container.

  To test this fix, I'll patch livecd-rootfs in order to set the new
  environment variable and we'll trigger a new build of a RISC-V image
  from launchpad.

  Additionally, an Ubuntu Server image should be spun up in a LXC
  container, and flash-kernel from the -proposed pocket should be
  executed to ensure it does *not* run:

  * Launch an Ubuntu Jammy image in LXD: lxc launch ubuntu:j test-fk
  * Shell into the instance: lxc exec test-fk bash
  * Enable proposed (https://wiki.ubuntu.com/Testing/EnableProposed)
  * Update flash-kernel to the proposed version: apt install -t jammy-proposed flash-kernel
  * Run flash-kernel if the update did not already: flash-kernel
  * Ensure it exited cleanly without doing anything (echo $? and check /boot looks the same?)

  [Where problems could occur]

  We must take care at not breaking other images builds, or boot on the
  cloud images (the reason for initial introduction of the container
  test in LP: #1863145), so great attention to the patch must be paid so
  that it only changes the current behaviour when we set the environment
  variable. The chosen variable name is specific enough as it likely
  won't be used (i.e.: FK_FORCE_CONTAINER).

  [Other Info]

  This patch is needed in Jammy as we intend to publish new RISC-V
  images for 22.04.1.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1980929/+subscriptions