action #20220
closed[tools][sles][functional] test fails in qa_net_boot_from_hdd - IPMI backend doesn't respond connection lost
0%
Description
Observation¶
openQA test in scenario sle-12-SP3-Server-DVD-x86_64-gnome@64bit-ipmi fails in
qa_net_boot_from_hdd
IPMI backend doesn't respond connection lost.
11:25:29.4952 20638 considering VNC stalled, no update for 4.41 seconds
DIE socket does not exist. Probably your backend instance could not start or died. at /usr/lib/os-autoinst/consoles/VNC.pm line 881.
at /usr/lib/os-autoinst/backend/baseclass.pm line 80.
backend::baseclass::die_handler('socket does not exist. Probably your backend instance could n...') called at /usr/lib/os-autoinst/consoles/VNC.pm line 801
consoles::VNC::catch {...} ('socket does not exist. Probably your backend instance could n...') called at /usr/lib/perl5/vendor_perl/5.18.2/Try/Tiny.pm line 115
Try::Tiny::try('CODE(0x7aa3250)', 'Try::Tiny::Catch=REF(0x7a9ada0)') called at /usr/lib/os-autoinst/consoles/VNC.pm line 803
consoles::VNC::update_framebuffer('consoles::VNC=HASH(0x7a8ead0)') called at /usr/lib/os-autoinst/consoles/vnc_base.pm line 95
consoles::vnc_base::current_screen('consoles::vnc_base=HASH(0x5a2ae78)') called at /usr/lib/os-autoinst/backend/baseclass.pm line 587
backend::baseclass::capture_screenshot('backend::ipmi=HASH(0x675dce0)') called at /usr/lib/os-autoinst/backend/baseclass.pm line 187
eval {...} called at /usr/lib/os-autoinst/backend/baseclass.pm line 156
backend::baseclass::run_capture_loop('backend::ipmi=HASH(0x675dce0)') called at /usr/lib/os-autoinst/backend/baseclass.pm line 129
backend::baseclass::run('backend::ipmi=HASH(0x675dce0)', 6, 9) called at /usr/lib/os-autoinst/backend/driver.pm line 85
backend::driver::start('backend::driver=HASH(0x687f5f8)') called at /usr/lib/os-autoinst/backend/driver.pm line 48
backend::driver::new('backend::driver', 'ipmi') called at /usr/bin/isotovideo line 212
main::init_backend() called at /usr/bin/isotovideo line 276
11:27:36.8044 20638 IPMI: Chassis Power Control: Down/Off
Reproducible¶
Fails since (at least) Build 0374
Expected result¶
Last good: 0373 (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by SLindoMansilla over 7 years ago
Recent example on Build0466: https://openqa.suse.de/tests/1045634
Updated by SLindoMansilla over 7 years ago
- Subject changed from [sles][functional] test fails in qa_net_boot_from_hdd - IPMI backend doesn't respond connection lost to [tools][sles][functional] test fails in qa_net_boot_from_hdd - IPMI backend doesn't respond connection lost
- Category changed from Bugs in existing tests to Infrastructure
Updated by SLindoMansilla over 7 years ago
It is still failing since the last 5 build: osd#1049781#previous
Updated by SLindoMansilla over 7 years ago
- Description updated (diff)
- Status changed from New to In Progress
- Assignee set to SLindoMansilla
Tasks:
- Try to close the ssh connection before rebooting. (easy/quick fix).
- Try to use iKVM backend instead of IPMI.
Updated by SLindoMansilla over 7 years ago
Access data for ex ipmi openqa workers: https://gitlab.suse.de/openqa/salt-pillars-openqa/blob/master/openqa/workerconf.sls#L31
Updated by SLindoMansilla over 7 years ago
- Status changed from In Progress to Feedback
The ex openqa workers were not reliable after several attempts. Too much time invested on this task.
Updated by asmorodskyi over 7 years ago
- Has duplicate action #15370: use_wicked function from y2logsstep fails constantly in IPMI workers added
Updated by asmorodskyi over 7 years ago
Currently issue is blocked by https://infra.nue.suse.com/SelfService/Display.html?id=89258 no point to invest time on it until this one will be fixed
Updated by nicksinger over 7 years ago
- Related to action #23724: [infrastructure][ipmi] openQA is unable to reconnect to quinn (openQA ipmi worker) added
Updated by nicksinger over 7 years ago
The linked infra ticket from @asmorodskyi has been resolved and openqaw3 and openqaw4 should work fine again. However the only IPMI-test we've in SLE Functional is "gnome" right now and this one is pretty unstable -> https://progress.opensuse.org/issues/23774
https://progress.opensuse.org/issues/23368 (and linked ones) take care of their current status so IMHO this bug can be closed as resolved.
Updated by SLindoMansilla over 7 years ago
- Status changed from Feedback to Resolved
Closing as suggested by Nick. It is no more needed that this ticket is still open.