Sv boot test part1

[miczyg1]

No description provided.

[miczyg1]

Command used to run QEMU for these tests: HDD_PATH=~/dts-base-image-v2.5.0.wic ./scripts/ci/qemu-run.sh graphic os

Mounting USB disk image is not yet there so I had to specify the DTS image manually from the start.

[miczyg1]

Logs from running the tests on revision 4a84254
sv_boot_log.zip

[macpijan]

Should it fix this run failure as well: Dasharo/coreboot#705 (comment) ?

EDIT:

OK, I think not, I can see that mostly the new suite is added here.

[miczyg1]

Should it fix this run failure as well: Dasharo/coreboot#705 (comment) ?

EDIT:

OK, I think not, I can see that mostly the new suite is added here.

No it won't. When wizard is enabled, the boot flow is different and no regular test will work.

[macpijan]

Do we have a relevant issue to be linked here?

@philipanda just recently replaced UEFI shell with disk detection in boot manager tests here: https://github.com/Dasharo/open-source-firmware-validation/pull/859/files#diff-f69b8b427ce0b5b677a07ffe9a4c20976614e4b5975fecb2e8bdc9a61371097aR135

It even passes on your PR: https://github.com/Dasharo/open-source-firmware-validation/actions/runs/15976860721/job/45061516534#step:11:31

Though I can see a different kwd is used, so maybe the internals of Mount USB Disk Image for QEMU needs fixing?

[philipanda]

The Mount USB Disk Image keyword first removes the drive from QEMU and only then mounts it. CI just mounts it right away. Maybe the keyword fails because there is nothing to remove. I can't really tell from the description and without the logs.

[miczyg1]

This time I tried and it worked, but changed nothing in the code except uncommenting this line...

Also I started the QEMU with graphic firmware instead of graphic os

[miczyg1]

Now that I want to start QEMU again I get either:

access denied by acl file
qemu-system-x86_64: -netdev bridge,id=vmnic,br=br0: bridge helper failed

Or:

failed to get mtu of bridge `br0': No such device
qemu-system-x86_64: -netdev bridge,id=vmnic,br=br0: bridge helper failed

But it worked before...

[philipanda]

I've been experimenting with qemu-run.sh to conditionally use a bridged interface so that the machines can connect to our NFSes here https://github.com/Dasharo/open-source-firmware-validation/blob/qemu-run-install-windows/scripts/ci/qemu-run.sh#L169-L174

Seems it was partially merged by mistake in this commit fc455d8

You can either create a bridge named br0, so that the QEMU VM will be connected to the local network, or revert the changes: https://github.com/Dasharo/open-source-firmware-validation/pull/923/files

[miczyg1]

I guess if the base already changed, everything may or may not work anymore...

[macpijan]

Rebasing to see if/what would be picked up by the tests on HW.

[macpijan]

So if we look at the logs from run on HW there are a couple of problems: https://github.com/Dasharo/open-source-firmware-validation/actions/runs/16071833981/job/45358037556

1. Do we need Dialogs in this suite?

[ ERROR ] Error in file '/home/user/actions-runner/_work/open-source-firmware-validation/open-source-firmware-validation/dasharo-security/sovereign-boot.robot' on line 3: Importing library 'robot.libraries.Dialogs' failed: ImportError: libtk8.6.so: cannot open shared object file: No such file or directory

2. New flag not included in pcengines config?

SVB001.001 Sovereign Boot Wizard shows up on first boot :: This te... | FAIL |
Parent suite setup failed:
Variable '${SOVEREIGN_BOOT_SUPPORT}' not found.

3. Not related to this MR, but we have also problem with combination of PC Engines + XCP NG flag:

@wiktormowinski @filipleple Is it from your latest tests?

USB002.401 USB keyboard detection in OS (ESXi) :: Verify that an e... | FAIL |
Variable '${TESTS_IN_ESXI_SUPPORT}' not found. Did you mean:
    ${TESTS_IN_HEADS_SUPPORT}

4. Also not related to this MR:

USB002.001 USB keyboard detected in FW :: Check whether the extern... | FAIL |
Option UEFI Shell not found in the list

Should this still be a problem @philipanda ?

5. MSI was not responsive at all and no tests have been executed there @philipanda 😞

6. Maybe not a problem, more of a question to @philipanda - why the SVB suite was scheduled to run on PC Engines, but not on MSI? Only USB suite was scheduled on MSI, but both have been scheduled on PC Engines.

[philipanda]

Should this still be a problem @philipanda ?

If no one has modified the test to not depend on UEFI shell in that test, then yes. I've only removed the dependency from qemu self-tests.

MSI was not responsive at all and no tests have been executed there @philipanda 😞

That's sad, we might switch to the Odroid faster than I thought. It was working fine just yesterday.

Maybe not a problem, more of a question to @philipanda - why the SVB suite was scheduled to run on PC Engines, but not on MSI? Only USB suite was scheduled on MSI, but both have been scheduled on PC Engines.

Actually, there were three runs despite there being only two platforms. Both suites were run on both of them, but on MSI they were split into two runs... I'd say that's a problem - a bug, and it might cause serious issues as the runs are being executed in parallel, but only one can access the device at a time. I suspect this might the cause of MSI being "unresponsive".

*Edit Ah, I see. The PiKVM of MSI was replaced and got a new IP address. I've updated the IP only in the config for modifying test cases. The config for modifying libraries was left intact. That's why the third run says there is no route to host.

[philipanda]

@macpijan The hardware regression scheduling was fixed here: #925