Project

General

Profile

Actions

action #45362

closed

[functional][u][ipmi][sporadic] Key press doesn't reach the system

Added by riafarov about 6 years ago. Updated over 4 years ago.

Status:
Rejected
Priority:
Normal
Category:
Bugs in existing tests
Target version:
Start date:
2018-12-19
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

In the logs we have key pressed:
[2018-12-19T09:37:58.591 CET] [debug] /var/lib/openqa/cache/openqa.suse.de/tests/sle/tests/installation/grub_test.pm:103 called testapi::send_key
[2018-12-19T09:37:58.591 CET] [debug] <<< testapi::send_key(key='ret', do_wait=0)

However, we so not start to boot.

openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-btrfs@64bit-ipmi fails in
first_boot

Reproducible

Fails since (at least) Build 128.1

Expected result

Last good: 126.1 (or more recent)

Further details

Always latest result in this scenario: latest


Related issues 3 (1 open2 closed)

Related to openQA Tests (public) - action #48380: [qe-core][opensuse][functional][aarch64][sporadic] test fails in multiple modules on cryptlvm test - lost keystrokesBlocked2019-02-25

Actions
Blocked by openQA Tests (public) - action #36027: [sle][functional][u][ipmi] test fails in boot_from_pxe - pxe boot menu doesn't show up at allResolvedxlai2017-10-20

Actions
Blocks openQA Tests (public) - action #41237: [functional][u][ipmi] test fails in first_boot after system shows text tty login prompt but fails to connect to machine over SSH -> need better post_fail_hook or retry, compare to s390x approachRejectedSLindoMansilla2018-09-19

Actions
Actions #1

Updated by okurz about 6 years ago

  • Blocked by action #36027: [sle][functional][u][ipmi] test fails in boot_from_pxe - pxe boot menu doesn't show up at all added
Actions #2

Updated by okurz about 6 years ago

  • Subject changed from [functional[ipmi][sporadic] Key press doesn't reach the system to [functional][u][ipmi][sporadic] Key press doesn't reach the system
  • Status changed from New to Blocked
  • Assignee set to okurz
  • Target version set to future

hm, the tags were kinda broken, "[functional" with no closing "]" and also no team-assignment. I suggest to always assign to a team so that nothing falls between the backlogs of the teams. In the "worst" case we could set "[y][u]". Or just pick one and we can shift around when we agree that it does not fit for one team but the other. I tag with "[u]" as this is where I think we track the most IPMI ones

Actions #3

Updated by okurz almost 6 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: btrfs@64bit-ipmi
https://openqa.suse.de/tests/2343792

Actions #4

Updated by okurz almost 6 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: btrfs@64bit-ipmi
https://openqa.suse.de/tests/2382494

Actions #5

Updated by mgriessmeier almost 6 years ago

  • Blocks action #41237: [functional][u][ipmi] test fails in first_boot after system shows text tty login prompt but fails to connect to machine over SSH -> need better post_fail_hook or retry, compare to s390x approach added
Actions #6

Updated by mgriessmeier almost 6 years ago

  • Status changed from Blocked to Workable
  • Assignee deleted (okurz)

I think we can work on this again, even if blocker ticket is not resolved yet - but the last 12 runs were hitting this bug.

hope you're fine if I unassign you @okurz

Actions #7

Updated by mgriessmeier almost 6 years ago

according to a statement of the machine maintainers, we sometimes see issues with this hardware and losing keys.
I would propose to just send the return key 10 times to workaround this.
I see no point in opening a bug for shitty hardware
wdyt?

Actions #9

Updated by mgriessmeier almost 6 years ago

  • Status changed from Workable to In Progress
  • Assignee set to mgriessmeier
Actions #10

Updated by okurz almost 6 years ago

mgriessmeier wrote:

I think we can work on this again, even if blocker ticket is not resolved yet - but the last 12 runs were hitting this bug.

hope you're fine if I unassign you @okurz

Actually no. If we are missing a key in the bootloader then would we not also miss a key elsewhere? I strongly recommend to work on the blocker #36027 properly first. Yes, that means good statistics :) We should first see if the MC is more stable with the approach by xlai. Then we can see if we really need a special approach for just the grub menu or is it rather all key presses sent over the IPMI which we might be able to handle better in the backend.

Actions #11

Updated by mgriessmeier almost 6 years ago

  • Status changed from In Progress to Blocked
  • Assignee changed from mgriessmeier to okurz

okurz wrote:

mgriessmeier wrote:

I think we can work on this again, even if blocker ticket is not resolved yet - but the last 12 runs were hitting this bug.

hope you're fine if I unassign you @okurz

Actually no. If we are missing a key in the bootloader then would we not also miss a key elsewhere? I strongly recommend to work on the blocker #36027 properly first. Yes, that means good statistics :) We should first see if the MC is more stable with the approach by xlai. Then we can see if we really need a special approach for just the grub menu or is it rather all key presses sent over the IPMI which we might be able to handle better in the backend.

fine, I will keep the WIP PR open nevertheless

Actions #12

Updated by okurz almost 6 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: btrfs@64bit-ipmi
https://openqa.suse.de/tests/2444052

Actions #13

Updated by okurz almost 6 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: btrfs@64bit-ipmi
https://openqa.suse.de/tests/2494631

Actions #14

Updated by okurz almost 6 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: btrfs@64bit-ipmi
https://openqa.suse.de/tests/2549913

Actions #15

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

Actions #16

Updated by JERiveraMoya over 5 years ago

For GMC it is found that when exiting PXE boot seems stuck, no going to grub for sle15: https://openqa.suse.de/tests/2874691

Actions #17

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

Actions #18

Updated by mgriessmeier over 5 years ago

  • Related to action #48380: [qe-core][opensuse][functional][aarch64][sporadic] test fails in multiple modules on cryptlvm test - lost keystrokes added
Actions #19

Updated by SLindoMansilla over 4 years ago

  • Status changed from Blocked to Rejected
  • Assignee changed from mgriessmeier to SLindoMansilla

It is a bug

Actions

Also available in: Atom PDF