| 2019-10-30 17:20:41 |
Dave Jones |
bug |
|
|
added bug |
| 2019-11-07 17:05:34 |
Dave Jones |
flash-kernel (Ubuntu): status |
New |
In Progress |
|
| 2019-11-07 17:05:37 |
Dave Jones |
flash-kernel (Ubuntu): assignee |
|
Dave Jones (waveform) |
|
| 2019-11-08 13:11:19 |
Launchpad Janitor |
flash-kernel (Ubuntu): status |
In Progress |
Fix Released |
|
| 2019-11-08 13:47:24 |
Francis Ginther |
tags |
|
id-5db015562d35287792a0a3bc |
|
| 2019-11-08 15:54:23 |
Łukasz Zemczak |
nominated for series |
|
Ubuntu Eoan |
|
| 2019-11-08 15:54:23 |
Łukasz Zemczak |
bug task added |
|
flash-kernel (Ubuntu Eoan) |
|
| 2019-11-08 15:54:23 |
Łukasz Zemczak |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-11-08 15:54:23 |
Łukasz Zemczak |
bug task added |
|
flash-kernel (Ubuntu Bionic) |
|
| 2019-11-08 16:35:58 |
Łukasz Zemczak |
description |
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.
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. |
[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.
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
[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. |
|
| 2019-11-08 20:10:08 |
Dave Jones |
description |
[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.
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
[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. |
[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. |
|
| 2019-11-08 23:15:01 |
Brian Murray |
flash-kernel (Ubuntu Eoan): status |
New |
Fix Committed |
|
| 2019-11-08 23:15:02 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-11-08 23:15:04 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2019-11-08 23:15:07 |
Brian Murray |
tags |
id-5db015562d35287792a0a3bc |
id-5db015562d35287792a0a3bc verification-needed verification-needed-eoan |
|
| 2019-11-12 15:05:11 |
Dave Jones |
tags |
id-5db015562d35287792a0a3bc verification-needed verification-needed-eoan |
id-5db015562d35287792a0a3bc verification-done-eoan verification-needed |
|
| 2019-11-12 15:31:50 |
Launchpad Janitor |
flash-kernel (Ubuntu Eoan): status |
Fix Committed |
Fix Released |
|
| 2019-11-12 15:31:57 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2020-02-03 08:49:45 |
Launchpad Janitor |
flash-kernel (Ubuntu Bionic): status |
New |
Fix Released |
|
