Project

General

Profile

Actions
Copy link

coordination #53249

open

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

Added by jorauch over 5 years ago. Updated 8 months ago.

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

50%

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

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

Subtasks 4 (2 open — 2 closed)

action #59014: [qe-core][functional] Enhanced grub_test moduleNew2020-02-21

Actions
action #59016: [qe-core][functional] Enhance reconnect_mgmt_consoleRejected2020-02-22

Actions
action #59018: [qe-core][functional][needs-refining] Enhance first_bootRejected2020-02-22

Actions
action #63649: [qe-core][functional] Enhanced reboot_after_installationNew2020-02-20

Actions

Related issues 1 (0 open — 1 closed)

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

Actions
Actions
Copy link
 #1

Updated by jorauch over 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
Actions
Copy link
 #2

Updated by jorauch over 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)
Actions
Copy link
 #3

Updated by jorauch over 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
Actions
Copy link
 #4

Updated by jorauch over 5 years ago

  • Status changed from Workable to New

Setting to new as we need AC and a better description

Actions
Copy link
 #5

Updated by jorauch over 5 years ago

  • Assignee deleted (jorauch)
Actions
Copy link
 #6

Updated by SLindoMansilla over 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
Actions
Copy link
 #7

Updated by zluo over 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
Actions
Copy link
 #8

Updated by zluo over 5 years ago

  • Assignee set to zluo

take over

Actions
Copy link
 #9

Updated by zluo over 5 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

Actions
Copy link
 #10

Updated by zluo over 5 years ago

  • Status changed from Workable to In Progress
Actions
Copy link
 #11

Updated by zluo over 5 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)

Actions
Copy link
 #12

Updated by zluo over 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.

Actions
Copy link
 #13

Updated by zluo over 5 years ago

  • Status changed from Workable to In Progress

check reboot_after_installation at first.

Actions
Copy link
 #14

Updated by zluo over 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.

Actions
Copy link
 #15

Updated by zluo over 5 years ago

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

unsign me for now to refine this ticket.

Actions
Copy link
 #16

Updated by SLindoMansilla over 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
Actions
Copy link
 #17

Updated by SLindoMansilla over 5 years ago

  • Description updated (diff)
Actions
Copy link
 #18

Updated by SLindoMansilla over 5 years ago

  • Priority changed from Urgent to Normal

Ready to be picked again for task 3

Actions
Copy link
 #19

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: default@64bit-ipmi
https://openqa.suse.de/tests/3167312

Actions
Copy link
 #20

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: default@64bit-ipmi
https://openqa.suse.de/tests/3167312

Actions
Copy link
 #21

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: default@ppc64le-spvm
https://openqa.suse.de/tests/3251523

Actions
Copy link
 #22

Updated by mgriessmeier over 5 years ago

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

let's move on here ;)

Actions
Copy link
 #23

Updated by szarate over 5 years ago

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

Actions
Copy link
 #24

Updated by szarate over 5 years ago

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

Updated by SLindoMansilla over 5 years ago

Actions
Copy link
 #26

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: default@ppc64le-spvm
https://openqa.suse.de/tests/3340755

Actions
Copy link
 #27

Updated by mgriessmeier over 5 years ago

  • Target version changed from Milestone 27 to Milestone 28
Actions
Copy link
 #28

Updated by okurz about 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: default@ppc64le-spvm
https://openqa.suse.de/tests/3418254

Actions
Copy link
 #29

Updated by okurz about 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: 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
Actions
Copy link
 #30

Updated by maritawerner about 5 years ago

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

Actions
Copy link
 #31

Updated by SLindoMansilla about 5 years ago

  • Priority changed from High to Urgent
Actions
Copy link
 #32

Updated by zluo about 5 years ago

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

take over and check current status

Actions
Copy link
 #33

Updated by zluo about 5 years ago

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

Actions
Copy link
 #34

Updated by zluo about 5 years ago

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

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

Actions
Copy link
 #35

Updated by SLindoMansilla about 5 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.

Actions
Copy link
 #36

Updated by SLindoMansilla about 5 years ago

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

Sorry, my firefox browser went crazy again.

Actions
Copy link
 #37

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

Actions
Copy link
 #38

Updated by SLindoMansilla about 5 years ago

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

Actions
Copy link
 #39

Updated by zluo about 5 years ago

  • Assignee deleted (zluo)
Actions
Copy link
 #40

Updated by zluo about 5 years ago

unassign myself, ready for grooming session.

Setting as New is not possible.

Actions
Copy link
 #41

Updated by mgriessmeier about 5 years ago

  • Status changed from Workable to New
Actions
Copy link
 #42

Updated by SLindoMansilla about 5 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

Actions
Copy link
 #43

Updated by okurz about 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: 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
Actions
Copy link
 #44

Updated by okurz about 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: 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
Actions
Copy link
 #45

Updated by mgriessmeier almost 5 years ago

  • Target version changed from Milestone 28 to Milestone 31
Actions
Copy link
 #46

Updated by SLindoMansilla almost 5 years ago

  • Due date set to 2019-12-03

due to changes in a related task

Actions
Copy link
 #47

Updated by SLindoMansilla almost 5 years ago

  • Due date set to 2019-11-04

due to changes in a related task

Actions
Copy link
 #48

Updated by SLindoMansilla almost 5 years ago

  • Due date set to 2020-02-21

due to changes in a related task

Actions
Copy link
 #49

Updated by SLindoMansilla almost 5 years ago

  • Due date set to 2020-02-22

due to changes in a related task

Actions
Copy link
 #50

Updated by SLindoMansilla almost 5 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

Actions
Copy link
 #51

Updated by mgriessmeier almost 5 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)
Actions
Copy link
 #52

Updated by SLindoMansilla over 4 years ago

  • Assignee changed from mgriessmeier to SLindoMansilla
Actions
Copy link
 #53

Updated by SLindoMansilla over 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?))
Actions
Copy link
 #54

Updated by szarate about 4 years ago

  • Tracker changed from action to coordination
  • Status changed from Workable to New
Actions
Copy link
 #56

Updated by tjyrinki_suse about 4 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
Actions
Copy link
 #57

Updated by SLindoMansilla almost 4 years ago

  • Assignee deleted (SLindoMansilla)

No time to work on this :(

Actions
Copy link
 #58

Updated by maritawerner over 3 years ago

Status update: Sub tasks are not done yet.

Actions
Copy link
 #59

Updated by slo-gin over 2 years 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.

Actions
Copy link

Also available in: Atom PDF