action #48485

[ipmi] test fails in login_console; Not even select xen menuentry

Added by michalnowak about 1 year ago. Updated about 1 year ago.

Status:ResolvedStart date:27/02/2019
Priority:NormalDue date:
Assignee:xlai% Done:

0%

Category:Bugs in existing tests
Target version:-
Difficulty:
Duration:

Description

Observation

openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-gi-guest_developing-on-host_developing-xen@64bit-ipmi fails in
login_console

There are odd characters on login prompt: [B[B[B[B[B[B[B[B[B[B[B[B

Maybe IPMI needs reset?

Reproducible

Fails since (at least) Build 178.3

Expected result

Last good: 178.1 (or more recent)

Further details

Always latest result in this scenario: latest

History

#1 Updated by cachen about 1 year ago

There are odd characters on login prompt: [B[B[B[B[B[B[B[B[B[B[B[B


Maybe IPMI needs reset?

very possible, it looks like suck in "send_key 'up'" and 'down'

     if (get_var("XEN") || check_var("HOST_HYPERVISOR", "xen")) {
         #send key 'up' to stop grub timer counting down, to be more robust to select xen
         send_key 'up';
         save_screenshot;
         send_key_until_needlematch("virttest-bootmenu-xen-kernel", 'down', 10, 5);
     }

#2 Updated by xlai about 1 year ago

  • Status changed from New to Rejected
Yes, I agree with calen. This is likely ipmi unstable again. So close it.

Please forget my previous comment. After debug further, actually it is likely that the change on following code leads to the failure on nearly all xen tests during selecting xen menuentry. Some people recently changes wait_grub. So it needs automation code fix actually.

 # Wait for bootload for the first time.
 $self->wait_grub(bootloader_time => 210);
 send_key 'ret';

From my view, our tests can skip the wait_grub which shared by many people and code changes from time to time. We can just use asssert_screen('grub', $timeout) to skip the influence by others.

#3 Updated by xlai about 1 year ago

  • Status changed from Rejected to Workable

#4 Updated by xlai about 1 year ago

  • Assignee set to waynechen55

@wayne, would you please help to take this ticket to solve the issue on booting to xen?

#5 Updated by waynechen55 about 1 year ago

  • Assignee changed from waynechen55 to xlai

xlai wrote:

@wayne, would you please help to take this ticket to solve the issue on booting to xen?

I have no time to take it. @xlai.

#6 Updated by xlai about 1 year ago

waynechen55 wrote:

xlai wrote:

@wayne, would you please help to take this ticket to solve the issue on booting to xen?


I have no time to take it. @xlai.

Fine. I will take it then.

#7 Updated by xlai about 1 year ago

  • Subject changed from [ipmi] test fails in login_console; Odd characters on login prompt to [ipmi] test fails in login_console; Not even select xen menuentry

#8 Updated by okurz about 1 year ago

xlai wrote:

From my view, our tests can skip the wait_grub which shared by many people and code changes from time to time. We can just use asssert_screen('grub', $timeout) to skip the influence by others.

Can we please try to still use it? I extracted the function "wait_grub" which in the most simple case really should not do more than the "assert_screen" you mentioned. I guess we are just pressing the key "ret" once too often or so. Sorry for the inconvenience.

#9 Updated by xlai about 1 year ago

okurz wrote:

xlai wrote:

From my view, our tests can skip the wait_grub which shared by many people and code changes from time to time. We can just use asssert_screen('grub', $timeout) to skip the influence by others.


Can we please try to still use it? I extracted the function "wait_grub" which in the most simple case really should not do more than the "assert_screen" you mentioned. I guess we are just pressing the key "ret" once too often or so. Sorry for the inconvenience.

@okurz, Please do not say sorry. We appreciate you help take care of so many shared code.
Our pain recently is that we are affected so much due to code change on shared part -- so many people contribute for their purpose, however may break others when not all are involved during review. As you know, our autoyast installation for 11sp4 is broken due to others' code change. Now it is this ticket. Also earlier in the morning another issue in reboot_after_installation. Now two members have to take these failures with highest priority, and put aside our planned tasks.

#10 Updated by xlai about 1 year ago

  • Status changed from Workable to In Progress

#11 Updated by xlai about 1 year ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF