action #44345
closed[functional][u] test fails in first_boot - Implement workaround to try to login instead of just pressing escape and hoping for the best
0%
Description
Observation¶
When a test fails in the first_boot module, and there are no users logged in yet, we still try to press esc key to see if there's the possibility that "something" is hidden by the bootloader, but this is simply a blind attempt.
openQA test in scenario sle-15-SP1-Installer-DVD-aarch64-create_hdd_gnome@aarch64 fails in
first_boot
Reproducible¶
Fails since (at least) Build 102.1 (current job)
Expected result¶
Last good: 101.2 (or more recent)
Suggestions¶
- Keep the escape
- Try to switch to root console and try to log in (Ensure we can clean the line, just in case [^ is found)
- If switching to the root console didn't work, switch to tty 1 and try to log in there...
Further details¶
Always latest result in this scenario: latest
Updated by SLindoMansilla over 5 years ago
- Target version set to Milestone 22
It is failing since 12 builds ago: https://openqa.suse.de/tests/2317867#next_previous
Updated by okurz over 5 years ago
- Due date set to 2019-02-12
pre-fill last sprint in M22 with all tickets within milestone not yet assigned to sprints
Updated by okurz over 5 years ago
- Subject changed from [functional][u][y] test fails in first_boot - Implement workaround to try to login instead of just pressing escape and hoping for the best to [functional][u] test fails in first_boot - Implement workaround to try to login instead of just pressing escape and hoping for the best
- Description updated (diff)
- Status changed from New to Feedback
- Assignee set to szarate
The original test fails in https://openqa.suse.de/tests/2279290/modules/first_boot/steps/7 because we expect a display manager but only the login prompt is shown. The reason is a product bug. I am not sure what you consider wrong here from the test point of view. I am not sure if it would be a good idea if the test module "first_boot", which only checks if we reach the right target in the happy case and actually does not log into a console, would try to login but in the failed case.
Updated by szarate about 5 years ago
- Assignee changed from szarate to okurz
@okurz The reasoning for that is:
If we hope for the best, and don't do anything else... We miss the whole point of using automated testing.
- System didn't boot, why?
- System booted, didn't reach the expected login screen, why?
- System booted, login screen is there, we can't do anything else, why?
I see a lot of value AT LEAST trying to answer those questions, and we already have all the bits and pieces to answer these questions, which would reduce the ammount of time wasted in bug investigation "trying to figure out how to reproduce and get logs"
Updated by okurz about 5 years ago
- Is duplicate of action #32683: [sle][functional][u][medium] Implement proper post_fail_hook for boot_to_desktop added
Updated by okurz about 5 years ago
- Status changed from Feedback to Rejected
Absolutely makes sense. I am totally looking for the same. Do you agree that this is a duplicate of #32683 then? If not please reopen, assign to yourself or me and set to blocked until we have the other completed.