Project

General

Profile

action #60392

[functional][y][timeboxed:8h] test fails in yast2_lan_restart

Added by riafarov almost 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Bugs in existing tests
Target version:
SUSE QA - Milestone 30
Start date:
2019-11-28
Due date:
2020-01-28
% Done:

0%

Estimated time:
Difficulty:

Description

Observation

journal.log file is missing. Requires some investigation.

openQA test in scenario sle-15-SP2-Online-x86_64-yast2_gui@64bit fails in
yast2_lan_restart

Test suite description

Maintainer: zluo, riafarov

Test for yast2 UI, GUI only. Running on created gnome images which provides both text console for ncurses UI tests as well as the gnome environment for the GUI tests.

Reproducible

Fails since (at least) Build 93.1

Expected result

Last good: 92.1 (or more recent)

Further details

Always latest result in this scenario: latest


Related issues

Related to openQA Tests - action #64349: test fails in yast2_lan_restartResolved2020-03-10

History

#1 Updated by SLindoMansilla almost 2 years ago

  • Description updated (diff)

#2 Updated by riafarov almost 2 years ago

  • Status changed from New to Blocked

Addressing #59315 first.

#3 Updated by riafarov almost 2 years ago

  • Due date changed from 2019-12-31 to 2020-01-14

#4 Updated by okurz over 1 year ago

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

This bug is still referenced in a failing openQA test: extra_tests_on_gnome
https://openqa.suse.de/tests/3720703

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"
  3. The label in the openQA scenario is removed

#5 Updated by JERiveraMoya over 1 year ago

  • Status changed from Blocked to Workable

#59315 addressed.

#6 Updated by riafarov over 1 year ago

  • Assignee deleted (riafarov)

#7 Updated by JERiveraMoya over 1 year ago

  • Due date changed from 2020-01-14 to 2020-01-28

not refined yet, moving to next sprint.

#8 Updated by mgriessmeier over 1 year ago

I assume that those concatenated > are the reason why the file is empty and therefore fails
this was introduced by cde7824ac87f3396b0928e526d1874609f79855a from alex

#9 Updated by riafarov over 1 year ago

mgriessmeier wrote:

I assume that those concatenated > are the reason why the file is empty and therefore fails
this was introduced by cde7824ac87f3396b0928e526d1874609f79855a from alex

It started failing before that change and actually Alex has split that test into 3. We will check if that test module should be dropped then as adjusted modules work just fine.

#10 Updated by riafarov over 1 year ago

So it's different test module and we need a separate patch, but it's not related to the change Alex did.

#11 Updated by riafarov over 1 year ago

  • Target version set to Milestone 30

#12 Updated by riafarov over 1 year ago

  • Subject changed from [functional][y] test fails in yast2_lan_restart to [functional][y][timeboxed:8h] test fails in yast2_lan_restart

#13 Updated by riafarov over 1 year ago

  • Assignee set to riafarov

#14 Updated by riafarov over 1 year ago

  • Status changed from Workable to Feedback

#15 Updated by riafarov over 1 year ago

  • Status changed from Feedback to Resolved

#16 Updated by dzedro over 1 year ago

  • Status changed from Resolved to In Progress

Please investigate behavior on 15sp2, device name should cause restart. https://fate.suse.com/318787
I reverted change which is breaking all yast2_lan_restart tests older than 15sp2 https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/9655

2020-02-27T22:28:43.781989-05:00 susetest kernel: [  330.470173] virtio_net virtio0 dyn0: renamed from eth0
2020-02-27T22:28:45.033528-05:00 susetest systemd[1]: Reloading wicked managed network interfaces.
2020-02-27T22:28:45.089883-05:00 susetest wicked[6619]: skipping lo interface: configuration unchanged
2020-02-27T22:28:45.090910-05:00 susetest wicked[6619]: skipping ifdown operation for dyn0 interface: device is not configured by wicked
2020-02-27T22:28:45.099070-05:00 susetest wicked[6619]: dyn0: configuration applied to nanny
2020-02-27T22:28:45.143501-05:00 susetest wickedd-dhcp4[897]: dyn0: Request to acquire DHCPv4 lease with UUID a987585e-2a83-0600-b903-000015000000
2020-02-27T22:28:45.145678-05:00 susetest wickedd-dhcp6[894]: dyn0: Request to acquire DHCPv6 lease with UUID a987585e-2a83-0600-b903-000016000000 in mode auto
2020-02-27T22:28:45.815046-05:00 susetest wickedd-dhcp4[897]: dyn0: Committed DHCPv4 lease with address 10.0.2.15 (lease time 86400 sec, renew in 43200 sec, rebind in 75600 sec)
2020-02-27T22:28:47.142028-05:00 susetest wickedd-dhcp6[894]: dyn0: DHCPv6 is disabled by IPv6 router RA
2020-02-27T22:28:48.773660-05:00 susetest wickedd-dhcp6[894]: message repeated 2 times: [ dyn0: DHCPv6 is disabled by IPv6 router RA]
2020-02-27T22:28:48.900251-05:00 susetest wicked[6619]: dyn0            up
2020-02-27T22:28:48.903529-05:00 susetest systemd[1]: Reloaded wicked managed network interfaces.

#17 Updated by dzedro over 1 year ago

  • Related to action #64349: test fails in yast2_lan_restart added

#18 Updated by okurz over 1 year ago

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

This bug is still referenced in a failing openQA test: extra_tests_gnome
https://openqa.suse.de/tests/3983406

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"
  3. The label in the openQA scenario is removed

#19 Updated by riafarov over 1 year ago

  • Status changed from In Progress to Resolved

https://bugzilla.suse.com/show_bug.cgi?id=1165923 was filed, so we can resolve it for now. I've talked to yast team and wicked, they were not sure about this behavior and on top, I've checked that device is actually renamed and network is running, which is most important.

Let's see what will happen in the bug. Ticket can be resolved for now.

Also available in: Atom PDF