[Bug 1850678] Re: flash-kernel only updates the dtb of the Pi it's on

[Launchpad Bug Tracker]

This bug was fixed in the package flash-kernel - 3.98ubuntu11~18.04.1

---------------
flash-kernel (3.98ubuntu11~18.04.1) bionic; urgency=medium

  * Permit flash-kernel to workaround an inconsistent /boot directory when
    triggered prior to the kernel finishing its triggers (LP: #1861292)

flash-kernel (3.98ubuntu10~18.04.1) bionic; urgency=medium

  * SRU of 3.98ubuntu10 to support Raspberry Pi 4B. (LP: #1847587)
  * Removed new entries from db/all.db for machines that were not already
    supported on Bionic
  * Remove "quiet splash" from kernel command line options; Bionic shipped
    without these options and we shouldn't change the boot experience for
    existing users
  * Ensure the "overlays" dir always exists on the boot partition; the Bionic
    image for the Pi 2 shipped without this dir

 -- Dave Jones <dave.jones at canonical.com>  Wed, 29 Jan 2020 16:15:05
+0000

** Changed in: flash-kernel (Ubuntu Bionic)
       Status: New => Fix Released

-- 
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/1850678

Title:
  flash-kernel only updates the dtb of the Pi it's on

Status in flash-kernel package in Ubuntu:
  Fix Released
Status in flash-kernel source package in Bionic:
  Fix Released
Status in flash-kernel source package in Eoan:
  Fix Released

Bug description:
  [Impact]

  When flash-kernel is executed to copy things to the boot partition,
  only the dtb of the Pi that it is being executed on is copied. In
  order to support moving the SD card between Pi models, flash-kernel
  needs to copy *all* dtbs provided by the kernel to the boot partition.

  Consider the case of SRUing Pi 4 support to Bionic. Bionic does not
  currently support the Pi 4, so a user must necessarily boot their
  Bionic image on, say, a Pi 3. If they then upgrade to a kernel
  supporting the Pi 4, flash-kernel will only copy the dtb for the Pi 3
  to the boot partition. If the card is then moved to a Pi 4 it will
  fail to boot due to a missing device-tree.

  This would be a very welcome bugfix/feature for eoan as well, since
  that's where we had first, proper pi4 support.

  [Test Case]

  On both armhf and arm64:

  1. Flash 19.10 image to an SD card
  2. Boot the card on a Pi 2B (armhf only), 3B, or 3B+
  3. Upgrade the kernel to Hui's test kernel, fixing the 4B 4Gb USB issue (see https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1848790/comments/11); this comes with a new device-tree for the 4B - the device-tree for the 4B shipped with the image will not work with the new kernel
  4. Shut down the machine
  5. Move the card to a Pi 4B (any RAM amount)
  6. Attempt to boot the machine; observe failure (the linux kernel will start, but boot will not complete and serial will not operate)
  7. Check the content of the boot partition; only one DTB (the original Pi's) should have a ".bak" copy

  In order to test that the fix works repeat the procedure, but before
  step 3, upgrade flash-kernel from the PPA mentioned below
  (https://launchpad.net/~waveform/+archive/ubuntu/flash-kernel/). Now
  in step 6, the boot should work, and in step 7, all dtbs (and *.dtbo
  in the overlays dir) should have ".bak" copies.

  [Regression Potential]

  The fix comes with a fair amount of flash-kernel code cleanup. On one
  side, more changes might feel more regression prone, but on the other
  - since we are doing a direct backport from focal, this means that
  there's no chance of us forgetting a change and making the backport
  incomplete.

  There is risk involved, as this SRU changes how basically flash-kernel
  performs updates for all the pi variants. The test suite however has
  been extended, so as to reduce regression potential. Potential
  regressions should be looked for in missing DTBs during flash-kernel
  updates and broken boot (due to the modifications made to the boot
  script). That being said, most of those issues should be instantly
  visible during verification.

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