Project

General

Profile

Actions

action #56441

closed

[sle][functional][y] test fails in partitioning_full_lvm - Volume management did not get expanded

Added by JERiveraMoya over 4 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 28
Start date:
2019-09-04
Due date:
2019-10-08
% Done:

0%

Estimated time:
5.00 h
Difficulty:

Description

Observation

openQA test in scenario sle-12-SP5-Server-DVD-s390x-lvm-full-encrypt@s390x-kvm-sle12 fails in
partitioning_full_lvm

Instead of expanding Volume Management menu to be able to check vg-system, it is going directly to the root of the tree, in this case linux and what tries to expand is vda.

Failed 2 out 3 runs.

Test suite description

Maintainer: riafarov poo#15926

(crypt-)LVM installations can take longer, especially on non-x86_64 architectures. Test suite creates encrypted lvm partition using expert partitioner and performs installation.

Reproducible

Fails since (at least) Build 0303 (current job)

Expected result

Last good: 0301 (or more recent)

Further details

Always latest result in this scenario: latest

Actions #1

Updated by riafarov over 4 years ago

  • Description updated (diff)
  • Due date set to 2019-10-08
  • Target version set to Milestone 28
Actions #2

Updated by riafarov over 4 years ago

  • Priority changed from Normal to High
Actions #3

Updated by okurz over 4 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: lvm-encrypt-separate-boot
https://openqa.suse.de/tests/3368946

Actions #4

Updated by JERiveraMoya over 4 years ago

  • Status changed from New to Workable
  • Estimated time set to 5.00 h
Actions #5

Updated by JRivrain over 4 years ago

  • Assignee set to JRivrain
Actions #6

Updated by JRivrain over 4 years ago

  • Status changed from Workable to In Progress

It looks like:

  • key home is sent
  • assert_screen_change sees a screen change where there is not (I suspect a glitch to trigger it)
  • it directly matches the next needle "volume_management_feature" before the screen actually had time to change, so no send_key 'down' is sent, because volume_management_feature is still higlighted from previous function "addvg"
  • starts the next instruction send_key_until_needlematch('lvm_uncollapse_vgs', 'right') which has effect to go down, expand the disk, then the partiton, and never reaches lvm_uncollapse_vgs. This happens also on aarch64.

Piece of code:

send_key $cmd{system_view};
assert_screen_change(sub {
send_key 'home';
}, 5);
send_key_until_needlematch('volume_management_feature', 'down');
wait_still_screen(stilltime => 2, timeout => 4);
# Expand collapsed list with VGs
send_key_until_needlematch('lvm_uncollapse_vgs', 'right') if is_sle('<15');
Actions #7

Updated by JRivrain over 4 years ago

I don't see any glitch on video, So I assume that what happens is: send_key 'home' is sent before send_key $cmd{system_view}; is received. trying some workaround.

Actions #8

Updated by JRivrain over 4 years ago

  • Status changed from In Progress to Feedback
Actions #9

Updated by JERiveraMoya over 4 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF