-
-
Notifications
You must be signed in to change notification settings - Fork 108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UEFI test #626
UEFI test #626
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #626 +/- ##
=======================================
Coverage 69.32% 69.32%
=======================================
Files 58 58
Lines 12005 12005
=======================================
Hits 8323 8323
Misses 3682 3682
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
The test failed for several reasons:
After fixing all the above, it still fails - the VM starts, but it has only black window and no grub. Doesn't react for typing "halt" - and that's what makes the test fail (VM doesn't shutdown when it should). |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024111405-4.3&flavor=pull-requests Test run included the following:
New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2024091704-4.3&flavor=update
Failed tests5 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/112766#dependencies 201 fixed
Unstable tests
|
Is this something that should be handled by this PR, or is it the responsibility of the test runner?
That is strange. I did a test that should be equivalent and that test does pass:
This was on R4.2, though. Can you recheck on R4.2 and see if the test passes there? If it passes on R4.2 I suspect a regression in R4.3. |
Nothing to do here.
I can try |
Ok, I think I know what the issue is. Or rather, two issues:
The first one is why I haven't noticed it actually worked eventually. The second one is the reason why test fails often (but it does passes from time to time. And when it fails (and with |
This is actually a regression compared to my (patched) R4.2, where it does show up provided one puts the UEFI firmware file where Xen will find it.
Should I work around this by increasing the timeout? |
Interestingly, it does show up on a VM console (click any of the failures in in the bot comment, go to logs tab and see the guest-test-inst-appvm.log). Maybe the test could check for that? Sounds more reliable check if it worked than checking if typing "halt" did something (that could be also VM crashing just after startup...). This should also help with typing "halt" too early. Technically, it could open the log after starting the VM see to the end and look back for grub messages until last "Logfile Opened" line (and repeat the search with some timeout). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the 50s timeout is not pretty but it works reliably now, so lets do it this way for now
UEFI VMs didn't boot. Add a test to ensure they do.