I have the very same issue. But in my case I only have two (2) interfaces defined and it still doesn’t come up. I have to manually “ifup” them every single time.
So as long as “cleaning up” does not exactly come down to “ONE” interface, this doesn’t work (for me). The devices are configured to start at boot and yet they are offline after boot.
I want to point out: I have the issue even though I use the new predictable interface names. Got rid of eth0 when reinstalling all fresh.
So right now we have lots of people complaining, we identified the package causing the error… I really hope for a patch soon, because this is the most annoying bug I’ve ever had throughout my usage of linux.
> So right now we have lots of people complaining, we identified the
> package causing the error… I really hope for a patch soon, because
> this is the most annoying bug I’ve ever had throughout my usage of
> linux.
I have seen worse. Large file writes to an encrypted xfs partition
causing the kernel to crash completely. I had to reformat those
partitions to reiserfs. The issue took years to be solved.
In your case, as the package that causes this has been identified, you
can simply revert to the previous version, and wait for a solution on
the bugzilla before doing the update again.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Sorry, but what exactly do you mean with that?
YaST shows 2 interfaces although you only have one? Or what?
Then remove all and configure the one you have.
You can try to give it a specific name (“eth0” f.e.) in “Edit”->“Hardware”, then this shouldn’t happen again.
But according to your description (IIUYC) this is a completely different issue than the one the others are facing (i.e. that connections that are setup to be started “on cable connect” don’t work anymore since that update).
If you want a fix for yours, you should open a new bug report. Hopefully you can reproduce the issue then, though.
No, my Mainboard has two interfaces and they are both in Yast. I shouldn’t be forced to delete a hardware that actually exists.
But the interfaces are not starting when the machine boots. I am forced to manually “ifup” after login.
And it also started after last weeks network-patch.
With the latest sysconfig-network patch the interfaces don’t come up automatically
When I check this against the headline of this thread it sure does seem to be the very same issue.
By the way: I manually reverted to th eold version of sysconfig-network. While this made everything work again, it gives me an update notification all the time. I locked the package in Yast to prevent updating, but I still get the annoying update notification. So while this works, it’s still annoying.
Maybe. I don’t know.
One difference is the start-mode. I thought that this problem was restricted to connections that start “on cable-connect”, because I couldn’t reproduce it with “on boot”. But if your problem is the same, that’s clearly not true then.
But there must be some specific setting to trigger this problem I guess. Because neither I nor Carlos are able to reproduce this.
If it was a general problem, we should see it too, by just switching to ifup, right?
And I did try with the new predictable interface names.
I fear that this doesn’t really make it easier to solve…
Well, let’s hope the cause is found soon.
Setting sysconfig-network back to the old version fixed it for me. So the issue really seems to be in what has changed in that package.
I’m just not smart enough to understand the changes or to debug it.
What I observed:
I have two machines here.
Behaviour PRE-Patch:
Both started up fine, my server came up pretty fast (sub 20 seconds).
The workstation had a long delay when initializing the network interfaces (approx. additional 30 secs).
This issue has been reported by quite a number of users in the past (in forums / buglists afair).
Behaviour POST-Patch:
The Server still starts up fine.
The workstation has the issues mentioned here.
The network hardware of the workstation is an on-board Realtek chip (RTL8111/8168B). Maybe it’s a combination of the chip/driver and the changes in the patch?
One of the people I was exchanging infos about this issues with reported, that his hardware had the same Pre-Patch delay when bringing up the interfaces.
The only thing I can see there causing a change in behaviour is if the $INTERFACETYPE is detected wrong.
So maybe add a “cat $INTERFACETYPE” there to see what it reports? (in /sbin/ifup, line ~300)
And check in your /etc/sysconfig/network/ifcfg-* files whether “INTERFACETYPE” is set there (it isn’t on my system).
Oops, sorry.
I meant “echo $INTERFACETYPE” of course. :shame:
And maybe redirect it to some file, so you don’t have to search the whole system log file.
Not really.
In that case, I don’t see how that patch would change the behaviour.
With $INTERFACETYPE=eth the “case” statement would leave SYSTEMD_REDIRECT at “yes”, and the “if” statement after that is the same as before (inverted of course).
So I don’t see what’s possibly going wrong, sorry.
Maybe check if that exec systemctl start “network@${INTERFACE}.service” is actually reached (and fails) or whether it’s not even called.
But if the “systemctl start” fails, I fail to see how it would be connected to that update…
PS: Have you (or anybody else that has/had this problem) ever run “sudo systemctl status network@${INTERFACE}.service” when network was not working? Maybe that would provide a clue?
We do agree that my interface was set to use ifup and as far as I understand id should NOT redirect to systemd?
Because after all, with the NEW sysconfig.network package, when the network failed, i don’t start it with “systemctl start” but with “ifup $Devicename” instead?
Ah, ok. Sorry, got a bit confused there.
In the case of booting, $PPID=1, so SYSTEMD_REDIRECT is set to “no” (and “systemctl start” is NOT called) in any case.
But that was the same even before that update.
So, there is ABSOLUTELY NO CHANGE regarding the boot behaviour with the update IMHO. (maybe I’m missing something here?)
Anyway, I have absolutely no idea anymore how that patch could cause your problem.:X
It could be caused by an incorrectly set “STARTMODE” in /etc/sysconfig/network/ifcfg-${INTERFACE} f.e., but as I already wrote, I don’t see how that update would have an influence there. It should have NOT worked before the update then as well…
ok, so. I broke my system again with updating sysconfig-network in order to run the commands mentioned above.
As expected the network doesn’t come up automatically.
/etc/init.d/network (which is called by /usr/lib/systemd/system/network.service in effect) is part of the sysconfig-network package, but it hasn’t changed in the latest update.
But apparently this script somehow digs out a wrong interface name.
One wild guess: maybe it gets the interface configurations from the initrd during boot?
Could you post:
Maybe you would just have to recreate your initrd (with “mkinitrd”) to fix your problem?
(but even in that case I don’t see why it would work before the update, but not after)
The same systemctl-command with the old package gives a slightly different output (again: I only downgraded sysconfig.network, nothing else):
systemctl status network.service
network.service - LSB: Configure network interfaces and set up routing
Loaded: loaded (/usr/lib/systemd/system/network.service; enabled)
Active: failed (Result: exit-code) since Di 2014-03-25 13:54:19 CET; 1min 54s ago
Process: 1183 ExecStart=/etc/init.d/network start (code=exited, status=7)
Main PID: 1183 (code=exited, status=7)
CGroup: /system.slice/network.service
Mär 25 13:53:48 SoltauSuseWorkstation network[1183]: lo
Mär 25 13:53:48 SoltauSuseWorkstation network[1183]: lo IP address: 127.0.0.1/8
Mär 25 13:53:57 SoltauSuseWorkstation network[1183]: …done…done enp8s0 Startmode is ‘manual’ → skipping
Mär 25 13:53:57 SoltauSuseWorkstation network[1183]: …skippedWaiting for mandatory devices: enp10s0
Mär 25 13:54:19 SoltauSuseWorkstation network[1183]: 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Mär 25 13:54:19 SoltauSuseWorkstation network[1183]: enp10s0 No interface found
Mär 25 13:54:19 SoltauSuseWorkstation network[1183]: …failedSetting up service network . . . . . . . . . . . . …failed
Mär 25 13:54:19 SoltauSuseWorkstation systemd[1]: network.service: main process exited, code=exited, status=7/NOTRUNNING
Mär 25 13:54:19 SoltauSuseWorkstation systemd[1]: Failed to start LSB: Configure network interfaces and set up routing.
Mär 25 13:54:19 SoltauSuseWorkstation systemd[1]: Unit network.service entered failed state.
Please note that now there is also enp8s0 which is the second onboard interface which is currently not configured.
And regardless of that status, the Interface enp7s0 comes up as expected and everything is online.
Not seeing why I should recreate initrd. It works with the old package and it doesn’t with the new one. And the initrd was created during a plain system setup from the DVD. Nothing tweaked by myself.
