** Description changed: [Impact] - Specific to the Raspberry Pi, 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. + 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] - TODO + 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 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. + 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.
-- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1850678 Title: flash-kernel only updates the dtb of the Pi it's on To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1850678/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
