From: Serge L. <ser...@gm...> - 2010-09-01 20:17:57
|
Dominic, may I ask you to reopen the FR#70 and upload the patch against the latest version of network script? Serge On 08/31/2010 07:28 AM, Dominic Raferd wrote: > Serge: > > Exactly so. I think this 'network redetect' works easily if there is one > network device (option 'r'). With more than one, and if the order > (eth0/eth1) matters, the user configures 70-persistent-net.rules > manually and then uses 'network redetect' with option 'k' to restart > networking; it makes life easier in this situation too. I haven't been > able to test it with wireless lan devices, though. > > BTW I see the existing network script has a never-executed call at the > end to a non-existent /etc/init.d/wlan. > > Dominic > > On 30/08/2010 21:50, Serge Leschinsky wrote: >> Heiko, Dominic, >> >> >> as far as I can see this feature is opposite to concatenation of >> 70-persistent-net.rules, and in essence it's a way to clean this file up from >> "outdated" records without reboot. For me it's "nice to have". >> >> >> Serge >> >> >> >> On 08/30/2010 08:33 AM, Heiko Zuerker wrote: >>> Does anybody have an opinion on this? >>> >>> Heiko >>> >>> Quoting Dominic Raferd<dl...@ed...>: >>> >>>> 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 >>>> ------------------------------------------------------------------------------ >>>> 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 >>>> >>> >>> >> >> ------------------------------------------------------------------------------ >> This SF.net Dev2Dev email is sponsored by: >> >> Show off your parallel programming skills. >> Enter the Intel(R) Threading Challenge 2010. >> http://p.sf.net/sfu/intel-thread-sfd >> _______________________________________________ >> Devil-linux-develop mailing list >> Dev...@li... >> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop >> > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > |