Project

General

Profile

action #62690

[functional][y][timeboxed:8h] finish btn is disabled in Installation Completed

Added by ybonatakis over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 32
Start date:
2020-01-27
Due date:
2020-02-25
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

The disabled btn is disabled and such the first_boot cant pass successfully. It might be the something in the xml as i didnt encounter any problem manual(not using AY though).

Also, we should create better needle in yast2_firstboot

It appears to be bug, as we wait a lot of time in openQA, so in worst case we should file a bug with detailed description of the problem and logs.

openQA test in scenario sle-15-SP2-Online-x86_64-autoyast_y2_firstboot@64bit fails in
first_boot

Test suite description

Smoke test for YaST2 Firstboot module, basically same as yast2_firstboot test suite. Test pre-defined autoyast profile, which enables YaST2 Firstboot during system deployment. SUT should boot to YaST2 Firstboot wizard after reboot. Test goes through all Firstboot tabs, configure root and user accounts. SUT should end up in GDM screen after exiting YaST2 Firstboot.

Reproducible

Fails since (at least) Build 126.1

Expected result

Last good: 122.1 (or more recent)

Further details

Always latest result in this scenario: latest

History

#1 Updated by riafarov over 1 year ago

  • Due date set to 2020-02-25
  • Priority changed from Normal to High
  • Target version set to Milestone 32

#2 Updated by riafarov over 1 year ago

  • Subject changed from [functional][y] finish btn is disabled in Installation Completed to [functional][y][timeboxed:8h] finish btn is disabled in Installation Completed
  • Description updated (diff)
  • Status changed from New to Workable

#3 Updated by mloviska over 1 year ago

  • Status changed from Workable to In Progress
  • Assignee set to mloviska

If you do not mind guys, I would like to take over since the problem affects WSL.

#4 Updated by mloviska over 1 year ago

2020-02-05 15:40:11 <1> susetest(1460) [Ruby] clients/inst_congratulate.rb:133 UI mode: expert
2020-02-05 15:40:11 <3> susetest(1460) [Ruby] modules/ProductControl.rb:1153 No such text congratulate
2020-02-05 15:40:11 <1> susetest(1460) [Ruby] modules/GetInstArgs.rb:48 args=$["enable_back":false, "enable_next":false]
2020-02-05 15:40:11 <1> susetest(1460) [Ruby] modules/GetInstArgs.rb:48 args=$["enable_back":false, "enable_next":false]

#5 Updated by ybonatakis over 1 year ago

I should correct myself here. This doesnt work not even manual. mloviska can you paste the bug number?

#6 Updated by mloviska over 1 year ago

ybonatakis wrote:

I should correct myself here. This doesnt work not even manual. mloviska can you paste the bug number?

https://bugzilla.suse.com/show_bug.cgi?id=1163100

#7 Updated by mloviska over 1 year ago

Checking TW

#8 Updated by mloviska over 1 year ago

Only 'Back' button is in the inactive state

https://openqa.opensuse.org/tests/1159548#step/firstrun/10

Let's see what happens on regular TW.

#9 Updated by mloviska over 1 year ago

ybonatakis, amazing hypothesis that the problem is in the workflow XML file!

<module>
<label>Finish Setup</label>
<name>firstboot_write</name>
<enable_back>no</enable_back>
<enable_next>no</enable_next>
</module>
<module>
<label>Finish Setup</label>
<name>inst_congratulate</name>
<enable_back>no</enable_back>
<enable_next>no</enable_next>
</module>
</modules>

#10 Updated by mloviska over 1 year ago

leap15sp2

<module>
<label>Finish Setup</label>
<name>firstboot_write</name>
<enable_back>no</enable_back>
<enable_next>no</enable_next>
</module>
<module>
<label>Finish Setup</label>
<name>inst_congratulate</name>
</module>

#11 Updated by riafarov over 1 year ago

Hi Martin! From our POV, ticket is resolved as you figured out the root cause and filed a bug. Do you think we still need to act on something in scope of this ticket?
And thanks for your help, very appreciated!

#12 Updated by mloviska over 1 year ago

  • Status changed from In Progress to Resolved

riafarov wrote:

Hi Martin! From our POV, ticket is resolved as you figured out the root cause and filed a bug. Do you think we still need to act on something in scope of this ticket?

Hey Rodion! Sure, let's close it

And thanks for your help, very appreciated!

Glad to help anytime, mainly when Yannis makes it so easy :D

Also available in: Atom PDF