Bugzilla – Bug 1013605
[Build 20161203] openQA test fails: Hostname Error Pop-Up During Installation
Last modified: 2021-02-26 19:55:51 UTC
## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-autoyast_gnome@64bit fails in [installation](http://openqa.opensuse.org/tests/314361/modules/installation/steps/15) ## Reproducible Fails since (at least) Build [20161203](http://openqa.opensuse.org/tests/314132) This snapshot was the first to include yast2-network 3.2.15 (previous 3.2.11) which introduced the new handling of 'update hostname by dhcp' ## Expected result Last good: [20161202](http://openqa.opensuse.org/tests/313869) (or more recent) ## Further details Always latest result in this scenario: [latest](http://openqa.opensuse.org/tests/latest?test=autoyast_gnome&version=Tumbleweed&distri=opensuse&machine=64bit&arch=x86_64&flavor=DVD)
The autoyast profile used can be found at https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/master/data/autoyast_opensuse/opensuse_gnome.xml
If this bug is tracking the popup warning "More than one interface asks to control the hostname via DHCP..." then there is a similar error also for minimalx tests for ppc64/ppc64le network install as per: https://openqa.opensuse.org/tests/314156#step/yast2_lan/12 <= ppc64le https://openqa.opensuse.org/tests/314155#step/yast2_lan/12 <= ppc64
I assume Dominique refers to bug #984890 which according to the logs was handled by mfilka.
(In reply to Dominique Leuenberger from comment #0) > ## Observation > > openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-autoyast_gnome@64bit > fails in > [installation](http://openqa.opensuse.org/tests/314361/modules/installation/ > steps/15) > > > ## Reproducible > > Fails since (at least) Build > [20161203](http://openqa.opensuse.org/tests/314132) > > This snapshot was the first to include yast2-network 3.2.15 (previous > 3.2.11) which introduced the new handling of 'update hostname by dhcp' > > ## Expected result > > Last good: [20161202](http://openqa.opensuse.org/tests/313869) (or more > recent) > > > ## Further details > > Always latest result in this scenario: > [latest](http://openqa.opensuse.org/tests/ > latest?test=autoyast_gnome&version=Tumbleweed&distri=opensuse&machine=64bit&a > rch=x86_64&flavor=DVD) I guess that all tests use the same configuration including the AY profile. If yes, then there is a kind of misconfiguration. What's going on: 1) boot param ifcg=*=dhcp configures all interfaces (in this case one) for dhcp including DHCLIENT_SET_HOSTNAME=yes 2) AY profile contains <dhcp_hostname config:type="boolean">true</dhcp_hostname> which sets DHCLIENT_SET_HOSTNAME=yes in /etc/sysconfig/network/dhcp yast issues the warning in such case bcs the (1) seems to be redundant or misconfigured ('no' would make more sense here in this case) So, what should let the test pass: - set dhcp_hostname from case (2) to false What should be improved on yast side: (1) the popup should be either disabled or timed out in case of (auto)installation. It is intended to be warning and should not block the installation (2) the dhcp_hostname option should be turned from boolean to list and accept values similar to UI (yes, no, <device-name> @Dominique: Could you pls check if change dhcp_hostname to false in the AY profile let the test pass? Thanks
> What's going on: > 2) AY profile contains <dhcp_hostname config:type="boolean">true</dhcp_hostname> No, at least the opensuse_gnome.xml profile from comment 1 does not contain that.
*** Bug 1013934 has been marked as a duplicate of this bug. ***
also visible in many SLE tests, e.g. https://openqa.suse.de/tests/656582
(In reply to Martin Vidner from comment #6) > > What's going on: > > 2) AY profile contains <dhcp_hostname config:type="boolean">true</dhcp_hostname> > > No, at least the opensuse_gnome.xml profile from comment 1 does not contain > that. ok I've misinterpreted logs from referenced correct example which states: 2016-12-03 13:38:13 <1> linux-1r4t(3557) [Ruby] modules/DNS.rb:492 dhcp_hostname=true, write_hostname=false Problem is elsewhere. Yast proposes a value for dhcp_hostname when not present in the profile. When a default is not found in product features (it's not in this case) than it sets that to true. (Note: original implementation of this proposal is in commit https://github.com/yast/yast-network/commit/4668fc7c) So, if I'm right this time then setting <dhcp_hostname config:type="boolean">false</dhcp_hostname> in the AY profile explicitly should fix the issue. @Dominique: Could you verify that?
jpupava prepared a change of the autoyast profiles: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2197 but I am not sure on this one. The mentioned profiles are minimal and only mention what's necessary. Why should it be necessary to specify explicit DHCP hostname settings? *If* this specific setting would be necessary in general then I would like to see the updated documentation of autoyast profiles before I am convinced. As Jozef did such a great work to verify the proposed changes to the profiles work, see https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2197#issue-194266528, I am clearing the needinfo on dimstar.
(In reply to Oliver Kurz from comment #10) > jpupava prepared a change of the autoyast profiles: > https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2197 > > but I am not sure on this one. The mentioned profiles are minimal and only > mention what's necessary. Why should it be necessary to specify explicit > DHCP hostname settings? *If* this specific setting would be necessary in > general then I would like to see the updated documentation of autoyast > profiles before I am convinced. > > As Jozef did such a great work to verify the proposed changes to the > profiles work, see > https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2197#issue- > 194266528, I am clearing the needinfo on dimstar. I'm preparing an update for yast. The update should take care of installer not to create incorrect configuration.
This bug will always appear when using remote install source e.g. install=ftp:// and after pressing 'OK' the roll-down list is empty
Created attachment 705866 [details] y2logs installation with remote source install=ftp://
Created attachment 705867 [details] empty hostname via DHCP roll-down list
another example of failure https://openqa.suse.de/tests/668088#
same warning "More than one interface asks to control the hostname via DHCP..." raises in dialogue of "yast2 clone_system"
This is being fixed in https://github.com/yast/yast-network/pull/476 (In reply to Jozef Pupava from comment #14) > empty hostname via DHCP roll-down list Thanks, this one is this fix: https://github.com/yast/yast-network/pull/476#discussion-diff-91705664L433
A fix for this was made in Linuxrc in the end: https://github.com/openSUSE/linuxrc/pull/131
still have same problem as described in comment 16. SLE-12-SP3-Server-DVD-ppc64le-Build0202 was used for my test.
since this is still not fixed yet, re-open it now.
Regarding SLE-12-SP2 (two!): It does contain an update for yast2-network, which was the trigger for this bug: --- Wed Nov 23 09:18:33 UTC 2016 - mfilka@suse.com - bsc#984890 - new implementation of setting hostname via DHCP. User is allowed to set hostname via particular interface or set a reasonable default value for all interfaces. - 3.1.170.5 --- BUT this version is not in the installation image, so I think we do not need to update linuxrc for SP2.
https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/2394 adds a workaround for the openQA tests with a reference to this bug. SR is still open.
https://build.suse.de/request/show/126906 is accepted now.
https://openqa.suse.de/tests/878812#step/clone/3