|
Bugzilla – Full Text Bug Listing |
Going to install the most recent factory from scratch... and take a look what happens there exactly. I guess, it is the NM <-> ifup switch, that does not work properly any more... BTW: Do not use "ifup" directly -- systemd will currently never consider manually started interfaces as part of the network service (it is on my TODO to bring him to consider them) as they're not part of the cgroup. Use "rcnetwork stop ; rcnetwork start". See also sysconfig & NetworkManager in $OBS/home:mtomaschewski:tests/. on 2nd boot network is there Created attachment 520129 [details]
Network started manually by some yast2 scripts
I've installed just now and have a bit different view: The network is up
and running, but systemd does not know anything about.
I guess this is caused by "rcnetwork start -o onboot" in the
/usr/lib/YaST2/startup/Second-Stage/S07-medium
script or something similar:
when there are additional arguments except of the init script action
(such as the "-o onboot" above), the call is not redirected to systemd
via /etc/rc.status redirection and the network is started "directly",
not via systemd, where it is still in any "not started" state.
Any news from NETWORKMANAGER -> network.service adoption of yast2? Created attachment 520659 [details]
yast2: prototype patch to use network.service instead NETWORKMANAGER
Created attachment 520661 [details]
yast2-network: prototype patch to use network.service instead NETWORKMANAGER
The patches also workarounds one insufficient fix for bnc#795929 problem with yast2's Service::Status implementation: -> Adding the directory checkExists's dir list is not sufficient. This check IMO still breaks e.g. network service (/etc/init.d/network). Call to Service::Status("network") is always -1 because of checkExists, because there is no network.service file. I'd say, just remove checkExists line from Service::Status(). Created attachment 520665 [details]
yast2: prototype patch to use network.service instead NETWORKMANAGER
Ahm... wrong function order: moved use behind declaration...
Michal, Lukas, see prototype patches. Please note also comment 3. See also the test packages in: http://download.opensuse.org/repositories/home:/mtomaschewski:/tests/ yast2-network test suite currently fails -- AFAIS because of the checkExists: Let me know when you have the yast2 packages ready. Created attachment 520666 [details]
network-service-switch.sh: illustration script
The patch is not bad but I have some comments:
* First of all, we use GitHub now, where cloning and creating pull requests
make it easier for us to incorporate changes from different authors
easily - this also makes it easy to comment the change
* Some pieces changes or even parts of the diff belong to Service YCP module
instead of NetworkService - they are quite generic or at least could be
For instance Service::RunInitScript() could be used or even extended
("--no-pager -p Id show" as a param)
* Functions like GetServiceId or GetUnitId definitely belong to Service module
* Additionally, testsuite is missing
Created attachment 521559 [details]
yast2-2.23.19: merged prototype patch to use network.service instead NETWORKMANAGER
Created attachment 521560 [details]
yast2-network-2.24.12: merged prototype patch to use network.service instead NETWORKMANAGER
(In reply to comment #12) > The patch is not bad but I have some comments: Sure. I'm completely not familiar with all the yast2 mechanisms. > * First of all, we use GitHub now, where cloning and creating pull requests > make it easier for us to incorporate changes from different authors > easily - this also makes it easy to comment the change OK, done. I've splitted the yast2 patch into two separate commits (for Service only and for NetworkService changes) and created github pull requests: https://github.com/yast/yast-yast2/pull/44 https://github.com/yast/yast-network/pull/47 > * Some pieces changes or even parts of the diff belong to Service YCP module > instead of NetworkService - they are quite generic or at least could be > For instance Service::RunInitScript() could be used or even extended > ("--no-pager -p Id show" as a param) I didn't wanted to break other services. AFAIS NetworkService reimplements e.g. an own RunInitScript anyway, so there were things to cleanup already before. > * Functions like GetServiceId or GetUnitId definitely belong to Service module They are in Service. > * Additionally, testsuite is missing Yes, but I've no idea how to make it the right way. So the testsuites and cleanup or "making it the right way" remains as TODO for the Authors / yast2-maintainers. I'm going to retest & submit the other packages now. See bnc#800365, a systemd queue-merge bug, which breaks the network start inside of the yast2 2nd stage scripts, because systemd merges the start calls with the network.service start which is scheduled to start after the 2nd stage. Except of the systemd bnc#800365 issue, the home:mtomaschewski:tests packages work fine for me, that is in a running system and at boot [without all the (re)starts in 2nd stage]. This is an autogenerated message for OBS integration: This bug (798348) was mentioned in https://build.opensuse.org/request/show/149829 Factory / sysconfig https://build.opensuse.org/request/show/149830 Factory / sysconfig This is an autogenerated message for OBS integration: This bug (798348) was mentioned in https://build.opensuse.org/request/show/149901 Factory / netcontrol This is an autogenerated message for OBS integration: This bug (798348) was mentioned in https://build.opensuse.org/request/show/150166 Factory / sysconfig https://build.opensuse.org/request/show/150169 Factory / sysconfig please note that kiwi-config-openSUSE sets NETWORKMANGER=yes for the live cds. This needs changes too. This is an autogenerated message for OBS integration: This bug (798348) was mentioned in https://build.opensuse.org/request/show/150265 Factory / NetworkManager (In reply to comment #21) > please note that kiwi-config-openSUSE sets NETWORKMANGER=yes for the live cds. > This needs changes too. => bnc#800817. Michal, Lukas, any news about: https://github.com/yast/yast-yast2/pull/44 https://github.com/yast/yast-network/pull/47 *** Bug 803521 has been marked as a duplicate of this bug. *** *** Bug 801994 has been marked as a duplicate of this bug. *** *** Bug 802761 has been marked as a duplicate of this bug. *** *** Bug 803008 has been marked as a duplicate of this bug. *** Marius, it seems to me that you do not handle the update correctly. When updating with NetworkManager running, you then have network.service enabled instead of NetworkManager.service. At least that's my understanding after updating my systems and also after reading some of the duplicated bug reports. (In reply to comment #29) > Marius, it seems to me that you do not handle the update correctly. When > updating with NetworkManager running, you then have network.service enabled > instead of NetworkManager.service. At least that's my understanding after > updating my systems and also after reading some of the duplicated bug reports. Yes, update is not working correctly too :-/ bug 803058: tracks the update case [where yast2 2nd stage is not involved, bug 798348: [this one] is about fresh installations with yast2 switch. BTW: network.service is basically always enabled (via insserv rcnetwork). When also NetworkManager.service is enabled, it creates network.service alias link which masks /etc/init.d/network. Unfortunately this does not work properly on update (I hope home:mtomaschewski:test packages fix it). Always enabling network.service but hiding it with a symlink sounds hacky. Is there a better way that arranges both services as exclusive alternatives? using symlink to shadow a service is part of systemd (in fact, it is just a derivative of the way systemd merged configuration in /usr/lib/systemd + /etc/system/system + /run/systemd/ ), so it isn't as hacky as it seems :) After some digging in the log file /var/log/y2log I found the error which causes the problem of not changing the network.service from pointing to NetworkManager.service or just to itself (/etc/init.d/network).
When only changing from Traditional to NetworkManager the network module of YaST sets this in the configuration and issues a "/bin/systemctl reload network.service" which does not work. The error message is "Job type reload is not applicable for unit network.service". YaST does not issue an error message to the user. So this error gets unnoticed.
For the maintainer: Line 570 in modules/Lan.ycp needs a more complicated treatment. Now it just reads:
Service::Reload("network");
without any error checking.
Just for the record: 'zypper dup' to 12.3 RC2 still leaves default route on eth0 instead of br0. Only manual switch from NetworkManager.service to network.service + reboot fixes this. AFAIK configuration in YaST without NetworkManager is not copied to the NetworkManager configuration when you switch to NetworkManager method. So switching means you have to configure the network from the bare basics. This is the situation as of Build97 (post RC2) DVD install Post installation, first boot, networking is not active On second boot or after rcnetwork restart, traditional network is enabled and active. yast2 lan: "User controlled with NetworkManager" is checked, but NetworkManager is not running (systemctl status NetworkManager -> loaded, disabled, inactive). Changing networking type with yast2 lan has no effect. What does work is systemctl stop network.service systemctl enable NetworkManager.service (this creates the symlink network.service masking /etc/init.d/network) systemctl --system daemon-reload (so systemd knows about the new masking) systemctl start NetworkManager.service This Summary is, with a DVD install you need to know this incantation to get NM and therefore useful networking on a laptop. We might as well call the DVD "Workstation edition" and make a positive out of this. Coolo, I hope it's clear now how this is worse than in 12.2 DVD... The problem is a call "systemctl reload network.service" which does not work (at least when NetworkManager is active, if not al all) and should be replaced by the above commands depending on which switch between Traditional and NetworkManager should be performed. I already suggested a solution on yast-devel@opensuse.org. I have tested with Marius' code from comment 24 (merged with other changes made in the meantime): https://github.com/mvidner/yast-yast2/commit/066d0e32d35af14938d40d9939827e944d28310f https://github.com/mvidner/yast-network/commit/38ebc06f8e6f0ec62198ab4c96874438a77ca482 (submitted them to https://build.opensuse.org/project/show?project=YaST%3AHead ) and the *original* bug, about network not coming up after a DVD installation without NetworkManager, is not fixed. Digging in. /usr/lib/YaST2/startup/Second-Stage/S09-cleanup stops the network. Frederic, did you mean to address that in https://github.com/fcrozat/yast-installation/commit/6b317d27cbeba2c7368fda15dc6cba00464e5a57 ? (bug 800365 Comment 5) (In reply to comment #40) > /usr/lib/YaST2/startup/Second-Stage/S09-cleanup stops the network. > > Frederic, did you mean to address that in > https://github.com/fcrozat/yast-installation/commit/6b317d27cbeba2c7368fda15dc6cba00464e5a57 > ? (bug 800365 Comment 5) Yes, YaST second stage shouldn't touch network at all (but there were other issues I couldn't debug). And it is way to late to change that for 12.3 now. But if we can clean up this for Factory, I'd be happy. Created attachment 528381 [details]
YaST2 log for a Lenovo x230 after installation
I tested yast2-2.23.22-0.x86_64.rpm and yast2-network-2.24.16-0.x86_64.rpm (build locally). The test platform is a Lenovo x230 laptop.
I installed both RPMs before stage2 installation process, and after the installation process I have network in the traditional mode (I can ping random URLs). A systemctl status NetworkManager.service show that the service is enabled but inactive. After the first reboot, the Network Manager is running perfectly. Also, I tested that I can switch between traditional and NM mode.
Really cool.
yast2-2.23.22 and yast2-network-2.24.16 are in https://build.opensuse.org/project/show?project=openSUSE%3A12.3 already. Merged to master git repos: https://github.com/yast/yast-network/pull/61 and https://github.com/yast/yast-yast2/pull/51 Note that this only fixes the netcontrol - NetworkManager switch being network.service instead of NETWORKMANAGER=yes. The original report of network not being up after a DVD install is still valid. Back to Michal. I too have a problem with Networkmanager not starting at all, and therefore don't have any network :-( I manage it using yast lan each time I want to connect to a network. If I checkthe user networkmanager and try to enable it in KDE, no network appears in NetworkManager-kde :-( (In reply to comment #44) > I too have a problem with Networkmanager not starting at all, and therefore > don't have any network :-( > I manage it using yast lan each time I want to connect to a network. > > If I checkthe user networkmanager and try to enable it in KDE, no network > appears in NetworkManager-kde :-( Until the yast2 changes (comment 43), which are required to switch between /etc/init.d/network and NetworkManager.service are available in install or update repositories, use the following commands as root: systemctl stop network.service systemctl --force enable NetworkManager.service systemctl start network.service See bug #800771 for more details. And yes, that fixed it for me :-) How amazing is this. Report issue, couple of hours later there is a reply with a viable sollution. Love openSuse (In reply to comment #40) > /usr/lib/YaST2/startup/Second-Stage/S09-cleanup stops the network. Exactly. See also bug#800365, which is already set as dependency of this bug. The 2nd stage is first trying to start network (without a check if the network were already running before or not) in S07-medium and sets a mark to stop it in S09-cleanup. Then yast2-network is started, which proposes some network configuration, that may switch to use NetworkManager [works since changes in comment 43] and restarts it at the end when possible (e.g. skipped in ssh-mode install). Finally, S09-cleanup stops the network (due to the mark). These start/stop requests either collide with the enqueued regular start job in systemd (and may cause a systemd deadlock in case when the network is enqueued to start after 2nd stage) or _cancel_ the job (network start before 2nd stage; see patches by Frederic). Have just tested Build107 DVD x86_64 incorporating Martin's fixed yast2 and yast2-network. Good: It is now possible to enable NetworkManager in the installed system using yast lan. Bad: In the first boot of the installed system, the initial value of the Network Setup Method radiobutton is still 'User Controlled with NetworkManager', when actually the traditional ifup method was started. So as Marius says in c47 ^, on initial boot of the installed system things are horked, and a further reboot (or force stop-start) is needed to get NM to come up as configured. *** Bug 807018 has been marked as a duplicate of this bug. *** *** Bug 806959 has been marked as a duplicate of this bug. *** This is an autogenerated message for OBS integration: This bug (798348) was mentioned in https://build.opensuse.org/request/show/161466 Maintenance / https://build.opensuse.org/request/show/161467 Maintenance / openSUSE-RU-2013:0598-1: An update that has three recommended fixes can now be installed. Category: recommended (low) Bug References: 798348,810381,811002 CVE References: Sources used: openSUSE 12.1 (src): netcontrol-0.2.8-0.3.7.1 openSUSE-RU-2013:0598-2: An update that has three recommended fixes can now be installed. Category: recommended (low) Bug References: 798348,810381,811002 CVE References: Sources used: openSUSE 12.2 (src): netcontrol-0.2.8-0.6.8.1 I don't want urge you or something, but 2 and a half month after the final version released, I did a dist upgrade. After a restart I lost my connection to my server, no SSH, nothing. It took me hours to find out what is the problem, until I found this report. I have no physical access to the server. In YaST ifup is checked as the current solution but I see "NetworkManager" in the output of the command "ps -ef | grep -i network". NM is buggy, but I don't care because I don't want to use it. Now I'm forced. So I ask two things: - how can I revert to ifup? Permanently. - after three months, please fix this bug already! Thank you. I found the answer how can I disable NM from the command line, without YaST: https://www.suse.com/releasenotes/x86_64/openSUSE/12.3/#sec.123.systemd-nm Removing the dependency on bnc#800365 (systemd: rcnetwork start in YaST2-Second-Stage.service blocks), so that I can close this one. The dependency is not clear to me anyway. I have tested with 13.1 Beta 1: - a KVM installation via virt-install, x86_64, DVD - My choices: Automatic configuration, KDE, btrfs, local authentication, no fw, enable ssh - NetworkManager was proposed to be installed, I deselected it. When the system has booted to KDE, the interface does have a DHCP supplied address, and "yast2 lan" correctly shows "traditional" as General/Network Setup Method. |
I just installed a recent Beta1 build in kvm and got no networkmanager (so far so good). But I didn't get any network either. linux-op4k:/home/col # /etc/init.d/network status Checking mandatory network interfaces: lo IP address: 127.0.0.1/8 lo is up running eth0 device: Realtek Semiconductor Co., Ltd. RTL-8139/8139 eth0 DHCP4 client NOT running eth0 DHCP6 client NOT running eth0 is up unused lo IP address: 127.0.0.1/8 lo is up running Checking service network . . . . . . . . . . . unused network.service - LSB: Configure the localfs depending network interfaces Loaded: loaded (/etc/init.d/network) Active: inactive (dead) CGroup: name=systemd:/system/network.service Jan 14 14:46:27 linux-op4k systemd[1]: Stopped LSB: Configure the localfs depending network interfaces. linux-op4k:/home/col # ifup eth0 eth0 device: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 20) Starting DHCP4+DHCP6 client on eth0. . . . . . . . eth0 IP address: 10.0.2.15/24 eth0 DHCP6 continues in background