Running zypper up on 3 Opensuse 13.1 X64 systems today (20/3) has caused ifup LAN networking to fail.
It seems there is a update causing havoc on the ifup network method, making networking on all the systems useless unless i switch to network manager. … or manually after every reboot starts ifup.
what’s causing the ifup trouble on opensuse 13.1 X64 as of today ?
any adwise on how to get ifup workign again after i reboot the system?
Ok I got a bit further. Have defined a multitude of lan cards because i’m using autoyast on many different hardware configurations. Thanks to predictable network names i had to add eno1, enp0s25, ens33 etc… in my autoyast profile. thoose are all put into /etc/sysconfig/network by autoyast.
if i remove the ones that are not used in /etc/sysconfig/network and restart my network. ifup is working fine again.
i got the (aparantly wrong??) impression that i could define as many predictable network names is i like, since the only device name that will be used is the one that actually matches the hardware.
Or you can name your interfaces manually by rules in /etc/udev/rules.d/70-persistent-net.rules which will not be touched on updates. YaST creates them if you rename your interfaces in Network Devices->Network Settings.
I updated yesterday and had the same issue - i was not able to access the internet - port unreachable. This is an error in the update - i rebuilt yesterday and accessed for a while - then today again same error.
I deleted the ethernet controller and this allowed access.
As such - can you state what i need to do to correct the issue - in easy steps please - as i am not a Linux networking person.
I can used the command line no issues - just need to know the setup for networking - i use OEL at work - but this aspect is new to me.
I ran into the same problem upgrading from 12.3 to 13.1…the dvd upgrade worked great but as soon as I let it grab updates I lost my ethernet connections…I’ve verified that network manager gets them back but that’s some poor testing on their part if they missed this. Has anyone identified what rpm’s we should NOT upgrade to avoid the issue?
To find Network Manager - go to system tray and right hand button click.
Next - go to Yast (you will need root password) and once in YAST click the Network Setting -> then select Global Option and set Network Manager as the management.
ifup does not work.
Opensuse needs to state how to correct - to ensure ifup works in future.
The problem is - for many once their network fails - they will NOT be able to use the internet to find out how to resolve. Perhaps some people have two PC’s - but this is a show stopper for many people - Opensuse need to react to this faster - or at least provide how to use Network manager.
Sorry, but I still don’t see a problem. I just switched to ifup on my fully updated 13.1 64bit system (was using NetworkManager before), and everything’s still working fine here, even after a reboot.
Have you checked that you have no duplicated interfaces?
If you do, removing them should help.
Opensuse needs to state how to correct - to ensure ifup works in future.
Have you (or anybody else that has a problem) filed a bug report? http://bugzilla.novell.org/ (same username/password as here)
Maybe it’s not a general problem (it doesn’t seem to be), but some bug that happens only on specific systems?
As long as nobody reports it, the developers might not even be aware that there is a problem…
> The problem is - for many once their network fails - they will NOT be
> able to use the internet to find out how to resolve. Perhaps some people
> have two PC’s - but this is a show stopper for many people - Opensuse
> need to react to this faster - or at least provide how to use Network
> manager.
I updated yesterday, less than 12 hours ago, and I use ifup. I have no
issues whatsoever, not a glitch. There is nothing to react to unless we
really find what exactly broke.
I actually updated my machine in the hope of seeing it break and
investigate the issue…
For instance. What exact repositories do you use? Post the output of
“zypper lr --details”, and please do so inside code tags (the ‘#’ button
in the forum editor). See photo
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Well here are a couple of answers…when the problem occurs you have two options to solve it:
Rerun the opensuse 13.1 CD/DVD and choose “update” to overwrite to the original files which have network running fine.
Switch to network manager and start the widget in the panel.
In testing I found the problem occurs even if the only 4 libraries you have enabled are:
Opensuse-Current OSS
Opensuse-Current Non-OSS
Opensuse-Current OSS Updates
Opensuse-Current Non-OSS Updates
Opensuse-Current is symbolically linked to the opensuse 13.1 repo’s. I identified this before upgrading my system to tumbleweed. The problem does not appear to be hardware specific as I installed a realtek gigabit ethernet card in my pc after the Qualcomm Atheros AR8161 Gigabit Ethernet quit working and it behaved in an identical manner till I swapped over to network manager. If you want commands ran to pull info from messages or dmesg let me know what commands you want ran. My interface was/is eth1 and I can re-enable the issue by switching back to ifup.
> In testing I found the problem occurs even if the only 4 libraries you
> have enabled are:
> 1) Opensuse-Current OSS
> 2) Opensuse-Current Non-OSS
> 3) Opensuse-Current OSS Updates
> 4) Opensuse-Current Non-OSS Updates
>
> Opensuse-Current is symbolically linked to the opensuse 13.1 repo’s.
Please note that you should not be using the “current” links, unless you
intend to use Tumbleweed.
Reason: things will break for people using 13.1 when 13.2 gets released.
I hope that the people reporting this problem are not using tumbleweed
repos.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
You’ll note I did say I upgraded to tumbleweed. The person reporting the original issue was not on tumbleweed therefore the 13.1 repo’s also cause the issue. Lets not confuse things further. If someone knew what had been updated in the last week or two in the normal repo’s it would narrow the suspect packages immensely. Since I ended up reinstalling about 4 times while tracking down which repo’s caused the issue I’m unwilling to do it again.
> If someone knew
> what had been updated in the last week or two in the normal repo’s it
> would narrow the suspect packages immensely. Since I ended up
> reinstalling about 4 times while tracking down which repo’s caused the
> issue I’m unwilling to do it again.
Ok, but finding out what you updated is easy. There is an history log,
and you can also produce a list of packages with install/update date.
But if, as I understand, you reinstalled the system, this can not be
done, as we can not differentiate in the logs, by date, when it stopped
working. All packages will be stamped at the reinstall date.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Thanks! That will come in handy in future…unfortunately I don’t see anything obvious in the list of packages that screams “hey I’m the package breaking your ifup network config”.
This one is apparently caused by the fix for https://bugzilla.novell.com/show_bug.cgi?id=846361, so that would be the “sysconfig” update (openSUSE-2014-217).
Try to revert “sysconfig”, “sysconfig-network”, “sysconfig-netconfig”, and “udevmountd” to the previous versions (I’m not sure which one is the exact package that causes it).
it’s definetly the package sysconfig-network version 0.81.5-22.1 causing the issues. rolling back to version 0.81.5-18.1 works … as expected.
could the timeout have been changed to a value a bit too low for starting up the ifup device in the system boot process?. since starting it manually works?
consider this.
one (I) might be using many lan device configurations (to support many different hardware configs) because of you guys introducing predictable network interface naming, and making it the default network routine.
Then, at the boot process… you are initiating all the devices until you reach one that works… and that takes time. if the timeout is too stringent and the working device is the last in the list … it will never start up…
thats why clearing the unused devices in /etdc/sysconfig/network works!