|
Bugzilla – Full Text Bug Listing |
| Summary: | YaST2 reports Traditional method with ifup, however ifdown reports Network is managed by 'NetworkManager.service' -> skipping | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.3 | Reporter: | Freek de Kruijf <freek> |
| Component: | Network | Assignee: | Marius Tomaschewski <mt> |
| Status: | RESOLVED DUPLICATE | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | arvidjaar, ctrippe, mircea.mucha, rcoe |
| Version: | RC 1 | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Freek de Kruijf
2013-02-10 23:50:08 UTC
After generating RC1 on a laptop YaST2 did setup the configuration with NetworkManager. However on my first login I could not start the UI for networkmanager. Only after changing the setup in YaST2 to the traditional method with ifup, logging out and logging in again, I got, to my surprise, the icon for the UI of NetworkManager and was able to enter the details for the wlan0 device. Apparently these details are not taken/copied from the KDE Live NetworkManager. I've installed two hosts with RC1. In both cases the hosts have fixed ip-addrs configured with ifup. I do not use NetworkManager. In both cases NetworkManager took over the eth0 interface and configured the port with dhcp. This is also my observation and the solution is to configure the fixed addresses using NetworkManager. You will find the configuration in /etc/NetworkManager/system-connections/<name_of_your_interface>. <name_of_your_interface> is in my case "Wired connection 1". Beware that you may get prompted for the root password, but the dialog is hidden behind the networkmanager window. Pressing OK in the networkmanager window also makes the dialog for the root password disappear and your changes are lost. It took a while before I figured out why the changes did not have effect. You're advocating running NetworkManager on headless systems? I also love how NetworkManager disables any network settings when the X system goes down. The solution is to disable NetworkManager.service with systemctl en enable network.service. This restores the ifup method. So this is something YaST2 should do if the traditional method ifup is chosen. Don't know if YaST2 sets up the network configuration properly in this case. I assume it does. After doing the above YaST2 will not return to the NetworkManager status of the network configuration. My conclusion is that the above two commands are missing in the network module of YaST2 and need to be performed when switching from one status to the other. The above works after e reboot, however it might work without a reboot when first stopping the NetworkManager.service, disabling it, enable network.service and start it or the other way around when going from ifup method to NetworkManager method. Have not tried it. *** Bug 804052 has been marked as a duplicate of this bug. *** sysconfig and most other packages has been changed to not use NETWORKMANAGER variable any more, but a network.service alias link. See also release notes bug #800771 and - still unfixed - bug #798348, to adopt switching between NetworkManager and /etc/init.d/network in yast2. [/etc/init.d/network is currently active only while miminal installation, in all other cases NetworkManager because yast2 is unable to switch it as needed.] To enable NetworkManager, use: systemctl stop network.service systemctl --force enable NetworkManager.service systemctl start network.service to disable NetworkManager, use: systemctl stop network.service systemctl --force disable NetworkManager.service systemctl start network.service This command: systemctl --no-pager -p Id show network.service reports "Id=NetworkManager.service" when NetworkManager acts as the network service, "Id=network.service" means /etc/init.d/network. I assume, it is a duplicate of bug#798348 [yast2-network unable to switch yet], isn't it? (In reply to comment #9) > I assume, it is a duplicate of bug#798348 [yast2-network unable to switch yet], > isn't it? From my side, yes, it is. OK, then closing as dup. There is also bug 803058 [blocker], where network is switched to use NM while "zypper dup". *** This bug has been marked as a duplicate of bug 798348 *** *** Bug 807179 has been marked as a duplicate of this bug. *** |