Project

General

Profile

action #117100

Adjust bootloader_start on s390x to new YaST start message

Added by rainerkoenig 2 months ago. Updated 10 days ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
Start date:
2022-09-23
Due date:
% Done:

0%

Estimated time:

Description

Observation

With Build 24.1 we get a systematic failure in bootloader_start on S390x (kvm and zvm):

Example: https://openqa.suse.de/tests/9563755#step/bootloader_start/37

First line in the output says

# wait_serial expected: " Starting YaST2 "

but at the end when YaST starts the message is:

*** Starting YaST ***

Fix should be easy by adjusting the trigger text.

Acceptance criteria

AC1: Trigger text is adjusted, tests no longer fail in bootloader_start
AC2: Adjusted code doesn't break other products (apparently this change is only in SLE-15-SP5)

Additional info

YaST team told us, that the YaST startup message intentionally changed because of this commit:
https://github.com/yast/yast-installation/commit/462733aca602bb2cf9eb8f309b9c58620b7f2938

wait_serial takes regex as parameter, favor that solution over if/else statements in code.

History

#1 Updated by rainerkoenig 2 months ago

  • Description updated (diff)
  • Priority changed from Normal to High

#2 Updated by JERiveraMoya about 2 months ago

  • Tags set to qe-yast-refinement
  • Description updated (diff)
  • Target version set to Current

#3 Updated by coolgw about 2 months ago

checked.
s/YaST2/YaST/ if sle=15sp5

#4 Updated by rainerkoenig about 2 months ago

Would we lose much "precision" if we just do a

s/YaST2/YaST/

without checking for any specific version? Those checks always open the door to problems if new versions arrive.

#5 Updated by JERiveraMoya about 2 months ago

coolgw wrote:

checked.
s/YaST2/YaST/ if sle=15sp5

that is why I added 'favor the solution without conditions' :)

#6 Updated by JERiveraMoya about 2 months ago

rainerkoenig wrote:

Would we lose much "precision" if we just do a

s/YaST2/YaST/

without checking for any specific version? Those checks always open the door to problems if new versions arrive.

It makes sense, but there are some spaces that perhaps needs to be accounted..." YaST " we'll see.

#7 Updated by JERiveraMoya about 2 months ago

  • Tags deleted (qe-yast-refinement)
  • Status changed from New to Workable

#8 Updated by shukui about 1 month ago

  • Assignee set to shukui

#9 Updated by shukui about 1 month ago

  • Status changed from Workable to In Progress

#11 Updated by shukui about 1 month ago

  • Status changed from In Progress to Resolved

#12 Updated by openqa_review 15 days ago

  • Status changed from Resolved to Feedback

This is an autogenerated message for openQA integration by the openqa_review script:

This bug is still referenced in a failing openQA test: autoyast_zvm_sles_product_reg@s390x-zVM-vswitch-l2
https://openqa.suse.de/tests/9919870#step/bootloader_start/1

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" or "EOL" (End-of-Life)
  3. The bugref in the openQA scenario is removed or replaced, e.g. label:wontfix:boo1234

Expect the next reminder at the earliest in 28 days if nothing changes in this ticket.

#13 Updated by JERiveraMoya 10 days ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF