|
From: Dominic R. <dl...@ed...> - 2010-08-29 12:56:21
|
Back in April I submitted to Mantis some code for the /etc/init.d/network script which added a new 'redetect' options to allow redetection of changed network hardware https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=70. This was felt to be unnecessary because of the introduction of mactab, but it might be worth reconsidering if we are now removing mactab. Dominic Here's the help info for it: 'network redetect' will disrupt any existing network connection and may leave it broken. It is intended for use from a local terminal and in cases where network hardware has changed and needs to be reconfigured to work properly. Or (with 'k' option) where /etc/udev/rules.d/70-persistent-net.rules file has been changed manually, and the network needs to be restarted to reflect the changes. If pre-existing network hardware is working, but additional new network hardware is not, 'network redetect' is probably not the right tool - instead, configure the new hardware from the NET section of 'setup'. Usually you first run with option 'r', this stops the network, removes any prior information about network devices stored at /etc/udev/rules.d/70-persistent-net.rules, redetects network devices, recreates this file and then attempts to restart the network. To restart the network it needs a network module; if you choose the 'autoselect' option when and if requested, it will override any existing module set by 'setup' at /etc/sysconfig/nic/ifcfg-ethn and use the module suggested by udev. If this fails, reconfigure /etc/udev/rules.d/70-persistent-net.rules manually (for instance, switching the allocation of device NAMEs between eth0 and eth1) and then rerun 'network redetect' with the 'k' option. If you still have problems, check settings for the network device (including module) using 'setup'. When you have an operational network, save your changes with 'save-config -q'. > > Heiko > >> -----Original Message----- >> From: Heiko Zuerker [mailto:he...@zu...] >> Sent: Saturday, August 28, 2010 8:06 AM >> To: dev...@li... >> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC >> address with correct interface name >> >> Yes I agree, let's take it back out. >> >> Heiko >> >>> -----Original Message----- >>> From: Stefan Engel [mailto:ma...@en...] >>> Sent: Monday, August 23, 2010 4:12 AM >>> To: dev...@li... >>> Subject: Re: [Devil-linux-develop] Enable "nameif" to associate MAC >>> address with correct interface name >>> >>> Hi Serge, >>> >>> I just tested my config with > /etc/udev/rules.d/70-persistent-net.rules >>> with two VMs and it's working without problems. This solution looks >> like >>> the more elegant way to assign interface names to mac addresses. >>> >>> Seems that the changes we made for dealing with /etc/mactab and >>> /etc/mactable are more or less obsolete by now. >>> >>> udev already works in the correct way when assigning the interface >>> names, without the 'workaround' I made in the network script to get >> the >>> interface names right. So if nobody really needs the changes we made >>> for working with /etc/mactab, /etc/mactable, we could roolback these >>> changes. >>> >>> Regards, >>> Stefan >>> >>> On 08/22/2010 07:56 AM, Serge Leschinsky wrote: >>>> Hi guys, >>>> >>>> DL system has been retired recently and I found that the problem >> with >>>> MAC-interface name association was solved a bit differently. >> Probably >>>> I missed something - in this case I'm sorry in advance. >>>> >>>> The solution is based on udev rule (70-persistent-net.rules). The >> file >>>> below is a simple concatenation of 70-persistent-net.rules from 3 >>>> different DL systems, and I was able to copy configuration tarball >>>> between systems without problem with network interface renaming. >>> Is it the same what you wish to get? >>>> >>>> >>>> # cat /etc/udev/rules.d/70-persistent-net.rules >>>> # This file was automatically generated by the >>>> /lib/udev/write_net_rules # program, run by the persistent-net- >>> generator.rules rules file. >>>> # >>>> # You can modify it, as long as you keep each rule on a single # >> line, >>>> and change only the value of the NAME= key. >>>> >>>> # PCI device 0x10ec:0x8169 (r8169) >>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", >>>> ATTR{address}=="00:14:d1:16:ab:c5", ATTR{type}=="1", >>> KERNEL=="eth*", NAME="eth0" >>>> >>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net", >>>> ACTION=="add", DRIVERS=="?*", >> ATTR{address}=="00:0a:e6:88:8f:4d", >>>> ATTR{type}=="1", >>> KERNEL=="eth*", NAME="eth1" >>>> >>>> # PCI device 0x10ec:0x8169 (r8169) >>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", >>>> ATTR{address}=="00:14:d1:16:a8:cc", ATTR{type}=="1", >>> KERNEL=="eth*", NAME="eth1" >>>> >>>> # PCI device 0x10ec:0x8139 (8139too) SUBSYSTEM=="net", >>>> ACTION=="add", DRIVERS=="?*", >> ATTR{address}=="00:0d:87:26:33:9e", >>>> ATTR{type}=="1", >>> KERNEL=="eth*", NAME="eth0" >>>> >>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", >>>> ATTR{address}=="00:23:4d:0b:87:b2", ATTR{type}=="1", >>> KERNEL=="eth*", NAME="wlan0" >>>> >>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", >>>> ATTR{address}=="00:21:70:bc:07:76", ATTR{type}=="1", >>> KERNEL=="eth*", NAME="eth0" >>>> >>>> # PCI device 0x8086:0x10f5 (e1000e) >>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", >>>> ATTR{address}=="00:22:68:13:c2:3b", ATTR{type}=="1", >>> KERNEL=="eth*", NAME="eth1" >>>> >>>> # PCI device 0x8086:0x4237 (iwlagn) >>>> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", >>>> ATTR{address}=="00:1e:65:6b:22:64", ATTR{type}=="1", >>> KERNEL=="wlan*", NAME="wlan1" >>>> >>>> >>>> Serge >>>> >>>> >>>> On 06/18/2010 09:13 AM, Stefan Engel wrote: >>>>> Sorry for the late reply, holiday and work kept me busy. >>>>> >>>>> I have seen the bug #73 is resolved and the network script is now >>>>> available in the latest CVS snapshot. I am about to build my own >>>>> devil distro sometime during the next days. So far the script > looks >>>>> ok and should work as intended. >>>>> >>>>> Thanks for all helping to get this task done. >>>>> >>>>> Regards, >>>>> Stefan >>>>> >>>>> >>>>> On 05/25/2010 03:29 AM, Stephen H F Ralph wrote: >>>>>> Having given further thought to my earlier posting from work, > and >>>>>> hopefully to ease confusion between the differing network >> scripts, >> I >>>>>> have given a version of "1.44a" to the original mactab-modified >>>>>> script, and "1.44b" to the same file as further patched by > Stefan. >>>>>> >>>>>> Both files have been uploaded to mantis. >>>>>> >>>>>> If Stefan can confirm I have correctly added his modifications > to >>>>>> 1.44b, then I propose this is the file to use. >>>>>> >>>>>> I'd expect Heiko to strip the temporary branding 1.44a and > 1.44b, >> by >>> the way. >>>>>> >>>>>> Regards - Steve >>>>>> >>>>>> "Stephen H F Ralph"<shf...@gm...> >>>>>> >>>>>> >> -------------------------------------------------------------------- >>>>>> ---------- >>>> >>>> >> ---------------------------------------------------------------------- >>>> -------- >>>> This SF.net email is sponsored by >>>> >>>> Make an app they can't live without >>>> Enter the BlackBerry Developer Challenge >>>> http://p.sf.net/sfu/RIM-dev2dev >>>> _______________________________________________ >>>> Devil-linux-develop mailing list >>>> Dev...@li... >>>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >>>> >>>> >>> >>> >>> >> > ------------------------------------------------------------------------ >> ------ >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM- >>> dev2dev _______________________________________________ >>> Devil-linux-develop mailing list >>> Dev...@li... >>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >> >> >> > ------------------------------------------------------------------------ > ------ >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >> Be part of this innovative community and reach millions of netbook > users >> worldwide. Take advantage of special opportunities to increase revenue >> and speed time-to-market. Join now, and jumpstart your future. >> http://p.sf.net/sfu/intel-atom-d2d >> _______________________________________________ >> Devil-linux-develop mailing list >> Dev...@li... >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > > ------------------------------------------------------------------------------ > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop |