ubuntustudio-release team mailing list archive
-
ubuntustudio-release team
-
Mailing list archive
-
Message #00221
[Merge] ~waveform/ubuntu-manual-tests:pi-boot into ubuntu-manual-tests:main
Dave Jones has proposed merging ~waveform/ubuntu-manual-tests:pi-boot into ubuntu-manual-tests:main.
Requested reviews:
Ubuntu Testcase Admins (ubuntu-testcase)
For more details, see:
https://code.launchpad.net/~waveform/ubuntu-manual-tests/+git/ubuntu-manual-tests/+merge/490120
Add A/B boot test cases to all Pi models. Also add the server test cases for the Pi 500 which were missing previously.
--
Your team Ubuntu Testcase Admins is requested to review the proposed merge of ~waveform/ubuntu-manual-tests:pi-boot into ubuntu-manual-tests:main.
diff --git a/definitions/pi_desktop_cases.xml b/definitions/pi_desktop_cases.xml
index adbf175..62c2ce0 100644
--- a/definitions/pi_desktop_cases.xml
+++ b/definitions/pi_desktop_cases.xml
@@ -97,6 +97,30 @@
</dd>
</ut:test>
+ <ut:test id="ab-piboot">
+ <dt>
+ (for 25.10, questing, and onwards only)<br/>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+ </ut:test>
+
<ut:test id="usb-file-transfer">
<dt>
Perform a large (300-600MB) file copy to USB storage
@@ -340,6 +364,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -369,6 +394,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -398,6 +424,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -427,6 +454,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -456,6 +484,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -485,6 +514,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -519,6 +549,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -553,6 +584,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -582,6 +614,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -611,6 +644,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -640,6 +674,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -669,6 +704,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -698,6 +734,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -727,6 +764,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -756,6 +794,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">15GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -778,6 +817,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">15GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -800,6 +840,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">15GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -822,6 +863,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
@@ -844,6 +886,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:incldue ref="dual-monitor" />
<ut:include ref="ethernet"><ut:define name="intf">eth0</ut:define></ut:include>
diff --git a/definitions/pi_server_cases.xml b/definitions/pi_server_cases.xml
index d8d4225..efa653e 100644
--- a/definitions/pi_server_cases.xml
+++ b/definitions/pi_server_cases.xml
@@ -73,6 +73,30 @@
</dd>
</ut:test>
+ <ut:test id="ab-piboot">
+ <dt>
+ (for 25.10, questing, and onwards only)<br/>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+ </ut:test>
+
<ut:test id="usb-file-transfer">
<dt>
Perform a large (300-600MB) file copy to USB storage
@@ -294,7 +318,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
</ut:test>
<ut:test id="raspinfo">
@@ -311,6 +335,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">1.6-1.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2 (black)</ut:define></ut:include>
@@ -348,6 +373,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2 (black)</ut:define></ut:include>
@@ -385,6 +411,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2 (black)</ut:define></ut:include>
@@ -422,6 +449,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">800-1000MB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2</ut:define></ut:include>
@@ -452,6 +480,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">800-1000MB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2</ut:define></ut:include>
@@ -475,6 +504,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">300-500MB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2</ut:define></ut:include>
@@ -504,6 +534,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">800-1000MB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2</ut:define></ut:include>
@@ -524,6 +555,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">800-1000MB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2</ut:define></ut:include>
@@ -546,6 +578,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">800-1000MB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2</ut:define></ut:include>
@@ -569,6 +602,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="audio">
@@ -599,6 +633,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">1.6-1.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="audio">
@@ -629,6 +664,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="audio">
@@ -659,6 +695,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="audio">
@@ -695,6 +732,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">300-500MB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="audio">
@@ -720,6 +758,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">1.6-1.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2 (black)</ut:define></ut:include>
@@ -753,6 +792,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">3.6-3.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2 (black)</ut:define></ut:include>
@@ -786,6 +826,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2 (black)</ut:define></ut:include>
@@ -819,6 +860,7 @@
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">15GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2 (black)</ut:define></ut:include>
@@ -838,13 +880,14 @@
<ut:include ref="bluetooth" />
</ut:case>
- <ut:case id="1826_RaspberryPi 500 Post-install">
+ <ut:case id="1841_RaspberryPi 500 Post-install">
<ut:define name="model">Raspberry Pi 500</ut:define>
<ut:include ref="power-led" />
<ut:include ref="running" />
<ut:include ref="flash-kernel" />
<ut:include ref="reboot" />
<ut:include ref="shutdown" />
+ <ut:include ref="ab-piboot" />
<ut:include ref="ram-free"><ut:define name="mem">7.6-7.8GB</ut:define></ut:include>
<ut:include ref="usb-file-transfer" />
<ut:include ref="usb-keyboard"><ut:define name="usb">USB2 (black)</ut:define></ut:include>
diff --git a/testcases/image/1711_RaspberryPi 4 2GB Post-install b/testcases/image/1711_RaspberryPi 4 2GB Post-install
index 5b72a31..d667b3d 100644
--- a/testcases/image/1711_RaspberryPi 4 2GB Post-install
+++ b/testcases/image/1711_RaspberryPi 4 2GB Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -310,7 +333,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1719_RaspberryPi 4 4GB Post-install b/testcases/image/1719_RaspberryPi 4 4GB Post-install
index f12230f..941c532 100644
--- a/testcases/image/1719_RaspberryPi 4 4GB Post-install
+++ b/testcases/image/1719_RaspberryPi 4 4GB Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -310,7 +333,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1720_RaspberryPi 4 8GB Post-install b/testcases/image/1720_RaspberryPi 4 8GB Post-install
index 2ffcb28..20af1f4 100644
--- a/testcases/image/1720_RaspberryPi 4 8GB Post-install
+++ b/testcases/image/1720_RaspberryPi 4 8GB Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -310,7 +333,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1721_RaspberryPi 3B+ Post-install b/testcases/image/1721_RaspberryPi 3B+ Post-install
index 375cf3d..7ba26e4 100644
--- a/testcases/image/1721_RaspberryPi 3B+ Post-install
+++ b/testcases/image/1721_RaspberryPi 3B+ Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -275,7 +298,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1722_RaspberryPi 3B Post-install b/testcases/image/1722_RaspberryPi 3B Post-install
index 8a426a1..d5b8090 100644
--- a/testcases/image/1722_RaspberryPi 3B Post-install
+++ b/testcases/image/1722_RaspberryPi 3B Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
diff --git a/testcases/image/1723_RaspberryPi 3A+ Post-install b/testcases/image/1723_RaspberryPi 3A+ Post-install
index 0836068..8538069 100644
--- a/testcases/image/1723_RaspberryPi 3A+ Post-install
+++ b/testcases/image/1723_RaspberryPi 3A+ Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -260,7 +283,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1724_RaspberryPi 2 Post-install b/testcases/image/1724_RaspberryPi 2 Post-install
index f14809e..bd34a1d 100644
--- a/testcases/image/1724_RaspberryPi 2 Post-install
+++ b/testcases/image/1724_RaspberryPi 2 Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
diff --git a/testcases/image/1726_RaspberryPi CM3+ Post-install b/testcases/image/1726_RaspberryPi CM3+ Post-install
index c0b0154..0a078ce 100644
--- a/testcases/image/1726_RaspberryPi CM3+ Post-install
+++ b/testcases/image/1726_RaspberryPi CM3+ Post-install
@@ -46,6 +46,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -169,7 +192,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1727_RaspberryPi CM3+ Lite Post-install b/testcases/image/1727_RaspberryPi CM3+ Lite Post-install
index 5a008f5..38dded4 100644
--- a/testcases/image/1727_RaspberryPi CM3+ Lite Post-install
+++ b/testcases/image/1727_RaspberryPi CM3+ Lite Post-install
@@ -46,6 +46,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -169,7 +192,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1740_RaspberryPi 400 Post-install b/testcases/image/1740_RaspberryPi 400 Post-install
index 8ccf7bf..4dc33a0 100644
--- a/testcases/image/1740_RaspberryPi 400 Post-install
+++ b/testcases/image/1740_RaspberryPi 400 Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -269,7 +292,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1741_RaspberryPi CM4 2GB Post-install b/testcases/image/1741_RaspberryPi CM4 2GB Post-install
index 25daa59..4e33efb 100644
--- a/testcases/image/1741_RaspberryPi CM4 2GB Post-install
+++ b/testcases/image/1741_RaspberryPi CM4 2GB Post-install
@@ -46,6 +46,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -260,7 +283,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1742_RaspberryPi CM4 4GB Post-install b/testcases/image/1742_RaspberryPi CM4 4GB Post-install
index aabb977..7018f43 100644
--- a/testcases/image/1742_RaspberryPi CM4 4GB Post-install
+++ b/testcases/image/1742_RaspberryPi CM4 4GB Post-install
@@ -46,6 +46,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -260,7 +283,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1745_RaspberryPi 4 4GB Desktop SD b/testcases/image/1745_RaspberryPi 4 4GB Desktop SD
index 754cf84..9551bf7 100644
--- a/testcases/image/1745_RaspberryPi 4 4GB Desktop SD
+++ b/testcases/image/1745_RaspberryPi 4 4GB Desktop SD
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1746_RaspberryPi 4 8GB Desktop SD b/testcases/image/1746_RaspberryPi 4 8GB Desktop SD
index b5bad2f..04cd3b9 100644
--- a/testcases/image/1746_RaspberryPi 4 8GB Desktop SD
+++ b/testcases/image/1746_RaspberryPi 4 8GB Desktop SD
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1747_RaspberryPi 400 Desktop SD b/testcases/image/1747_RaspberryPi 400 Desktop SD
index 8a26428..3b809b0 100644
--- a/testcases/image/1747_RaspberryPi 400 Desktop SD
+++ b/testcases/image/1747_RaspberryPi 400 Desktop SD
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1749_RaspberryPi CM4 4GB Desktop eMMC b/testcases/image/1749_RaspberryPi CM4 4GB Desktop eMMC
index 4cd9416..5ff2dc1 100644
--- a/testcases/image/1749_RaspberryPi CM4 4GB Desktop eMMC
+++ b/testcases/image/1749_RaspberryPi CM4 4GB Desktop eMMC
@@ -81,6 +81,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1750_RaspberryPi CM4 8GB Desktop eMMC b/testcases/image/1750_RaspberryPi CM4 8GB Desktop eMMC
index 303b2a1..6fd51a3 100644
--- a/testcases/image/1750_RaspberryPi CM4 8GB Desktop eMMC
+++ b/testcases/image/1750_RaspberryPi CM4 8GB Desktop eMMC
@@ -81,6 +81,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1752_RaspberryPi Zero 2 Post-install b/testcases/image/1752_RaspberryPi Zero 2 Post-install
index c4e5027..8b63315 100644
--- a/testcases/image/1752_RaspberryPi Zero 2 Post-install
+++ b/testcases/image/1752_RaspberryPi Zero 2 Post-install
@@ -58,6 +58,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -231,7 +254,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1777_RaspberryPi CM4 8GB Post-install b/testcases/image/1777_RaspberryPi CM4 8GB Post-install
index d8e6e88..3e276ab 100644
--- a/testcases/image/1777_RaspberryPi CM4 8GB Post-install
+++ b/testcases/image/1777_RaspberryPi CM4 8GB Post-install
@@ -46,6 +46,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -260,7 +283,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1791_RaspberryPi 5 4GB Desktop SD b/testcases/image/1791_RaspberryPi 5 4GB Desktop SD
index 25bd403..83960b0 100644
--- a/testcases/image/1791_RaspberryPi 5 4GB Desktop SD
+++ b/testcases/image/1791_RaspberryPi 5 4GB Desktop SD
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1792_RaspberryPi 5 8GB Desktop SD b/testcases/image/1792_RaspberryPi 5 8GB Desktop SD
index 07468b2..3370366 100644
--- a/testcases/image/1792_RaspberryPi 5 8GB Desktop SD
+++ b/testcases/image/1792_RaspberryPi 5 8GB Desktop SD
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1793_RaspberryPi 5 4GB Post-install b/testcases/image/1793_RaspberryPi 5 4GB Post-install
index 5ac3660..55e329f 100644
--- a/testcases/image/1793_RaspberryPi 5 4GB Post-install
+++ b/testcases/image/1793_RaspberryPi 5 4GB Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -285,7 +308,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1794_RaspberryPi 5 8GB Post-install b/testcases/image/1794_RaspberryPi 5 8GB Post-install
index 40cfc83..8045f3b 100644
--- a/testcases/image/1794_RaspberryPi 5 8GB Post-install
+++ b/testcases/image/1794_RaspberryPi 5 8GB Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -285,7 +308,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1812_RaspberryPi 4 4GB Desktop USB b/testcases/image/1812_RaspberryPi 4 4GB Desktop USB
index c9d81e3..fdb3026 100644
--- a/testcases/image/1812_RaspberryPi 4 4GB Desktop USB
+++ b/testcases/image/1812_RaspberryPi 4 4GB Desktop USB
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1813_RaspberryPi 4 8GB Desktop USB b/testcases/image/1813_RaspberryPi 4 8GB Desktop USB
index 459e772..5e6eb1b 100644
--- a/testcases/image/1813_RaspberryPi 4 8GB Desktop USB
+++ b/testcases/image/1813_RaspberryPi 4 8GB Desktop USB
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1814_RaspberryPi 400 Desktop USB b/testcases/image/1814_RaspberryPi 400 Desktop USB
index cec55e2..f4e489d 100644
--- a/testcases/image/1814_RaspberryPi 400 Desktop USB
+++ b/testcases/image/1814_RaspberryPi 400 Desktop USB
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1815_RaspberryPi 5 4GB Desktop USB3 b/testcases/image/1815_RaspberryPi 5 4GB Desktop USB3
index 655f82b..9789c08 100644
--- a/testcases/image/1815_RaspberryPi 5 4GB Desktop USB3
+++ b/testcases/image/1815_RaspberryPi 5 4GB Desktop USB3
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1816_RaspberryPi 5 4GB Desktop NVMe b/testcases/image/1816_RaspberryPi 5 4GB Desktop NVMe
index a948b69..baa5ad1 100644
--- a/testcases/image/1816_RaspberryPi 5 4GB Desktop NVMe
+++ b/testcases/image/1816_RaspberryPi 5 4GB Desktop NVMe
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1817_RaspberryPi 5 8GB Desktop USB b/testcases/image/1817_RaspberryPi 5 8GB Desktop USB
index f7bded7..143d558 100644
--- a/testcases/image/1817_RaspberryPi 5 8GB Desktop USB
+++ b/testcases/image/1817_RaspberryPi 5 8GB Desktop USB
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1818_RaspberryPi 5 8GB Desktop NVMe b/testcases/image/1818_RaspberryPi 5 8GB Desktop NVMe
index 274ac27..356c3a9 100644
--- a/testcases/image/1818_RaspberryPi 5 8GB Desktop NVMe
+++ b/testcases/image/1818_RaspberryPi 5 8GB Desktop NVMe
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
@@ -190,6 +213,71 @@
and that the desktop unlocks successfully (without the system hanging).
</dd>
+
+ <dt>
+ Check the CPU clock speed using <code>vcgencmd</code>
+ <ul>
+ <li>Stress the CPU by doing <code>yes > /dev/null &</code></li>
+ <li>Run <code>sudo vcgencmd measure_clock arm</code> after about 5 sec</li>
+ <li>Kill the stress process</li>
+ </ul>
+ </dt>
+ <dd>The output should be around 2.4GHz (obtained from online specs)</dd>
+
+
+ <dt>
+ Run <code>sudo vcmailbox 0x00010004 8 8 0 0</code>
+ </dt>
+ <dd>
+ The output should have the board serial number as the 6th integer.
+ </dd>
+
+
+ <dt>
+ Test <code>dtmerge</code>
+ <ul>
+ <li>Copy the live device tree using <code>dtc -I fs -O dtb -o test.dtb /proc/device-tree</code></li>
+ <li>Use dtmerge to overclock the SD card. <code>dtmerge test.dtb merged.dtb - sd_overclock=62</code></li>
+ <li>Check the contents of the new DTB. <code>dtdiff test.dtb merged.dtb</code></li>
+ <li>Delete both test.dtb and merged.dtb</li>
+ </ul>
+ </dt>
+ <dd>
+ merged.dtb should have <code>brcm,overclock-50 = 0x3e</code> under the SD card device.
+ </dd>
+
+
+ <dt>
+ Test <code>dtoverlay</code>
+ <ul>
+ <li>Run <code>sudo dtoverlay pwm</code></li>
+ <li>Run <code>sudo dtoverlay -l</code></li>
+ </ul>
+ </dt>
+ <dd>The PWM Overlay should show up as loaded. Remove it by running <code>sudo dtoverlay -r pwm</code></dd>
+
+
+ <dt>
+ Test <code>dtparam</code>
+ <ul>
+ <li>Run <code>sudo dtparam sd_overclock=62</code></li>
+ <li>Run <code>sudo dtparam -l</code></li>
+ </ul>
+ </dt>
+ <dd>The sd_overclock parameter should show up as set. Remove it by running <code>sudo dtparam -r 0</code></dd>
+
+
+ <dt>
+ Run <code>sudo pinctrl</code>
+ </dt>
+ <dd>THe output should have status of the GPIO pins.</dd>
+
+
+ <dt>
+ Run <code>sudo raspinfo</code>
+ </dt>
+ <dd>The output should have an information dump about the Pi.</dd>
+
</dl>
<p>If <strong>all</strong> actions produce the expected results listed,
diff --git a/testcases/image/1824_RaspberryPi 5 2GB Post-install b/testcases/image/1824_RaspberryPi 5 2GB Post-install
index 3e77d9e..90bb3a3 100644
--- a/testcases/image/1824_RaspberryPi 5 2GB Post-install
+++ b/testcases/image/1824_RaspberryPi 5 2GB Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
@@ -285,7 +308,7 @@
<dt>
Run <code>sudo pinctrl</code>
</dt>
- <dd>THe output should have status of the GPIO pins.</dd>
+ <dd>The output should have status of the GPIO pins.</dd>
<dt>
diff --git a/testcases/image/1825_RaspberryPi 5 16GB Post-install b/testcases/image/1825_RaspberryPi 5 16GB Post-install
index 292d9b4..2786a9f 100644
--- a/testcases/image/1825_RaspberryPi 5 16GB Post-install
+++ b/testcases/image/1825_RaspberryPi 5 16GB Post-install
@@ -55,6 +55,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Check output of <code>free -h</code>
</dt>
<dd>
diff --git a/testcases/image/1827_RaspberryPi 5 16GB Desktop SD b/testcases/image/1827_RaspberryPi 5 16GB Desktop SD
index 6e88b3a..19eff01 100644
--- a/testcases/image/1827_RaspberryPi 5 16GB Desktop SD
+++ b/testcases/image/1827_RaspberryPi 5 16GB Desktop SD
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1828_RaspberryPi 5 16GB Desktop USB b/testcases/image/1828_RaspberryPi 5 16GB Desktop USB
index f991e91..b0269e6 100644
--- a/testcases/image/1828_RaspberryPi 5 16GB Desktop USB
+++ b/testcases/image/1828_RaspberryPi 5 16GB Desktop USB
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1829_RaspberryPi 5 16GB Desktop NVMe b/testcases/image/1829_RaspberryPi 5 16GB Desktop NVMe
index 097ab58..f9cf89e 100644
--- a/testcases/image/1829_RaspberryPi 5 16GB Desktop NVMe
+++ b/testcases/image/1829_RaspberryPi 5 16GB Desktop NVMe
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1830_RaspberryPi 500 SD b/testcases/image/1830_RaspberryPi 500 SD
index 90dc97a..32b29e1 100644
--- a/testcases/image/1830_RaspberryPi 500 SD
+++ b/testcases/image/1830_RaspberryPi 500 SD
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1831_RaspberryPi 500 USB b/testcases/image/1831_RaspberryPi 500 USB
index 6139a20..9521649 100644
--- a/testcases/image/1831_RaspberryPi 500 USB
+++ b/testcases/image/1831_RaspberryPi 500 USB
@@ -77,6 +77,29 @@
<dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
Launch Settings from
the menu that appears, then "About" in the left panel of the window that
appears
diff --git a/testcases/image/1841_RaspberryPi 500 Post-install b/testcases/image/1841_RaspberryPi 500 Post-install
new file mode 100644
index 0000000..7ba76c0
--- /dev/null
+++ b/testcases/image/1841_RaspberryPi 500 Post-install
@@ -0,0 +1,262 @@
+<!-- Please do not edit this file directly; it was generated with the
+ tools/test_case_gen script using the following configuration as input:
+ definitions/pi_server_cases.xml
+-->
+
+
+ <p>This test case is to be carried out on a Raspberry Pi 500.</p>
+ <p>Follow the installation steps at <a href="https://ubuntu.com/download/iot/installation-media";>
+ IoT installation media</a>
+ </p>
+ <dl>
+
+
+ <dt>
+ After powering on the machine, look at the power LED
+ </dt>
+ <dd>
+ The power LED illuminates and stays illuminated while the kernel continues
+ to boot.
+ </dd>
+
+
+ <dt>
+ After logging in, run <code>systemctl status</code>, and look at the
+ "State:" reported at the top of the output
+ </dt>
+ <dd>
+ State should be reported as "running". In particular, it should
+ <em>not</em> read "degraded".
+ </dd>
+
+
+ <dt>
+ Run <code>sudo flash-kernel</code>
+ </dt>
+ <dd>
+ Exit code is clean (0) and no error messages are reported
+ </dd>
+
+
+ <dt>
+ Run <code>sudo reboot</code>
+ </dt>
+ <dd>
+ System reboots successfully to a login prompt
+ </dd>
+
+
+ <dt>
+ Run <code>sudo shutdown -h now</code>
+ </dt>
+ <dd>
+ System shuts down in a reasonable time (less than a minute)
+ </dd>
+
+
+ <dt>
+ (for 25.10, questing, and onwards only)<br>
+ Create new boot assets and deliberately corrupt them, ensuring that
+ boot fallback operates as expected
+ <ul>
+ <li>Run <code>sudo flash-kernel</code> to write new boot assets to the
+ boot partition</li>
+ <li>Run <code>sudo truncate -s 10M /boot/firmware/vmlinuz</code> to
+ truncate the Linux kernel, corrupting it</li>
+ <li>Run <code>sudo reboot</code></li>
+ <li>Once the system finally returns to a login prompt, run <code>cat
+ /boot/firmware/new/state</code></li>
+ </ul>
+ </dt>
+ <dd>
+ Observe three separate reboots: the first should be relatively short and
+ causes the pi to enter "tryboot" mode. The second should fail with the
+ Linux kernel panicking. The third should be the fallback which should
+ then succeed. The final cat command should print "bad" indicating the
+ new boot assets were found to be faulty.
+ </dd>
+
+
+ <dt>
+ Check output of <code>free -h</code>
+ </dt>
+ <dd>
+ Reported "Mem" under "total" is consistent with a
+ Raspberry Pi 500. It should be in the region of 7.6-7.8GB.
+ </dd>
+
+
+ <dt>
+ Perform a large (300-600MB) file copy to USB storage
+ <ul>
+ <li>Generate a large (500MB) file: <code>dd if=/dev/urandom of=rubbish
+ bs=1M count=500</code></li>
+ <li>Insert a USB stick (appropriately sized) into a spare USB port</li>
+ <li>Make a mount directory: <code>sudo mkdir /mnt/stick</code></li>
+ <li>Mount the stick: <code>sudo mount /dev/sda1 /mnt/stick</code>
+ (modify mount-point as necessary; check <code>sudo dmesg</code>
+ output if unsure)</li>
+ <li>Copy the file: <code>sudo cp rubbish /mnt/stick/</code></li>
+ <li>Unmount the stick: <code>sudo umount /mnt/stick</code></li>
+ <li>Remove the stick from the USB port</li>
+ <li>Re-insert the stick into the USB port</li>
+ <li>Re-mount the stick: <code>sudo mount /dev/sda1 /mnt/stick</code>
+ (again, adjust mount-point as necessary)</li>
+ <li>Compare the copied file to that on the stick: <code>cmp rubbish
+ /mnt/stick/rubbish</code></li>
+ </ul>
+ </dt>
+ <dd>
+ <code>cmp</code> returns 0 and outputs nothing, indicating the files are
+ identical
+ </dd>
+
+
+ <dt>
+ Connect a USB keyboard to one of the USB2 (black) ports
+ </dt>
+ <dd>
+ Verify that keys typed on the keyboard appear on the console
+ </dd>
+
+
+ <dt>
+ Connect a USB keyboard to one of the USB3 (blue) ports
+ </dt>
+ <dd>
+ Verify that keys typed on the keyboard appear on the console
+ </dd>
+
+
+ <dt>
+ With an HDMI monitor that supports audio plugged into
+ the HDMI0 output, and an available MP3 file:
+ <ul>
+ <li>Install ffmpeg and amixer with <code>sudo apt install ffmpeg
+ alsa-utils</code></li>
+ <li>Find the correct card name for the HDMI0 port:
+ <code>cat /proc/asound/cards</code> and note the name in [brackets]
+ for the HDMI0 port</li>
+ <li>Attempt to play your MP3 file with: <code>ffmpeg -i
+ <em>music.mp3</em> -f alsa -ar 22050 default:CARD=<em>name</em></code>
+ substituting <em>name</em> for the card name found during the
+ previous step, and <em>music.mp3</em> for your choice of MP3 file,
+ e.g. <code>ffmpeg -i "Jeff Wayne - War of the Worlds.mp3"
+ -f alsa -ar 22050 default:CARD=vc4hdmi0</code></li>
+ <li>Use <tt>Ctrl+C</tt> or <tt>q</tt> to end playback early, if you
+ wish</li>
+ <li>If you cannot hear anything, first check that the mixer's volume is
+ not set too low; run <code>alsamixer</code>, and adjust the volume
+ (<tt>J</tt> for down, <tt>K</tt> for up) before exiting
+ (<tt>Esc</tt>) and retrying playback</li>
+ </ul>
+ </dt>
+ <dd>Audio can be heard through the device</dd>
+
+
+ <dt>
+ With an HDMI monitor that supports audio plugged into
+ the HDMI1 output, and an available MP3 file:
+ <ul>
+ <li>Install ffmpeg and amixer with <code>sudo apt install ffmpeg
+ alsa-utils</code></li>
+ <li>Find the correct card name for the HDMI1 port:
+ <code>cat /proc/asound/cards</code> and note the name in [brackets]
+ for the HDMI1 port</li>
+ <li>Attempt to play your MP3 file with: <code>ffmpeg -i
+ <em>music.mp3</em> -f alsa -ar 22050 default:CARD=<em>name</em></code>
+ substituting <em>name</em> for the card name found during the
+ previous step, and <em>music.mp3</em> for your choice of MP3 file,
+ e.g. <code>ffmpeg -i "Jeff Wayne - War of the Worlds.mp3"
+ -f alsa -ar 22050 default:CARD=vc4hdmi0</code></li>
+ <li>Use <tt>Ctrl+C</tt> or <tt>q</tt> to end playback early, if you
+ wish</li>
+ <li>If you cannot hear anything, first check that the mixer's volume is
+ not set too low; run <code>alsamixer</code>, and adjust the volume
+ (<tt>J</tt> for down, <tt>K</tt> for up) before exiting
+ (<tt>Esc</tt>) and retrying playback</li>
+ </ul>
+ </dt>
+ <dd>Audio can be heard through the device</dd>
+
+
+ <dt>
+ Check auto-configuration of ethernet
+ <ul>
+ <li>Run <code>ip addr</code></li>
+ <li>Check that a valid IP address is recorded on the eth0 interface</li>
+ <li>Check <code>ping google.com</code> successfully pings a few times
+ (<tt>Ctrl+C</tt> to cancel)</li>
+ </ul>
+ </dt>
+ <dd>
+ The "eth0" interface should have a DHCP
+ assigned IP address and you should be able to ping google.com
+ </dd>
+
+
+ <dt>
+ Configure wifi via netplan
+ <ul>
+ <li>Place the following in <code>/etc/netplan/wifi.yaml</code>
+ (substituting the SSID and password as necessary):</li>
+ <li><pre>
+ network:
+ version: 2
+ wifis:
+ wlan0:
+ dhcp4: true
+ access-points:
+ my-ssid-here:
+ password: my-password-here</pre>
+ </li>
+ <li>Run <code>sudo netplan apply</code></li>
+ <li>Wait a few seconds (to allow DHCP to complete), then run <code>ip
+ addr</code></li>
+ <li>Check that a valid IP address is recorded on the wlan0 interface</li>
+ <li>Check <code>ping google.com</code> successfully pings a few times
+ (<tt>Ctrl+C</tt> to cancel)</li>
+ </ul>
+ </dt>
+ <dd>
+ The "wlan0" interface should have a DHCP
+ assigned IP address and you should be able to ping google.com
+ </dd>
+
+
+ <dt>
+ Configure bluetooth, scan for, and pair, a device
+ <ul>
+ <li>Install bluez with <code>sudo apt install bluez</code></li>
+ <li>Run <code>sudo bluetoothctl</code></li>
+ <li>Check bluetoothctl prints <code>Agent registered</code></li>
+ <li>Check the MAC address looks "real" (not some obviously blank
+ value like AA:AA:AA:AA:AA:AA)</li>
+ <li>Run <code>scan on</code></li>
+ <li>Make some other Bluetooth device visible for pairing (e.g. go into
+ Bluetooth settings on your Android phone)</li>
+ <li>Verify the other Bluetooth device appears in console output</li>
+ <li>Run <code>pair XX:XX:XX:XX:XX:XX</code>
+ where XX:XX:XX:XX:XX:XX is the other device's MAC address, as it
+ appears in scan output
+ </li>
+ <li>Verify the passcode on both devices</li>
+ <li>Check output includes "Pairing successful"</li>
+ <li>Disable scanning with <code>scan off</code></li>
+ <li>Exit tool with <code>quit</code></li>
+ </ul>
+ </dt>
+ <dd>
+ The Bluetooth interface should have a valid MAC address (not
+ AA:AA:AA:AA:AA:AA), can see and pair with another Bluetooth device.
+ </dd>
+
+
+ </dl>
+ <p>If <strong>all</strong> actions produce the expected results listed,
+ please <a href="results#add_result">submit</a> a 'passed' result.</p>
+ <p>If <strong>any</strong> action fails, or produces an unexpected result,
+ please <a href="results#add_result">submit</a> a 'failed' result and <a href="../../buginstructions">file a bug</a>. Please be sure to include
+ the bug number when you <a href="results#add_result">submit</a> your
+ result.</p>
+
\ No newline at end of file
References
