Bug 807179

Summary: yast-Statically Assigned IP Address is ignored
Product: [openSUSE] openSUSE 12.3 Reporter: Mircea Mucha <mircea.mucha>
Component: YaST2Assignee: E-mail List <bnc-team-screening>
Status: RESOLVED DUPLICATE QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P2 - High CC: hfischer, suse-beta
Version: RC 2   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE 12.2   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: Print screens-output systemctl status network.service

Description Mircea Mucha 2013-03-03 09:07:35 UTC
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.0.3705; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; MS-RTC LM 8; InfoPath.2)

Environment: Oracle Virtual Box 4.2.6.r82870 running under a Windows XP OS. There are 2 OpenSuse virtual machines installed from scratch: OpenSuse 12.2 and OpenSuse 12.3. Same route (ADSL) Huawei is DHCP server for the private network: 192.168.1.0/24.
In both cases using yast – Network Devices – Network Settings there are the same settings:
Network Settings: Network Setup Method=Traditional Method with ifup, IPV6=disabled, DHCP Client Options=empty, Hostname to Send=Empty, Change Default Route via DHCP=empty. Network Card Setup=eth0, Statically Assigned IP Address=192.168.1.53/24 (OpenSuse12.2), 192.168.1.54/24 (OpenSuse 12.3), in both cases: in Routing, Default IPv4 Gateway= 192.168.1.1, Device: eth0.
In case of OpenSuse 12.2 changing in the menu Network Card Setup from Statically Assigned IP Address to Dynamic Address, changes are immediately done, while in case of OpenSuse 12.3 the same IP address initial allocated by DHCP can be seen after changes in yast are done, even after a reboot of the OpenSuse 12.3 and reboot of DHCP router, the statically allocated IP is ignored.
Is it a bug of the OpenSuse 12.3 itself or this problem is related with BUG-806416 (virtualbox-guest-tools-4.2.6-3.1.7.i586.rpm is not installed)?


Reproducible: Always

Steps to Reproduce:
1.Described in Details
2.
3.
Actual Results:  
Cannot change to a statically allocated IP address
Comment 1 Helga Fischer 2013-03-04 22:16:00 UTC
This problem occurs too on a opensuse 12.2 system as host using virtualbox 8.2.8 on a 64bit-system. Guest is openSUSE 12.3RC2, installed from the dvd-image build 0094 with all updates. For networking for this virtual machine I choosed 'bridged'.

For installing and using the first time this guest was using a ipv4 address using dhcp. Now I want to switch to a static ip using yast to configure that.

YaST got IP, networkmask, nameserver, standardgateway, but ifconfig shows no static ip.

I'm using YaST for a long time configuring static ips. All times it just work.

Looking at /etc/sysconfig/network I find all dates correct. But I'm not able to load them. Reboot fetch the IP from the DHCP server.

Older virtual machines take their static IPs without any problems. Unfortunatly I didn't test newer Suse systems.

I think it is important, to solve this bug. Not only me is testing for servers on VirtualBox.
Comment 2 Christian Boltz 2013-03-05 20:43:19 UTC
Helga told me on the opensuse-de mailinglist that NetworkManager (instead of "traditional" network) was active. This means this is a possible duplicate of bug 803008, which was fixed in the meantime (after RC2).

Mircea, what's the output of
    systemctl status network.service
on your system?
Comment 3 Mircea Mucha 2013-03-07 18:55:22 UTC
Created attachment 528782 [details]
Print screens-output systemctl status network.service
Comment 4 Mircea Mucha 2013-03-07 18:58:06 UTC
Please see the output of the command in the attachment.
Comment 5 Christian Boltz 2013-03-07 19:26:34 UTC
As I guessed - NetworkManager is running, even if YaST tells you something else. That's a known bug and already fixed.

See bug 803008 comment #9 for information how to really ;-) switch to traditional network config.

*** This bug has been marked as a duplicate of bug 803008 ***