action #43064
closed[functional][u] test fails in boot_into_snapshot and reboot_gnome with encrypted setup - test not waiting long enough for shutdown/reboot until we end up in grub which shows in post_fail_hook
0%
Description
Updated by okurz over 5 years ago
- Subject changed from [functional][u] test fails in boot_into_snapshot - test not waiting long enough for shutdown/reboot until we end up in grub which shows in post_fail_hook to [functional][u] test fails in boot_into_snapshot and reboot_gnome - test not waiting long enough for shutdown/reboot until we end up in grub which shows in post_fail_hook
also happened in reboot_gnome: https://openqa.suse.de/tests/2222861#step/reboot_gnome/20
Updated by jorauch over 5 years ago
- Assignee set to jorauch
Looks like a ppc issue to me, we could increase the timeout for ppc, wdyt?
Edit: in wait_boot
Updated by okurz over 5 years ago
yes, just bump the timeout. Optional: record soft failure with reference to bug about "waiting in reboot too long", a bug might exist for that as well.
Updated by szarate over 5 years ago
I am smelling performance regression... The passphrase part was kind of slow for me when I tried it, but I disregarded it as it was expected to be slow... however, 300 seconds is a bit too much... :)
Updated by mloviska over 5 years ago
It happened on arm as well
https://openqa.suse.de/tests/2239567#step/reboot_gnome/9
Updated by jorauch over 5 years ago
@mloviska this is after Grub2 is shown, are you sure it is the same issue?
Updated by jorauch over 5 years ago
- Status changed from Workable to Feedback
Since PR is open:
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6149
Putting this to feeback
Updated by szarate over 5 years ago
- Subject changed from [functional][u] test fails in boot_into_snapshot and reboot_gnome - test not waiting long enough for shutdown/reboot until we end up in grub which shows in post_fail_hook to [functional][u] test fails in boot_into_snapshot and reboot_gnome with encrypted setup - test not waiting long enough for shutdown/reboot until we end up in grub which shows in post_fail_hook
It's def not the same issue, martin's scenario is not cryptlvm
Updated by jorauch over 5 years ago
- Status changed from Feedback to In Progress
If this is really a performance regression we have to prove it and open a bug.
According to szarate we should also check the function unlock_if_encrypted
Updated by jorauch over 5 years ago
It also didn't appear for 10 days, maybe it's not happening anymore?
Both fails happened on 447 and I couldn't find any others
I also fail to see how this is an encrypted setup since ENCRYPT is not set in the initally mentioned job -> this could mean we have a problem completely unrelated to encryption
Updated by jorauch over 5 years ago
- Status changed from In Progress to Feedback
- Assignee changed from jorauch to okurz
Since we have three different test cases which seem to have not much in common (2x PPC, 1x ARM, 1x encrypted, 2x not encrypted) I have honestly no clue how to continue here, especially since it does not appear anymore as far as I can say.
Could you please take a look and give some directions?
Updated by okurz over 5 years ago
- Related to action #41306: [sle][functional][u] test fails in reboot_gnome - timeout issue for reboot added
Updated by okurz over 5 years ago
- Status changed from Feedback to Workable
- Assignee changed from okurz to jorauch
- Target version changed from Milestone 20 to Milestone 21
- Focus on "encrypted" cases only
- Focus on ppc64le only for the time being
- As we did only have a handful of SLE12SP4 builds after the original report I recommend to conduct a proper statistical investigation on production
Updated by okurz over 5 years ago
- Related to action #42863: [sle][functional][u] test fails in first_boot - hard to see what is exactly the cause for timeout issue added
Updated by okurz over 5 years ago
- Blocked by action #44144: [functional][y] Rework "boot_into_snapshot" to boot from images and not reconduct whole installation added
Updated by okurz over 5 years ago
- Status changed from Workable to Blocked
- Assignee changed from jorauch to okurz
Updated by okurz over 5 years ago
This is an autogenerated message for openQA integration by the openqa_review script:
This bug is still referenced in a failing openQA test: boot_to_snapshot
https://openqa.suse.de/tests/2242757
Updated by okurz over 5 years ago
- Related to action #43880: [functional][u][s390x][sporadic] test fails in shutdown on s390x added
Updated by okurz over 5 years ago
- Target version changed from Milestone 21 to Milestone 23
Updated by jorauch over 5 years ago
- Related to action #46385: [functional][u][ppc64le] test fails in user_defined_snapshot - just not waiting long enough for grub menu added
Updated by okurz over 5 years ago
- Target version changed from Milestone 23 to Milestone 25
-> #44144
Updated by okurz about 5 years ago
- Assignee changed from okurz to mgriessmeier
Move to new QSF-u PO after I moved to the "tools"-team. I mainly checked the subject line so in individual instances you might not agree to take it over completely into QSF-u. Feel free to discuss with me or reassign to me or someone else in this case. Thanks.
Updated by mgriessmeier almost 5 years ago
- Target version changed from Milestone 25 to Milestone 26
Updated by mgriessmeier almost 5 years ago
- Status changed from Blocked to Resolved
- Target version changed from Milestone 26 to Milestone 27
didnt happen in 12sp5 - since all related are resolved, I assume this as well