coordination #53249
open[epic][qe-core][functional] ensure that grub_test gets a booting system
Added by jorauch almost 5 years ago. Updated over 1 year ago.
0%
Description
Description¶
Sometimes it happens that the system is not yet shutdown and rebooting from the previous module when entering grub_test.
This has been seen after trying to workaround the missed tiano core screen on aarch64: https://openqa.opensuse.org/tests/940347#step/grub_test/1
We need to ensure that the booting is in progress as soon as we enter grub_test
Acceptance criteria¶
- AC1: The tasks 1, 2 and 3 are done before changing the code.
- AC2: This ticket is refined again after tasks 1, 2 and 3 are done.
- AC3: The problem is fixed.
Tasks¶
- Find in which tests scenarios, the following modules are NOT schedule: reboot_after_installation, first_boots
- In which scenarios grub_test is schedule, and what is the previous module that was executed?
- Find all modules executed after installation, reboot, boot
- Migrate the data in the picture to confluence (do NOT upload the picture)
. *Unify all the scenarios to use wait_boot not to be done yet
Files
| photo_2019-08-23_14-40-54.jpg (127 KB) photo_2019-08-23_14-40-54.jpg | SLindoMansilla, 2019-08-23 12:41 |
Updated by jorauch almost 5 years ago
- Copied from action #49751: [functional][u] test fails in grub_test - isotovideo missed the boot screen while worker-host was likely under heavy load added
Updated by jorauch almost 5 years ago
- Copied from deleted (action #49751: [functional][u] test fails in grub_test - isotovideo missed the boot screen while worker-host was likely under heavy load)
Updated by jorauch almost 5 years ago
- Blocks action #49751: [functional][u] test fails in grub_test - isotovideo missed the boot screen while worker-host was likely under heavy load added
Updated by jorauch almost 5 years ago
- Status changed from Workable to New
Setting to new as we need AC and a better description
Updated by SLindoMansilla almost 5 years ago
- Description updated (diff)
- Category changed from Enhancement to existing tests to Spike/Research
- Status changed from New to Workable
- Priority changed from High to Normal
- Target version changed from Milestone 25 to Milestone 26
Updated by zluo almost 5 years ago
- Blocks coordination #23650: [sle][functional][ipmi][epic][u] Fix test suite gnome to work on ipmi 12-SP3 and 15 (WAS: test fails in boot_from_pxe - connection refused trying to ipmi host over ssh?) added
Updated by zluo almost 5 years ago
- Find in which tests scenarios, the following modules are NOT schedule: reboot_after_installation, first_boot
boot_to_snapshot -> first_boot is scheduled, but reboot_after_installation is not, of course.
all extra_tests
memtest
pcm_aws_validation
pcm_azure_validation
pcm_googlecloud
qemu
rescue_system_sle11sp4
toolchain_zypper
toolkits_sle12
Updated by zluo almost 5 years ago
- Status changed from In Progress to Workable
- In which scenarios grub_test is schedule, and what is the previous module that was executed?
well, all tests starting with installation have grub_test except the scenarios mentioned above: http://openqa.suse.de/tests/overview?distri=sle&version=12-SP5&build=0222&groupid=139
reboot_after_installation is scheduled, but for s390 and ipmi we have reconnect_mgmt_console after reboot_after_installation, instead of grub_test.
for example:
http://openqa.suse.de/tests/3052951
http://openqa.suse.de/tests/3058673 (failed at first_boot, because grub_test started before first_boot?)
for spvm we have reboot_after_installation, reconnect_mgmt_console before grub_test and first_boot.
for example:
http://openqa.suse.de/tests/3052657 (looks good atm)
Updated by zluo almost 5 years ago
I think this issue with booting system for grub_test is related also to performance issue of worker.
In most cases they are fine.
reboot_after_installation
grub_test / reconnect_mgmt_console
first_boot
reboot_after_installation covers already first_boot if it contains installation tests.
Updated by zluo almost 5 years ago
- Status changed from Workable to In Progress
check reboot_after_installation at first.
Updated by zluo almost 5 years ago
- Status changed from In Progress to Workable
https://openqa.suse.de/tests/3053111/modules/reboot_after_installation/steps/1/edit
shows that needle tag 'installation' which is only about 'Help' button needs to be checked, yast-still-running contains it, so it means that rebooting started, but we are not sure at this stage whether reboot works or how it will take.
The needle "installation" is not good because we have to check at least string "rebooting now", and maybe to solve the issue we need to check something which can tell us that system is booting up successfully.
Updated by zluo almost 5 years ago
- Assignee deleted (
zluo) - Priority changed from Normal to Urgent
unsign me for now to refine this ticket.
Updated by SLindoMansilla almost 5 years ago
- Subject changed from [functional][u] ensure that grub_test gets a booting system to [functional][u][epic] ensure that grub_test gets a booting system
Updated by SLindoMansilla almost 5 years ago
- Priority changed from Urgent to Normal
Ready to be picked again for task 3
Updated by okurz over 4 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: default@64bit-ipmi
https://openqa.suse.de/tests/3167312
Updated by okurz over 4 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: default@64bit-ipmi
https://openqa.suse.de/tests/3167312
Updated by okurz over 4 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: default@ppc64le-spvm
https://openqa.suse.de/tests/3251523
Updated by mgriessmeier over 4 years ago
- Priority changed from Normal to High
- Target version changed from Milestone 26 to Milestone 27
let's move on here ;)
Updated by szarate over 4 years ago
I ended up creating a workaround needle for default@spvm, see poo#55832 for details
Updated by szarate over 4 years ago
- Related to action #55832: [functional][u] test fails in first_boot - default boot scenario in spvm ends up in a console added
Updated by SLindoMansilla over 4 years ago
- File photo_2019-08-23_14-40-54.jpg photo_2019-08-23_14-40-54.jpg added
- Subject changed from [functional][u][epic] ensure that grub_test gets a booting system to [functional][u] ensure that grub_test gets a booting system
- Description updated (diff)
- Estimated time set to 42.00 h
Updated by okurz over 4 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: default@ppc64le-spvm
https://openqa.suse.de/tests/3340755
Updated by mgriessmeier over 4 years ago
- Target version changed from Milestone 27 to Milestone 28
Updated by okurz over 4 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: default@ppc64le-spvm
https://openqa.suse.de/tests/3418254
Updated by okurz over 4 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: default@ppc64le-spvm
https://openqa.suse.de/tests/3484606
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by maritawerner over 4 years ago
What is the status here? We are almost at GMC? Can we get that fixed?
Updated by SLindoMansilla over 4 years ago
- Priority changed from High to Urgent
Updated by zluo over 4 years ago
- Assignee set to zluo
- Priority changed from Urgent to High
take over and check current status
Updated by zluo over 4 years ago
https://openqa.suse.de/tests/3484629#next_previous shows no failure for first_boot on spvm since 2 months: ppc64le-Build0363-textmode
Updated by zluo over 4 years ago
but https://openqa.suse.de/tests/3484606 shows failure for test: ppc64le-Build0363-default
grenache-1:5 failed, grenache-1:6 successful.
Updated by SLindoMansilla over 4 years ago
- Assignee deleted (
zluo) - Priority changed from High to Urgent
Please, don't forget ACs and Tasks. This ticket is not about fixing failures in first_boot, but about researching and refactoring ;)
The expected outcome is that after this refactoring, we will be able to fix those failures.
Updated by SLindoMansilla over 4 years ago
- Assignee set to zluo
- Priority changed from Urgent to High
Sorry, my firefox browser went crazy again.
Updated by zluo over 4 years ago
**
Task: find all modules executed after installation, reboot, boot:
x86_64:
grub_test, first_bootdefault@64bit-ipmi
reconnect_mgmt_console, first_bootcreate_hdd_textmode@svirt-xen-hvm
grub_test, first_bootcreate_hdd_textmode@svirt-xen-pv
first_boots390x
reconnect_mgmt_console, first_bootppc64le
grub_test, first_bootppc64le-spvm:
reconnect_mgmt_console, grub_test, first_bootaarch64
grub_test, first_boot
Updated by SLindoMansilla over 4 years ago
The ticket should be put in new/high to be refined in the next big grooming meeting (Monday?)
Updated by zluo over 4 years ago
unassign myself, ready for grooming session.
Setting as New is not possible.
Updated by SLindoMansilla over 4 years ago
- Subject changed from [functional][u] ensure that grub_test gets a booting system to [epic][functional][u] ensure that grub_test gets a booting system
- Status changed from New to Workable
- Assignee set to mgriessmeier
See subtasks
Updated by okurz over 4 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: default@ppc64le-spvm
https://openqa.suse.de/tests/3576096
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by okurz over 4 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: skip_registration+workaround_modules@s390x-zVM-ctc
https://openqa.suse.de/tests/3698912
To prevent further reminder comments one of the following options should be followed:
- The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
- The openQA job group is moved to "Released"
- The label in the openQA scenario is removed
Updated by mgriessmeier over 4 years ago
- Target version changed from Milestone 28 to Milestone 31
Updated by SLindoMansilla over 4 years ago
- Due date set to 2019-12-03
due to changes in a related task
Updated by SLindoMansilla over 4 years ago
- Due date set to 2019-11-04
due to changes in a related task
Updated by SLindoMansilla about 4 years ago
- Due date set to 2020-02-21
due to changes in a related task
Updated by SLindoMansilla about 4 years ago
- Due date set to 2020-02-22
due to changes in a related task
Updated by SLindoMansilla about 4 years ago
- Due date set to 2020-02-22
- Start date changed from 2019-11-04 to 2020-02-20
due to changes in a related task
Updated by mgriessmeier about 4 years ago
- Blocks deleted (action #49751: [functional][u] test fails in grub_test - isotovideo missed the boot screen while worker-host was likely under heavy load)
Updated by SLindoMansilla almost 4 years ago
- Assignee changed from mgriessmeier to SLindoMansilla
Updated by SLindoMansilla almost 4 years ago
- Blocks deleted (coordination #23650: [sle][functional][ipmi][epic][u] Fix test suite gnome to work on ipmi 12-SP3 and 15 (WAS: test fails in boot_from_pxe - connection refused trying to ipmi host over ssh?))
Updated by szarate over 3 years ago
- Tracker changed from action to coordination
- Status changed from Workable to New
Updated by szarate over 3 years ago
See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html
Updated by tjyrinki_suse over 3 years ago
- Subject changed from [epic][functional][u] ensure that grub_test gets a booting system to [epic][qe-core][functional] ensure that grub_test gets a booting system
Updated by SLindoMansilla about 3 years ago
- Assignee deleted (
SLindoMansilla)
No time to work on this :(
Updated by maritawerner almost 3 years ago
Status update: Sub tasks are not done yet.
Updated by slo-gin over 1 year ago
This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.