action #103203
closed
openqa.opensuse.org consistently fails to boot from vmdk disk images
Added by dancermak over 2 years ago.
Updated over 2 years ago.
Category:
Feature requests
Description
Observation¶
We are facing some weird issues with vmdk disk images: while openQA can boot from these without issues on my local development machine, it consistently fails to do so on o3. E.g.: https://openqa.opensuse.org/tests/2062448, https://openqa.opensuse.org/tests/2062446. This issue appears to be also intermingled with asset download failures on o3, which troubled the vmdk disk image group, but this did not appear anymore in the last run.
Steps to reproduce locally¶
git clone https://github.com/OSInside/kiwi-functional-testspoetry installpoetry run ./settings.py --server $MY_INSTANCE --server-scheme http
and then clone one of the failing jobs or schedule a full test run (this will schedule many jobs):
poetry run ./schedule_test_run.py --server $MY_INSTANCE --server-scheme http -vd Tumbleweed+opensuse --use-https-for-asset-download
Steps to reproduce remotely¶
- clone the failed openQA job on o3 directly
Problem¶
openQA appears to be unable to boot from the vmdk disk images: they are not considered to be bootable devices by the BIOS/EFI firmware (this is independent of whether we are booting from BIOS or EFI).
Suggestion¶
Sadly, none.
Workaround¶
None known.
- Category set to Regressions/Crashes
- Target version set to Ready
- Status changed from New to Feedback
- Assignee set to okurz
- Priority changed from Normal to Low
asmorodskyi wrote:
okurz wrote:
Hi @dancermak, you could help us a lot if you can adapt the ticket description according to https://progress.opensuse.org/projects/openqav3/wiki/#Defects and at best also add information regarding any "last good". In https://github.com/OSInside/kiwi-functional-tests/issues/9#issuecomment-979092064 asmorodskyi mentioned that the problem might be a recent regression as an older version might have still worked for you?
Not sure that it will be right thing to do . The tricky part that in such a case "last good" will be in one machine ( Dan's personal instance ) and described failure in another ( o3 ). AFAIK it never worked on o3 ...
You are absolutely correct: there is really no "last good", I was never able to get this to run on o3. The tests might have worked in the past, but don't have any records of past runs any more, because there were far too many random failures (they turned out to be caused by my silliness, but that's a different story…).
- Description updated (diff)
- Category changed from Regressions/Crashes to Feature requests
- Status changed from Feedback to New
- Assignee deleted (
okurz)
- Target version changed from Ready to future
ok, thx. Considering that this does not seem to be a recent regression I can't make promises when or if we would look into this anytime soon.
- Status changed from New to Resolved
Also available in: Atom
PDF