action #45362
closed[functional][u][ipmi][sporadic] Key press doesn't reach the system
0%
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
Updated by okurz over 5 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
Updated by okurz over 5 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
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/2343792
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/2382494
Updated by mgriessmeier about 5 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
Updated by mgriessmeier about 5 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
Updated by mgriessmeier about 5 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?
Updated by mgriessmeier about 5 years ago
following proposal: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/6646
Updated by mgriessmeier about 5 years ago
- Status changed from Workable to In Progress
- Assignee set to mgriessmeier
Updated by okurz about 5 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.
Updated by mgriessmeier about 5 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
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: btrfs@64bit-ipmi
https://openqa.suse.de/tests/2444052
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: btrfs@64bit-ipmi
https://openqa.suse.de/tests/2494631
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: btrfs@64bit-ipmi
https://openqa.suse.de/tests/2549913
Updated by okurz almost 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
Updated by JERiveraMoya almost 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
Updated by okurz almost 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.
Updated by mgriessmeier almost 5 years ago
- Related to action #48380: [qe-core][opensuse][functional][aarch64][sporadic] test fails in multiple modules on cryptlvm test - lost keystrokes added
Updated by SLindoMansilla about 4 years ago
- Status changed from Blocked to Rejected
- Assignee changed from mgriessmeier to SLindoMansilla
It is a bug