Bug 4352 - 2_a3: wrong nic selected for eth0 50% of the time
Summary: 2_a3: wrong nic selected for eth0 50% of the time
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Colin Guthrie
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-30 21:55 CET by Bit Twister
Modified: 2012-02-27 01:22 CET (History)
5 users (show)

See Also:
Source RPM: udev-181-1.mga2.src.rpm
CVE:
Status comment:


Attachments
log and configuration info (3.00 KB, text/plain)
2012-01-30 21:57 CET, Bit Twister
Details
ifcfg-eth0 contents. Has all normal information (249 bytes, application/octet-stream)
2012-02-25 21:16 CET, Jeff Robins
Details
ifcfg-eth1 contents. Only Minimal information (70 bytes, application/octet-stream)
2012-02-25 21:17 CET, Jeff Robins
Details

Description Bit Twister 2012-01-30 21:55:59 CET
Description of problem:

About 50% of the time, the wrong nic (Realtek) is selected as eth0 during boot.

linksys nic using tulip driver is wired to switch which is connected to Fios router. That needs to be eth0.

On motherboard Realtek nic is wired to a HomerunDual TV network tuner.

Version-Release number of selected component (if applicable):


How reproducible: Fails about 50% of the time.


Steps to Reproduce:
1. clean alpha3 install, updates applied.
2. reboot
3. check for lan connectivity
4. run steps 2 and 3.
Comment 1 Bit Twister 2012-01-30 21:57:14 CET
Created attachment 1465 [details]
log and configuration info
Bit Twister 2012-02-11 17:29:03 CET

Severity: normal => major

Comment 2 Jeffrey Laramie 2012-02-22 01:18:57 CET
I can confirm that Beta 1 i586 also re-assigns eth0 to a different card on multi NIC boxes. There may also be a problem enabling packet forwarding but I'm unfamiliar with the Mageia network configuration tools so I'm still working on that one.

CC: (none) => jalaramie

Comment 3 Bit Twister 2012-02-22 02:20:17 CET
(In reply to comment #2)
> There may also be a problem enabling packet forwarding but I'm
> unfamiliar with the Mageia network configuration tools so I'm still working on
> that one.

I can not remember if there is a configuration screen to set it.
I set net.ipv4.ip_forward = 1 in /etc/sysctl.conf when I use to need it. :)

There is a keyword you can set in /etc/sysconfig/network and/or in
/etc/sysconfig/network-scripts/ifcfg-<interface-name>

search for forwarding in /usr/share/doc/initscripts/sysconfig.txt
Be sure to backup to the file name then start reading back towards the keyword.
Some keywords are obsolete/superseded.....

Hardware: x86_64 => All

Comment 4 Jeffrey Laramie 2012-02-22 02:44:43 CET
The Control Center has a Network & Internet -> Share the Internet Connection with other local machines screen which sounds like it enables forwarding, but it isn't working for me. It asks which card is connected to the internet which is odd since I don't think the forwarding parameter is interface specific. As far as I know it's enabled or not. Then after I select the card it gives me an error that "No ethernet network adapter configured for LAN has been detected on your system." which is odd since the machine has 2 other correctly configured NICs.

I run my own iptables configuration script and many years ago I once had to insert something like "echo 1 > /proc/sys/net/ipv4/ip_forward" to get forwarding to work. Probably sets the same parameter you set in sysctl.conf.

Jeff
Comment 5 Bit Twister 2012-02-22 03:28:36 CET
(In reply to comment #4)
> The Control Center has a Network & Internet -> Share the Internet Connection
> with other local machines screen which sounds like it enables forwarding, but
> it isn't working for me. It asks which card is connected to the internet which
> is odd since I don't think the forwarding parameter is interface specific.

All I can say is read sysconfig.txt :)

> As
> far as I know it's enabled or not. Then after I select the card it gives me an
> error that "No ethernet network adapter configured for LAN has been detected on
> your system." which is odd since the machine has 2 other correctly configured
> NICs.

No idea where exactly your problem is. Could be it knows to not to work with already configured nics and therefore the no nic error. Add the correct keyword/value found in sysconfig.txt to the /etc/sysconfig/network-scripts/ifcfg-<interface-name> and see how it goes.

> I run my own iptables configuration script and many years ago I once had to
> insert something like "echo 1 > /proc/sys/net/ipv4/ip_forward" to get
> forwarding to work. Probably sets the same parameter you set in sysctl.conf.

More like sysctl.conf sets the same parameter you set with echo statement. :-D
For sysctl.conf, you drop the /proc/sys/, change the rest of / to . and you have the keyword for sysctl.conf.
Comment 6 Dave Hodgins 2012-02-22 04:56:11 CET
(In reply to comment #4)
> The Control Center has a Network & Internet -> Share the Internet Connection
> with other local machines screen which sounds like it enables forwarding, but
> it isn't working for me. It asks which card is connected to the internet which
> is odd since I don't think the forwarding parameter is interface specific. As
> far as I know it's enabled or not. Then after I select the card it gives me an
> error that "No ethernet network adapter configured for LAN has been detected on
> your system." which is odd since the machine has 2 other correctly configured
> NICs.

In mcc/Security, Go through "Set up your firewall", and ensure the nic
for the lan is NOT handled by the firewall.

Regarding the nics switching device name, my guess is that it's due to
/etc/udev/rules.d/70-persistent-net.rules not getting created/used,
as it is in Mageia 1.

Setting the rpm to udev, as I'm pretty sure that's the problem.

Source RPM: (none) => udev-181-1.mga2.src.rpm
CC: (none) => davidwhodgins

Comment 7 Jeffrey Laramie 2012-02-22 16:45:54 CET
(In reply to comment #5)
> (In reply to comment #4)
> > The Control Center has a Network & Internet -> Share the Internet Connection
> > with other local machines screen which sounds like it enables forwarding, but
> > it isn't working for me. It asks which card is connected to the internet which
> > is odd since I don't think the forwarding parameter is interface specific.
> 
> All I can say is read sysconfig.txt :)

Lot's of good info there. Thanks for the advice.
Comment 8 Jeffrey Laramie 2012-02-22 16:54:12 CET
(In reply to comment #6)
> (In reply to comment #4)
> > The Control Center has a Network & Internet -> Share the Internet Connection
> > with other local machines screen which sounds like it enables forwarding, but
> > it isn't working for me. It asks which card is connected to the internet which
> > is odd since I don't think the forwarding parameter is interface specific. As
> > far as I know it's enabled or not. Then after I select the card it gives me an
> > error that "No ethernet network adapter configured for LAN has been detected on
> > your system." which is odd since the machine has 2 other correctly configured
> > NICs.
> 
> In mcc/Security, Go through "Set up your firewall", and ensure the nic
> for the lan is NOT handled by the firewall.
> 
> Regarding the nics switching device name, my guess is that it's due to
> /etc/udev/rules.d/70-persistent-net.rules not getting created/used,
> as it is in Mageia 1.
> 
> Setting the rpm to udev, as I'm pretty sure that's the problem.

Hmmm, are you referring to the MCC -> Security -> Set up your personal firewall page? I don't see any place to identify NICs there. Also, since I run my own firewall script I've already checked the Everything(no firewall) box on that screen which ought to disable any further checks when enabling packet forwarding. I also looked at the Invictus page. That allows configuration by NIC, but it seems to be a different kind of configuration.
Comment 9 Jeffrey Laramie 2012-02-22 20:31:08 CET
(In reply to comment #6)
> Regarding the nics switching device name, my guess is that it's due to
> /etc/udev/rules.d/70-persistent-net.rules not getting created/used,
> as it is in Mageia 1.

As you guessed, this file does not exist on my system.
Comment 10 Dave Hodgins 2012-02-23 08:48:04 CET
(In reply to comment #8)
> Hmmm, are you referring to the MCC -> Security -> Set up your personal firewall
> page? I don't see any place to identify NICs there. Also, since I run my own
> firewall script I've already checked the Everything(no firewall) box on that
> screen which ought to disable any further checks when enabling packet
> forwarding. I also looked at the Invictus page. That allows configuration by
> NIC, but it seems to be a different kind of configuration.

I don't know if Invictus uses it's own config files or just updates
the shorewall files.  My understanding is that drakgw assumes shorewall
is in use, and if the lan nic shows up in "grep eth /etc/shorewall/*"
it won't work.

Ensure the lan nic doesn't show up in grep eth /etc/shorewall/*
Comment 11 Dave Hodgins 2012-02-23 08:49:34 CET
(In reply to comment #9)
> (In reply to comment #6)
> > Regarding the nics switching device name, my guess is that it's due to
> > /etc/udev/rules.d/70-persistent-net.rules not getting created/used,
> > as it is in Mageia 1.
> 
> As you guessed, this file does not exist on my system.

If you have a Mageia 1 system installed on the same computer,
try copying that file to the Mageia 2 installation.  If that
works, then we know the problem is simply udev failing to create
that file.
Comment 12 Bit Twister 2012-02-23 09:15:38 CET
(In reply to comment #11)

> If you have a Mageia 1 system installed on the same computer,
> try copying that file to the Mageia 2 installation.  If that
> works, then we know the problem is simply udev failing to create
> that file.

A word of caution, I can not remember when it happened but I have seen the format of 70-persistent-net.rules change. I think it was between 2010.0 and 2011.0 on Mandriva. I was always editing it to force eth0 to my linksys nic on new installs and gave up trying to automate my changes via a script at that point. :(
Comment 13 Jeffrey Laramie 2012-02-23 14:55:46 CET
(In reply to comment #11)
> (In reply to comment #9)
> > (In reply to comment #6)
> > > Regarding the nics switching device name, my guess is that it's due to
> > > /etc/udev/rules.d/70-persistent-net.rules not getting created/used,
> > > as it is in Mageia 1.
> > 
> > As you guessed, this file does not exist on my system.
> 
> If you have a Mageia 1 system installed on the same computer,
> try copying that file to the Mageia 2 installation.  If that
> works, then we know the problem is simply udev failing to create
> that file.

Unfortunately there is only the Beta on this box. I created my own file using ifconfig and a hacked Mageia 1 file from a different box, but it didn't work. If you think it's important I can re-install mga 1 on this box and grab a copy that way. I only changed the hardware address and the NIC name for each NIC so I think my hacked file was valid, but I can't really tell for sure.
Comment 14 Jeffrey Laramie 2012-02-23 15:15:06 CET
(In reply to comment #10)
> (In reply to comment #8)
> > Hmmm, are you referring to the MCC -> Security -> Set up your personal firewall
> > page? I don't see any place to identify NICs there. Also, since I run my own
> > firewall script I've already checked the Everything(no firewall) box on that
> > screen which ought to disable any further checks when enabling packet
> > forwarding. I also looked at the Invictus page. That allows configuration by
> > NIC, but it seems to be a different kind of configuration.
> 
> I don't know if Invictus uses it's own config files or just updates
> the shorewall files.  My understanding is that drakgw assumes shorewall
> is in use, and if the lan nic shows up in "grep eth /etc/shorewall/*"
> it won't work.
> 
> Ensure the lan nic doesn't show up in grep eth /etc/shorewall/*

Here is the output of grep eth /etc/shorewall/* :

/etc/shorewall/interfaces:net   eth2    detect
/etc/shorewall/interfaces:net   eth1    detect
/etc/shorewall/interfaces:net   eth0    detect
/etc/shorewall/params:#         NET_IF=eth0
/etc/shorewall/params:#         net     eth0            130.252.100.255 routefilter,norfc1918

All 3 interfaces show up. I don't know where the params settings came from. I never set eth0 as an internet facing card (I haven't found a way to do that yet) and that IP addr isn't mine. I assume these are default settings of some sort.
Comment 15 Dave Hodgins 2012-02-24 00:01:35 CET
(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #9)
> > > (In reply to comment #6)
> > > > Regarding the nics switching device name, my guess is that it's due to
> > > > /etc/udev/rules.d/70-persistent-net.rules not getting created/used,
> > > > as it is in Mageia 1.
> Unfortunately there is only the Beta on this box. I created my own file using
> ifconfig and a hacked Mageia 1 file from a different box, but it didn't work.
> If you think it's important I can re-install mga 1 on this box and grab a copy
> that way. I only changed the hardware address and the NIC name for each NIC so
> I think my hacked file was valid, but I can't really tell for sure.

I don't think that's critical.  I just have to dig a bit to figure out
why the file isn't being created now, in order to ensure the report
goes to the correct package.  I'll do that later today.
Comment 16 Dave Hodgins 2012-02-24 00:04:24 CET
(In reply to comment #14)
> Here is the output of grep eth /etc/shorewall/* :
> 
> /etc/shorewall/interfaces:net   eth2    detect
> /etc/shorewall/interfaces:net   eth1    detect
> /etc/shorewall/interfaces:net   eth0    detect
> /etc/shorewall/params:#         NET_IF=eth0
> /etc/shorewall/params:#         net     eth0            130.252.100.255
> routefilter,norfc1918
> 
> All 3 interfaces show up. I don't know where the params settings came from. I
> never set eth0 as an internet facing card (I haven't found a way to do that
> yet) and that IP addr isn't mine. I assume these are default settings of some
> sort.

You can igore the params file, as those are just the comments explaining
how statements should be formatted.

Remove the lan nic from the interfaces file, and then mcc should be
able to set up the internet sharing.

In drakfirewall, the option to control which nics are in that file
is on the screen that shows up when you select next, on the screen
where you select which ports to have open.
Comment 17 Dave Hodgins 2012-02-24 01:58:32 CET
/etc/udev/rules.d/70-persistent-net.rules
should be getting created by
/usr/lib/libDrakX/network/connection/ethernet.pm
but for some reason isn't.

Now I have to figure out why, as the file ethernet.pm has not
changed since Mageia 1.
Comment 18 Dave Hodgins 2012-02-24 02:23:03 CET
I think there are two separate problems here.

First /etc/udev/rules.d/70-persistent-net.rules isn't being created
using the beta 1 dvd.

Second, even if it exists, which it does in one of my cauldron
installs, it doesn't get included in the initrd by dracut, so it
won't be available when udev first starts, although I haven't
confirmed that the ethernet is processed by udev before the root
pivot.
Comment 19 Jeffrey Laramie 2012-02-24 04:02:48 CET
(In reply to comment #18)
> I think there are two separate problems here.
> 
> First /etc/udev/rules.d/70-persistent-net.rules isn't being created
> using the beta 1 dvd.
> 
> Second, even if it exists, which it does in one of my cauldron
> installs, it doesn't get included in the initrd by dracut, so it
> won't be available when udev first starts, although I haven't
> confirmed that the ethernet is processed by udev before the root
> pivot.

FYI, I do a network install from a local cauldron mirror so it's not specific to the dvd. And as I indicated earlier even a manually created file is ignored here so that is consistent with your suggestion of a second issue.
Comment 20 Jeffrey Laramie 2012-02-24 04:42:56 CET
(In reply to comment #16)
> (In reply to comment #14)
> > Here is the output of grep eth /etc/shorewall/* :
> > 
> > /etc/shorewall/interfaces:net   eth2    detect
> > /etc/shorewall/interfaces:net   eth1    detect
> > /etc/shorewall/interfaces:net   eth0    detect
> > /etc/shorewall/params:#         NET_IF=eth0
> > /etc/shorewall/params:#         net     eth0            130.252.100.255
> > routefilter,norfc1918
> > 
> > All 3 interfaces show up. I don't know where the params settings came from. I
> > never set eth0 as an internet facing card (I haven't found a way to do that
> > yet) and that IP addr isn't mine. I assume these are default settings of some
> > sort.
> 
> You can igore the params file, as those are just the comments explaining
> how statements should be formatted.
> 
> Remove the lan nic from the interfaces file, and then mcc should be
> able to set up the internet sharing.
> 
> In drakfirewall, the option to control which nics are in that file
> is on the screen that shows up when you select next, on the screen
> where you select which ports to have open.

Well we may have a 3rd bug, or at least a feature request. I seems that when the firewall is disabled those next screens don't show up. I tried enabling a port just to test and sure enough there was a screen that asked which NIC to apply the rules to. But if you have the firewall disabled those screens (correctly) don't get displayed. The problem is that the module that configures packet forwarding assumes you have enabled shorewall and requires those settings or it won't enable forwarding. So in essence there is no way to enable forwarding though drakconf without also enabling shorewall. I know how to work around this manually but I shouldn't have to.

I frankly think having a separate module to enable forwarding is unnecessary anyway. A simple checkbox in the main network configuration module is all that's needed and that is all any other distro has. Anyone setting up a box as a router/firewall ought to be savvy enough to know that a router requires a more advanced firewall configuration. At most a reminder to configure the firewall for routing would be all that is needed, IMHO.
Comment 21 Dave Hodgins 2012-02-24 05:15:56 CET
Let's try to keep this bug report about the multiple nics getting
the wrong order.  It's getting to be a lot of scrolling to read
this bug report.

Please open a new bug report about the firewall/drakgw.

I've posted a summary of what I've found on the developers mailing
list asking for help in trouble shooting the multiple nics problem.
Comment 22 Bit Twister 2012-02-25 13:10:29 CET
(In reply to comment #17)
> /etc/udev/rules.d/70-persistent-net.rules
> should be getting created by
> /usr/lib/libDrakX/network/connection/ethernet.pm
> but for some reason isn't.
> 
> Now I have to figure out why, as the file ethernet.pm has not
> changed since Mageia 1.

You might check to see if bug 4695 is root cause.
Comment 23 Jeffrey Laramie 2012-02-25 17:07:00 CET
(In reply to comment #22)
> (In reply to comment #17)
> > /etc/udev/rules.d/70-persistent-net.rules
> > should be getting created by
> > /usr/lib/libDrakX/network/connection/ethernet.pm
> > but for some reason isn't.
> > 
> > Now I have to figure out why, as the file ethernet.pm has not
> > changed since Mageia 1.
> 
> You might check to see if bug 4695 is root cause.

My system shows this bug also.
Comment 24 Jeff Robins 2012-02-25 21:14:23 CET
I also have this problem.  As an added benefit, "service network start/stop/restart" only act on eth1 and lo.  If the NIC I have connected to the network cable comes up as eth0, then I have to run "ifconfig eth0 up" manually.  Network Center doesn't know it's up until I run "dhclient eth0" manually, but it did manage to get an ip-address before.  Everything works fine if the NIC with the network cable is eth1.

"ifcfg-eth0" has all of the proper information, but "ifcfg-eth1" only has minimal info.

I will attached "ifcfg-eth0" and "ifcfg-eth1".

CC: (none) => jeffrobinsSAE

Comment 25 Jeff Robins 2012-02-25 21:16:38 CET
Created attachment 1632 [details]
ifcfg-eth0 contents. Has all normal information

ifcfg-eth0 contents. Has all normal information
Comment 26 Jeff Robins 2012-02-25 21:17:17 CET
Created attachment 1633 [details]
ifcfg-eth1 contents. Only Minimal information

ifcfg-eth1 contents. Only Minimal information
AL13N 2012-02-25 21:29:41 CET

CC: (none) => alien, mageia

Comment 27 Jeffrey Laramie 2012-02-25 22:18:12 CET
I did a little more digging and when I grep udev in my system logs I get a couple other errors. Not sure if they are related to this bug or not, but they seem to be:

Feb 25 10:26:31 Cedar1 draknetcenter[19728]: running: /lib/udev/write_net_rules 00:11:09:01:8f:2b
Feb 25 10:26:31 Cedar1 draknetcenter[19728]: program not found: /lib/udev/write_net_rules
Feb 25 10:39:44 Cedar1 udev-post[482]: Retrigger failed udev eventsunknown type --type=failed
Feb 25 10:39:44 Cedar1 udevadm[550]: unknown type --type=failed
Feb 25 10:39:44 Cedar1 udev-post[482]: [  OK  ]
Feb 25 10:47:18 Cedar1 udevadm[543]: unknown type --type=failed
Feb 25 10:47:18 Cedar1 udev-post[483]: Retrigger failed udev eventsunknown type --type=failed
Feb 25 10:47:18 Cedar1 udev-post[483]: [  OK  ]
Feb 25 10:55:22 Cedar1 udev-post[492]: Retrigger failed udev eventsunknown type --type=failed
Feb 25 10:55:22 Cedar1 udevadm[559]: unknown type --type=failed
Feb 25 10:55:22 Cedar1 udev-post[492]: [  OK  ]
Comment 28 Dave Hodgins 2012-02-25 23:33:32 CET
That's it!  This is definitely a udev bug, as the file
/lib/udev/write_net_rules
is missing.
Comment 29 Bit Twister 2012-02-25 23:50:12 CET
(In reply to comment #28)
> That's it!  This is definitely a udev bug, as the file
> /lib/udev/write_net_rules
> is missing.

Yeah, but I tried a copy from mandriva 2011 and grep eth /etc/udev/rules.d/ did not show anything.  :(
Comment 30 Dave Hodgins 2012-02-26 01:54:26 CET
(In reply to comment #29)
> (In reply to comment #28)
> > That's it!  This is definitely a udev bug, as the file
> > /lib/udev/write_net_rules
> > is missing.
> 
> Yeah, but I tried a copy from mandriva 2011 and grep eth /etc/udev/rules.d/ did
> not show anything.  :(

That script in turn needs
/lib/udev/rule_generator.functions

I copied both files from my Mageia 1 install to the install done with
the beta 1 dvd.  Using draknetcenter to change the config for eth0
now results in the 70-persistent-net.rules file getting written.
Comment 31 Dave Hodgins 2012-02-26 01:58:04 CET
In addition, the file
/lib/udev/rules.d/75-persistent-net-generator.rules
needs to be copied so that the file gets updated when a new
nic is found.
Comment 32 Bit Twister 2012-02-26 05:57:33 CET
(In reply to comment #31)
> In addition, the file
> /lib/udev/rules.d/75-persistent-net-generator.rules
> needs to be copied so that the file gets updated when a new
> nic is found.

Still no persistent-net rules after copying that file from Mandriva 2011 and rebooting.

Used MCC to delete/create both nics, no error messages on console, reboot.
No net rule.

What's new in the logs:

First two lines in /var/log/boot.log
udevd[162]: could not find module by name='tulip'
udevd[162]: could not find module by name='8139too'

Some dmesg snippets showing the drivers loaded sometime later:
8139too: 8139too Fast Ethernet driver 0.9.28
8139too 0000:02:03.0: eth0: RealTek RTL8139 at 0xf.....
8139too 0000:02:03.0: eth0: link up

tulip: Linux Tulip driver version 1.1.15 (Feb 27, 2007)
tulip0:  MII transceiver #1 config 3100 status 7829 advertising 01e1

All the above is with latest updates and running 
uname -r
3.2.7-desktop-1.mga2

Know of any command line congfu tricks to force both modules into initrd?
Comment 33 AL13N 2012-02-26 09:50:27 CET
normally, they are not needed in the initrd, only if you wanted to have pxe from it.

the thing is with udev moved to initrd, i dont know if that would effect them. in any case, if the net generator rules are present in udev, and there should be a udev systemd thing to handle the missing udev stuff from initrd, and that should trigger the file being written.
Comment 34 Colin Guthrie 2012-02-26 23:18:09 CET
Yup these scripts and rules are not copied from udev sources. I'll take a look.
Comment 35 Colin Guthrie 2012-02-26 23:40:51 CET
OK, seems the rule_generator was disabled during update to udev 175. I've re-enabled it in udev-181-3.mga2

If you enable the network module in dracut, I now include the generated rules, so both cases should be covered.

Please test and close if the bug is fixed for you.

Status: NEW => ASSIGNED
Assignee: bugsquad => mageia

Comment 36 Bit Twister 2012-02-27 00:26:40 CET
(In reply to comment #35)

> If you enable the network module in dracut, 

Just a dumb user here. No idea about "enable the network module in dracut"

> I now include the generated rules, so both cases should be covered.

Hmmm, have installed latest updates, one of which is udev-181-2.mga2

did a reboot and no net rules.. :(
# cd /etc/udev/rules.d
# ls -1
10-vboxdrv.rules
40-hplip.rules
56-hpmud_support.rules
60-libsane.rules
60-raw.rules
61-x11-input.rules
69-floppy-acl.rules
86-hpmud_plugin.rules
91-drm-modeset.rules
alsa.rules
Comment 37 Colin Guthrie 2012-02-27 00:31:35 CET
(In reply to comment #36)
> (In reply to comment #35)
> 
> > If you enable the network module in dracut, 
> 
> Just a dumb user here. No idea about "enable the network module in dracut"

from "man dracut":

       -a, --add <list of dracut modules>
           add a space-separated list of dracut modules to the default set of
           modules. This parameter can be specified multiple times.

           If [LIST] has multiple arguments, then you have to put these in
           quotes. For example:

               # dracut --add "module1 module2"  ...


So you can add it this way, but again, using the network module of dracut is quite a special use case (typically used for NFS root or similar setups - often with the ramdisk loaded over TFTP with a PXE boot loader). I was mentioning it more for clarity and information rather than expecting any specific tests.

> > I now include the generated rules, so both cases should be covered.
> 
> Hmmm, have installed latest updates, one of which is udev-181-2.mga2

Sadly, it is udev-181-3.mga2 that is needed here.... (you were unlucky with timing as I uploaded it ~35 minutes after the 2 version! Check the rpm -q --changelog udev output to be sure of that the version you have has the fix)
Comment 38 Bit Twister 2012-02-27 01:17:30 CET
(In reply to comment #37)

> Sadly, it is udev-181-3.mga2 that is needed here.... (you were unlucky with
> timing 

Yeah, Murphy has been riding my shoulder throughout this release.

> as I uploaded it ~35 minutes after the 2 version! Check the rpm -q
> --changelog udev output to be sure of that the version you have has the fix)

Much better. also picked up my cdrom definitions which was about to be my next bug.

70-persistent-cd.rules
70-persistent-net.rules


Last show stopper for me is bug 4021, which was not a problem in Alpha2.
That is preventing Voice Over Ip/ekiga operation.

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

Comment 39 Jeffrey Laramie 2012-02-27 01:22:26 CET
> Much better. also picked up my cdrom definitions which was about to be my next
> bug.
> 
> 70-persistent-cd.rules
> 70-persistent-net.rules

Same here. Let's close this one. Thanks for everyone's help!

Note You need to log in before you can comment on or make changes to this bug.