Project

General

Profile

Actions

action #62852

closed

[sle][functiona][u]test fails in hostname_inst - Test died: command 'test "$(hostname)" == "linux"'

Added by zluo about 4 years ago. Updated about 4 years ago.

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

0%

Estimated time:
42.00 h
Difficulty:

Description

it looks that hostname is not linux anymore, please check.

Observation

openQA test in scenario sle-15-SP2-Online-x86_64-network_configuration@64bit fails in
hostname_inst

Test suite description

Maintainer: jrivera@suse.com Verify that DHCLIENT_SET_HOSTNAME preloaded from control file does not overwrite the customer selection and check the hostname in the installed system

Suggestions

  1. Investigate what does NICTYPE_USER_OPTIONS.
  2. Investigate why the machine gets the name changed from install to myguest.
  3. Report a product bug or fix the test.

Reproducible

Fails since (at least) Build 89.1

Expected result

Last good: (unknown) (or more recent)

Further details

Always latest result in this scenario: latest


Related issues 1 (0 open1 closed)

Is duplicate of openQA Tests - action #56750: [functional][u] test fails in hostname_inst: hostname magically changedRejectedJERiveraMoya2019-09-10

Actions
Actions #1

Updated by zluo about 4 years ago

https://bugzilla.suse.com/show_bug.cgi?id=1153198 got fixed and the report information for this bug is not available anymore. So I think this could be an another issue.

Actions #2

Updated by SLindoMansilla about 4 years ago

The fix for the mentioned bug is present in the SLE15-SP2 repository: https://build.suse.de/package/view_file/SUSE:SLE-15-SP2:GA/yast2-network/yast2-network.changes?expand=1
Search for 4.2.29

The build 131.1 has yast2-network [4.2.46-1.6.noarch] < skelcd-control-leanos and it is still failing.

Actions #3

Updated by SLindoMansilla about 4 years ago

  • Is duplicate of action #56750: [functional][u] test fails in hostname_inst: hostname magically changed added
Actions #4

Updated by SLindoMansilla about 4 years ago

It seems it wasn't the bug. This needs more investigation.

Actions #5

Updated by SLindoMansilla about 4 years ago

  • Description updated (diff)
  • Status changed from New to Workable
  • Priority changed from Normal to High
  • Target version set to Milestone 30
  • Estimated time set to 42.00 h
Actions #6

Updated by zluo about 4 years ago

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

take over

Actions #7

Updated by zluo about 4 years ago

found out for:

  1. NICTYPE_USER_OPTIONS=hostname=myguest is used for tests/console/network_hostname.pm
    and this got set for the testsuite. It will be used later.

  2. this explains why hostname myguest got displayed to user because shells running on other consoles 2, 5, 6, 9

  3. I don't think this is a product issue. Because I could not find any successful of network_hostname.pm. So I need to investigate it further when it uses NICTYPE_USER_OPTIONS=hostname=myguest and it breaks the test

I'll try to adapter for this change in hostname_inst.pm.

Actions #9

Updated by SLindoMansilla about 4 years ago

So, as I feared, this is more complex than it looked like.

Expectations

This is the expected behavior from the documentation: https://github.com/openSUSE/linuxrc/blob/master/linuxrc_hostname.md
This is the expected behavior from SLE15-SP1: https://openqa.suse.de/tests/2923593
This is the failure on SLE15-SP2: https://openqa.suse.de/tests/3867716

Test suite settings for network_configuration

DESKTOP=gnome
EXPECTED_INSTALL_HOSTNAME=linux
INSTALLONLY=1
NETWORK_CONFIGURATION=1
NICTYPE_USER_OPTIONS=hostname=myguest

Observations

  1. NICTYPE_USER_OPTIONS is used to add parameters to QEMU. In this case the parameter hostname=myguest would simulate a hostname given by a DHCP server.
  2. Set Hostname via DHCP is enabled by default in both SP1 and SP2
  3. Set Hostname via DHCP is disabled via Yast in both SP1 and SP2
  4. For some reason I don't understand the hostname is changed at this step without any related command
  5. In the installed system, it is check that the DHCP setting and the hostname are the expected ones

I think it is a product bug. Reported: https://bugzilla.suse.com/show_bug.cgi?id=1162987

Actions #10

Updated by zluo about 4 years ago

Let#s check feedback of https://bugzilla.suse.com/show_bug.cgi?id=1162987 and we can check the current status again if any relevant fixes already is already working.

Actions #11

Updated by okurz about 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: network_configuration
https://openqa.suse.de/tests/3938942

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
Actions #12

Updated by SLindoMansilla about 4 years ago

Actions #14

Updated by SLindoMansilla about 4 years ago

  • Status changed from In Progress to Resolved
Actions #15

Updated by SLindoMansilla about 4 years ago

Setting EXPECTED_INSTALL_HOSTNAME removed from test suite network_configuration

Actions #16

Updated by SLindoMansilla about 4 years ago

Fix scenario yast_hostname+linuxrc_hostname: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/9827 (merged)

Actions

Also available in: Atom PDF