devil-linux-develop

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Stephen H F R. <shf...@gm...>]

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...>

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Stefan E. <ma...@en...>]

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...>
> 
> ------------------------------------------------------------------------------
> 
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Serge L. <fi...@in...>]

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...>
>>
>> ------------------------------------------------------------------------------

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Stefan E. <ma...@en...>]

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
> 
> 

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Heiko Z. <he...@zu...>]

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

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Heiko Z. <he...@zu...>]

I did remove the mactab feature from CVS.
I had to manually merge a few lines from Serge's last change, so
hopefully I didn't fat-finger anything.

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

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Dominic R. <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

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Heiko Z. <he...@zu...>]

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
>



-- 

Regards
   Heiko Zuerker
   http://www.devil-linux.org


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Serge L. <ser...@gm...>]

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
>>
> 
> 
> 

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Dominic R. <dl...@ed...>]

  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
>

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Stefan E. <ma...@en...>]

Thanks, then I can now remove one more patch from my setup.

Regards,
Stefan

On 08/31/2010 04:28 PM, 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
> 
> 

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Stefan E. <ma...@en...>]

Forget the last reply. It was meant for Heiko's mail regarding "Possible
to build util-linux earlier?".

Regards,
Stefan

On 09/01/2010 09:21 PM, Stefan Engel wrote:
> Thanks, then I can now remove one more patch from my setup.
> 
> Regards,
> Stefan
> 
> On 08/31/2010 04:28 PM, 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
>>
>>
> 
> 
> ------------------------------------------------------------------------------
> 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
> 
> 

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Serge L. <ser...@gm...>]

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
> 

Re: [Devil-linux-develop] Enable "nameif" to associate MAC address with correct interface name

[Dominic R. <dl...@ed...>]

Serge,

That's now done, with patch against 1.50 which is the latest I can find 
in cvs.

Dominic

On 01/09/2010 21:17, Serge Leschinsky wrote:
> 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
>>
>
>
> ------------------------------------------------------------------------------
> 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