workaround solution did not work.

I have no idea where eth0 should be associated with 8139too and eth1 with tulip.
Thought they used be set/associated/ in /etc/modprobe.conf

Did you run "dracut -f", after creating the persistent rules?

CC: (none) => davidwhodgins

(In reply to comment #2)
> Did you run "dracut -f", after creating the persistent rules?

No. I have no idea what I am doing. 

New/Improved temp Workaround solution:
copy /etc/udev/rules.d/*persistent* from a release 2 installed system and do a
dracut -f


I'll keep an eye out to see if that solves my problem. I do not know if the Source Rpm: should be udev or systemd. Looks like bug 4352 might jog someone's memory.

seems I have a similar issue, wifi should be eth1 and sometimes it's eth0


colin, something for you ?

CC: (none) => mageia
Source RPM: (none) => systemd ?
Whiteboard: (none) => 3alpha1

Yeah this is actually a known issue since the persistent net generators were dropped. It's on my todo to speak to Kay upstream about the alternative (which is biosname ethernet devices).

(In reply to comment #2)
> Did you run "dracut -f", after creating the persistent rules?

Yes, but network configuration is still fluid/broke/random.

It took 3 boots to get the network connection correct. :(
First boot picked nic 2, second boot pick nic 1 but nic 2 was picked as gateway.
Third boot picked nic 1 with gateway on nic 1 and I had internet connectivity.

This is a static setup for both nics and ifcfg-eth0/1 have NM_CONTROLLED=no

alpha2 and alpha3 good news and bad news.
Good news: Nic selection has improved dramatically. snippet from my reboot.log:
2012_10_03_18:50 reboot: 6
2012_10_04_15:35 reboot: 5
2012_10_07_13:53 reboot: 2
2012_10_08_18:47 reboot: 1
2012_10_10_07:49 reboot: 2
2012_10_11_16:03 reboot: 2
2012_10_12_20:45 reboot: 6
2012_10_13_19:16 reboot: 5
2012_10_14_19:19 reboot: 1
2012_10_15_07:26 reboot: 3
2012_10_15_10:20 reboot: 1
2012_10_17_20:50 reboot: 1
2012_10_17_21:05 reboot: 2
2012_10_20_19:23 reboot: 1
2012_10_21_15:06 reboot: 1
2012_10_23_14:44 reboot: 5
2012_10_31_15:52 reboot: 1
2012_11_01_03:35 reboot: 1
2012_11_02_19:10 reboot: 1
2012_11_09_04:51 reboot: 1
to reboot: 0

Bad news: still needs workaround fix to work:
copy /etc/udev/rules.d/*persistent* from a release 2 installed system and do a
dracut -f

*** Bug 8338 has been marked as a duplicate of this bug. ***

CC: (none) => djmarian4u

Two different parts of this feature were removed from upstream systemd/udev:
  - support for generation of the persistent net rules
  - support for switching the names of two interfaces  a <-> b
    (upstream udev now only supports renaming a -> c , b -> d)

I fixed the second part in systemd 194-3.mga3 so with the persistent network rules and a recent systemd package network renaming should work reliably again. I guess this is what's described in comment #7 .

Now the rule generation needs to be fixed. It shouldn't even be very hard to revert the upstream changes, but apparently it still looked complicated to me, probably because it's auto-detection stuff which I don't know much about.

Note that I reported this regression on Aug 16 to the development mailing list so it was already known at the time when this bug was created. Breakage was fully expected so I don't really think waiting is a good strategy.

CC: (none) => cjw

*** Bug 8451 has been marked as a duplicate of this bug. ***

CC: (none) => ftg

This should be fixed now as I've added back in the (horrible, ugly, evil) persistent-net rules generator.

We will be removing this in Mageia 4 for good (yippee) and will replace it with the predictable network device names system provided by newer systemd/udev: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

Please reopen if this is still a problem.

Status: NEW => RESOLVED
Resolution: (none) => FIXED