Project

General

Profile

coordination #53249

[epic][qe-core][functional] ensure that grub_test gets a booting system

Added by jorauch over 2 years ago. Updated 22 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Spike/Research
Target version:
SUSE QA - Milestone 31
Start date:
2020-02-20
Due date:
% Done:

0%

Estimated time:
(Total: 84.00 h)
Difficulty:

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

  1. Find in which tests scenarios, the following modules are NOT schedule: reboot_after_installation, first_boots
  2. In which scenarios grub_test is schedule, and what is the previous module that was executed?
  3. 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

photo_2019-08-23_14-40-54.jpg (127 KB) photo_2019-08-23_14-40-54.jpg SLindoMansilla, 2019-08-23 12:41
8453

Subtasks

action #59014: [qe-core][functional] Enhanced grub_test moduleNew

action #59016: [qe-core][functional] Enhance reconnect_mgmt_consoleWorkable

action #59018: [qe-core][functional][needs-refining] Enhance first_bootWorkable

action #63649: [qe-core][functional] Enhanced reboot_after_installationNew


Related issues

Related to openQA Tests - action #55832: [functional][u] test fails in first_boot - default boot scenario in spvm ends up in a consoleResolved2019-08-22

History

#1 Updated by jorauch over 2 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

#2 Updated by jorauch over 2 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)

#3 Updated by jorauch over 2 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

#4 Updated by jorauch over 2 years ago

  • Status changed from Workable to New

Setting to new as we need AC and a better description

#5 Updated by jorauch over 2 years ago

  • Assignee deleted (jorauch)

#6 Updated by SLindoMansilla about 2 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

#7 Updated by zluo about 2 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

#8 Updated by zluo about 2 years ago

  • Assignee set to zluo

take over

#9 Updated by zluo about 2 years ago

  1. 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

#10 Updated by zluo about 2 years ago

  • Status changed from Workable to In Progress

#11 Updated by zluo about 2 years ago

  • Status changed from In Progress to Workable
  1. 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)

#12 Updated by zluo about 2 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.

#13 Updated by zluo about 2 years ago

  • Status changed from Workable to In Progress

check reboot_after_installation at first.

#14 Updated by zluo about 2 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.

#15 Updated by zluo about 2 years ago

  • Assignee deleted (zluo)
  • Priority changed from Normal to Urgent

unsign me for now to refine this ticket.

#16 Updated by SLindoMansilla about 2 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

#17 Updated by SLindoMansilla about 2 years ago

  • Description updated (diff)

#18 Updated by SLindoMansilla about 2 years ago

  • Priority changed from Urgent to Normal

Ready to be picked again for task 3

#19 Updated by okurz about 2 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

#20 Updated by okurz about 2 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

#21 Updated by okurz about 2 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

#22 Updated by mgriessmeier about 2 years ago

  • Priority changed from Normal to High
  • Target version changed from Milestone 26 to Milestone 27

let's move on here ;)

#23 Updated by szarate about 2 years ago

I ended up creating a workaround needle for default@spvm, see poo#55832 for details

#24 Updated by szarate about 2 years ago

  • Related to action #55832: [functional][u] test fails in first_boot - default boot scenario in spvm ends up in a console added

#25 Updated by SLindoMansilla about 2 years ago

8453

#26 Updated by okurz about 2 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

#27 Updated by mgriessmeier about 2 years ago

  • Target version changed from Milestone 27 to Milestone 28

#28 Updated by okurz almost 2 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

#29 Updated by okurz almost 2 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:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed

#30 Updated by maritawerner almost 2 years ago

What is the status here? We are almost at GMC? Can we get that fixed?

#31 Updated by SLindoMansilla almost 2 years ago

  • Priority changed from High to Urgent

#32 Updated by zluo almost 2 years ago

  • Assignee set to zluo
  • Priority changed from Urgent to High

take over and check current status

#33 Updated by zluo almost 2 years ago

https://openqa.suse.de/tests/3484629#next_previous shows no failure for first_boot on spvm since 2 months: ppc64le-Build0363-textmode

#34 Updated by zluo almost 2 years ago

but https://openqa.suse.de/tests/3484606 shows failure for test: ppc64le-Build0363-default

grenache-1:5 failed, grenache-1:6 successful.

#35 Updated by SLindoMansilla almost 2 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.

#36 Updated by SLindoMansilla almost 2 years ago

  • Assignee set to zluo
  • Priority changed from Urgent to High

Sorry, my firefox browser went crazy again.

#37 Updated by zluo almost 2 years ago

**

  1. Task: find all modules executed after installation, reboot, boot:

    x86_64:
    grub_test, first_boot

    default@64bit-ipmi
    reconnect_mgmt_console, first_boot

    create_hdd_textmode@svirt-xen-hvm
    grub_test, first_boot

    create_hdd_textmode@svirt-xen-pv
    first_boot

    s390x
    reconnect_mgmt_console, first_boot

    ppc64le
    grub_test, first_boot

    ppc64le-spvm:
    reconnect_mgmt_console, grub_test, first_boot

    aarch64
    grub_test, first_boot

#38 Updated by SLindoMansilla almost 2 years ago

The ticket should be put in new/high to be refined in the next big grooming meeting (Monday?)

#39 Updated by zluo almost 2 years ago

  • Assignee deleted (zluo)

#40 Updated by zluo almost 2 years ago

unassign myself, ready for grooming session.

Setting as New is not possible.

#41 Updated by mgriessmeier almost 2 years ago

  • Status changed from Workable to New

#42 Updated by SLindoMansilla almost 2 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

#43 Updated by okurz almost 2 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:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed

#44 Updated by okurz almost 2 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:

  1. The test scenario is fixed by applying the bug fix to the tested product or the test is adjusted
  2. The openQA job group is moved to "Released"
  3. The label in the openQA scenario is removed

#45 Updated by mgriessmeier over 1 year ago

  • Target version changed from Milestone 28 to Milestone 31

#46 Updated by SLindoMansilla over 1 year ago

  • Due date set to 2019-12-03

due to changes in a related task

#47 Updated by SLindoMansilla over 1 year ago

  • Due date set to 2019-11-04

due to changes in a related task

#48 Updated by SLindoMansilla over 1 year ago

  • Due date set to 2020-02-21

due to changes in a related task

#49 Updated by SLindoMansilla over 1 year ago

  • Due date set to 2020-02-22

due to changes in a related task

#50 Updated by SLindoMansilla over 1 year 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

#51 Updated by mgriessmeier over 1 year 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)

#52 Updated by SLindoMansilla over 1 year ago

  • Assignee changed from mgriessmeier to SLindoMansilla

#53 Updated by SLindoMansilla about 1 year 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?))

#54 Updated by szarate 12 months ago

  • Tracker changed from action to coordination
  • Status changed from Workable to New

#56 Updated by tjyrinki_suse 11 months 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

#57 Updated by SLindoMansilla 6 months ago

  • Assignee deleted (SLindoMansilla)

No time to work on this :(

#58 Updated by maritawerner 3 months ago

Status update: Sub tasks are not done yet.

Also available in: Atom PDF