Bug Description
Looking at this RPI5 kernel run on rpi5b8g-003 and the 4th run has a failing test that isn't present at all on previous runs or it is run and I just missed it because the UUID changes on every run?
When usb/storage-preinserted-disk/by-uuid/0227-00EA runs on attempt it appears to fail because it cannot write to the usb device and then dumps a traceback that should be handled with some exception handling.
More confusingly on this system is that the test appears only one time on run 4 with UUID 0227-00EA, then shows twice on run 3 but with two completely different UUIDs, then doesn't show at all on run 2 though presumably the hardware remains the same and the testplan is the same.
This is listed as a blocker.
Cert-blocker Test Case
To Reproduce
rerun the linux-raspi sru for rpi5b8g with the test plan: com.canonical.certification::client-cert-iot-server-24-04-automated
observe the failures in the results and compare to previous runs:
run 4: https://certification.canonical.com/hardware/202512-38180/submission/494806/
run 3: https://certification.canonical.com/hardware/202310-32202/submission/493258/
Run 2: https://certification.canonical.com/hardware/202512-38178/submission/493072/
Expected Result
The job should pass, but if it fails it should at least provide useful feedback and handle the exception being triggered.
Actual Result
job failed becuase it cannot write to the usb device (if I'm reading the output correctly, see below in the log output section)
Traceback should be handled properly
Environment
- 24.04 on rpi5b8g-003
- 7.3.0.dev42 (debs)
- Testplan:
Relevant log output
DEBUG:generating a random file
DEBUG:try to mount usb storage for testing
DEBUG:mount /dev/disk/by-uuid/0227-00EA on /tmp/tmpj7awcl7w successfully.
DEBUG:===================
DEBUG:writing test begins
DEBUG:===================
DEBUG:Apply command: ['dd', 'if=/tmp/tmp_lhd6urj', 'of=/tmp/tmpj7awcl7w/tmp_lhd6urj0', 'bs=1M', 'oflag=sync']
DEBUG:["dd: error writing '/tmp/tmpj7awcl7w/tmp_lhd6urj0': No such device", '1+0 records in', '0+0 records out', '0 bytes copied, 23.7318 s, 0.0 kB/s', '']
INFO:context manager exit: unmount USB storage
INFO:umount /tmp/tmpj7awcl7w successfully.
INFO:Remove temporary folders and files.
Traceback (most recent call last):
File "/usr/bin/checkbox-support-usb_read_write", line 8, in <module>
sys.exit(run_read_write_test())
^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/checkbox_support/scripts/usb_read_write.py", line 147, in run_read_write_test
write_test(random_file)
File "/usr/lib/python3/dist-packages/checkbox_support/scripts/usb_read_write.py", line 272, in write_test
write_speed_list.append(write_test_unit(random_file, str(idx)))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/checkbox_support/scripts/usb_read_write.py", line 315, in write_test_unit
dd_speed = float(list_dd_message[2].split(" ")[-2])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: could not convert string to float: 'records'Additional context
No response
Bug Description
Looking at this RPI5 kernel run on rpi5b8g-003 and the 4th run has a failing test that isn't present at all on previous runs or it is run and I just missed it because the UUID changes on every run?
When usb/storage-preinserted-disk/by-uuid/0227-00EA runs on attempt it appears to fail because it cannot write to the usb device and then dumps a traceback that should be handled with some exception handling.
More confusingly on this system is that the test appears only one time on run 4 with UUID 0227-00EA, then shows twice on run 3 but with two completely different UUIDs, then doesn't show at all on run 2 though presumably the hardware remains the same and the testplan is the same.
This is listed as a blocker.
Cert-blocker Test Case
To Reproduce
rerun the linux-raspi sru for rpi5b8g with the test plan: com.canonical.certification::client-cert-iot-server-24-04-automated
observe the failures in the results and compare to previous runs:
run 4: https://certification.canonical.com/hardware/202512-38180/submission/494806/
run 3: https://certification.canonical.com/hardware/202310-32202/submission/493258/
Run 2: https://certification.canonical.com/hardware/202512-38178/submission/493072/
Expected Result
The job should pass, but if it fails it should at least provide useful feedback and handle the exception being triggered.
Actual Result
job failed becuase it cannot write to the usb device (if I'm reading the output correctly, see below in the log output section)
Traceback should be handled properly
Environment
Relevant log output
Additional context
No response