devil-linux-develop Mailing List for Devil-Linux (Page 18)

Regarding udev, I found info at 
http://www.reactivated.net/writing_udev_rules.html#why about how it 
works which mentions some udev tools - udevinfo, udevtest, udevtrigger, 
udevcontrol - which are missing in DL, and might be worth adding.

udevtrigger seems to be the way to reprocess udev rules without 
rebooting. Altering (or deleting) 70-persistent-net.rules + udevtrigger 
+ /etc/init.d/network restart should be a way to fix a broken network 
connection after a hardware change. At the moment I think you have to 
save-config and reboot instead of udevtrigger.

If this worked, then a new option could be added for the network script, 
say '-redetect' which would stop the network, delete 
70-persistent-net.rules, then run udevtrigger before starting the 
network again. It should also post an advisory message that the change 
will not persist under DL unless configuration is saved.

Dominic

On 26/04/2010 07:32, Frank Weis wrote:
> Hi,
>
> being a complete ignorant about how udev works internally, I wonder if
> it would be possible to put multiple entries in 70-persistent-net.rules,
> eg.
>
> ma:cc:ad:dr:es:s1 is eth0
> ma:cc:ad:dr:es:s2 is eth0
>
> ma:cc:ad:dr:es:s3 is eth1
> ma:cc:ad:dr:es:s4 is eth1
>
>
> Plan B:
> If that doesn't work (or can be hacked to work easily) I'd favour a
> solution which handles multiple etc-mods.tar.bz2 entirely. This would
> probably be interesting for other people/problems too (someone wanted to
> be able to roll back to the previous config recently)
>
> We'd need the following:
>
> *) save-config would need to be able to attach a label (that would go
> into the filename) and maybe a description.
>
> *) a way to specify which config is 'hot': there used to be boot options
> that specified where the config-file is and what it is called. See if
> it's still there and if it works.
>
> *) a tool to manage config files
> 	list,
> 	delete,
> 	copy,
> 	specify 'hot' file at next boot.
>
> What do you think? I'd be willing to invest some time into this if this
> can make us all happy...
>
> Frank
>
>
> Heiko Zuerker wrote:
>    
>> I took a quick look at our network init script.
>> I'm not sure about a good place to put the nameif line, since we may
>> required the module to be loaded first.
>> Honestly I'd rather stick with just the udev solution for now, but I'm
>> open to suggestions.
>>
>> Heiko
>>      

Hi,

being a complete ignorant about how udev works internally, I wonder if
it would be possible to put multiple entries in 70-persistent-net.rules,
eg.

ma:cc:ad:dr:es:s1 is eth0
ma:cc:ad:dr:es:s2 is eth0

ma:cc:ad:dr:es:s3 is eth1
ma:cc:ad:dr:es:s4 is eth1


Plan B:
If that doesn't work (or can be hacked to work easily) I'd favour a
solution which handles multiple etc-mods.tar.bz2 entirely. This would
probably be interesting for other people/problems too (someone wanted to
be able to roll back to the previous config recently)

We'd need the following:

*) save-config would need to be able to attach a label (that would go
into the filename) and maybe a description.

*) a way to specify which config is 'hot': there used to be boot options
that specified where the config-file is and what it is called. See if
it's still there and if it works.

*) a tool to manage config files
	list,
	delete,
	copy,
	specify 'hot' file at next boot.

What do you think? I'd be willing to invest some time into this if this
can make us all happy...

Frank


Heiko Zuerker wrote:
> I took a quick look at our network init script.
> I'm not sure about a good place to put the nameif line, since we may
> required the module to be loaded first.
> Honestly I'd rather stick with just the udev solution for now, but I'm
> open to suggestions.
> 
> Heiko
> 



-- 
_______________________________________________
 Centre de Technologie de l'Education
 29 avenue John F. Kennedy
 L-1855 Luxembourg-Kirchberg
 email: Fra...@ct...
 tél.: +352 247-85973
 fax: +352 333797
_______________________________________________

I took a quick look at our network init script.
I'm not sure about a good place to put the nameif line, since we may
required the module to be loaded first.
Honestly I'd rather stick with just the udev solution for now, but I'm
open to suggestions.

Heiko

> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: Tuesday, April 20, 2010 10:51 AM
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Feature request - Enable
> "nameif" to associate MAC address with correct interface name.
> 
> Are you saying that /etc/mactab does the same thing as
> /etc/udev/rules.d/70-persistent-net.rules ?
> 
> If so, should we do the same thing two different ways?
> 
>  - BS
> 
> 
> On Tue, Apr 20, 2010 at 11:30, Steve Ralph
> <Ste...@sa...> wrote:
> > Hi,
> >
> > As part of my investigations to the
> > "/etc/udev/rules.d/70-persistent-net.rules" issue reported just
> now, I
> > discovered the "/sbin/nameif" program, which reads the file
> "/etc/mactab" if
> > it exists, and associates interface names with mac-address.
> >
> > It has to be run prior to the interface(s) starting, so I
> envisage it hooked
> > into "/etc/init.d/network" to be called only if the file
> "/etc/mactab"
> > exists. "jiim-barber" on one of the debian lists offers "[ -x
> /sbin/nameif ]
> > && [ -r /etc/mactab ] && /sbin/nameif " as a code-frag that could
> be
> > included in "/etc/init.d/network".
> >
> > The format of "/etc/mactab" is:
> >
> >         #--- /etc/mactab : associate network interfaces with MAC
> address
> >         #
> >         eth0    00:08:02:01:02:03
> >         eth1    00:08:02:01:02:04
> >         eth2    00:08:02:01:02:05
> >         #
> >         #--- End
> >
> > I'd assume that the default config would *not* include
> "/etc/mactab" which
> > would only be created if the default udev-assignment needed to be
> modified.
> >
> > If this feature doesn't make it into release 1.4 I'll not be
> upset.
> >
> > Regards - Steve.
> 
> -------------------------------------------------------------------
> -----------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Bruce,

This does not help  the high speed firewall swap to standby hardware. The NIC sequence as the cold-standby starts up might require manual configuration.

Regards - Steve.

-----Original Message-----
From: Bruce Smith [mailto:bw...@re...]
Sent: 21 April 2010 15:47
To: dev...@li...
Subject: Re: [Devil-linux-develop] /etc/udev/rules.d/70-persistent-net.rules and /etc/mactab

Another idea I just came up with is to add an option to save-config to
save a new config file with a different name, omitting all hardware
specific files, who's purpose is to be transferred to a different
machine.

And since the new saved config file has a different name, there is no
chance of it being used upon boot by mistake, without manual renaming.

To do this, we'd need to come up with a list of files to omit.
Probably more than just the NIC related files.  LVM files?  Others?

That might be the quickest and easiest solution.  Thoughts?

 - BS


On Wed, Apr 21, 2010 at 10:40, Steve Ralph <Ste...@sa...> wrote:
> OK, thanks everyone.
>
> Taking on board everyone's comments to date, I'll combine my initial bug/feature requests into a new proposal.
>
> As the absence of "70-persistent-net.rules" may not generate the NIC assignments in the same order (which I agree could be disastrous for a firewall) then I now think that the present behaviour of save-config including "70-persistent-net.rules" should be retained.
>
> My test-environment on a usb-stick (used on differing hardware) is conceptually the same as Stefan's requirement to fail-over a saved config onto a cold standby box. While the impact on my usb test-build to correct persistent mac assignment is no real problem, if you are failing over a firewall you want a speedy swapover with as little messing as possible, assuming always that you have configured this upfront.
>
> Just patching /etc/init.d/network to call /sbin/nameif to align interfaces and mac-addresses will not, on it's own, address this scenario.
>
> What enabling a call to nameif and mactab does do is allow an administrator to take control of interface assignment, rather than having to work with whatever udev saves in 70-persistent-net.rules.
>
> My colleague Roy (the "linux-nut" of previous posts) has a proof-of-concept bash-script that reads a separate new config file /etc/mactable.conf pre-populated with multiple interface/mac-address details from *both* the current-active and the cold-standby hardware, and greps to populate /etc/mactab with only the entries relating to addresses discovered by "ifconfig -a". This would need to be called earlier in the startup sequence than network startup, which would then find a valid /etc/mactab for the booting hardware.
>
> Sequencing would need to be as follow (pseudo code):
>
>        if /etc/mactable.conf exists
>                then create or overwrite /etc/mactab from /etc/mactable.conf
>        fi
>        if /etc/mactab exists
>                then call nameif to use it
>        else
>                use the current behaviour (Eg: 70-persistent-net.rules)
>        fi
>
> So, if the requirement is to assign mac addresses to specific devices on a single system edit /etc/mactab, or If the requirement is to assign differect mac addresses to specific devices on a failover systems edit /etc/mactable.conf.
>
> Does this sound to be a way forward?
>
> Regards - Steve.
>

------------------------------------------------------------------------------
_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Another idea I just came up with is to add an option to save-config to
save a new config file with a different name, omitting all hardware
specific files, who's purpose is to be transferred to a different
machine.

And since the new saved config file has a different name, there is no
chance of it being used upon boot by mistake, without manual renaming.

To do this, we'd need to come up with a list of files to omit.
Probably more than just the NIC related files.  LVM files?  Others?

That might be the quickest and easiest solution.  Thoughts?

 - BS


On Wed, Apr 21, 2010 at 10:40, Steve Ralph <Ste...@sa...> wrote:
> OK, thanks everyone.
>
> Taking on board everyone's comments to date, I'll combine my initial bug/feature requests into a new proposal.
>
> As the absence of "70-persistent-net.rules" may not generate the NIC assignments in the same order (which I agree could be disastrous for a firewall) then I now think that the present behaviour of save-config including "70-persistent-net.rules" should be retained.
>
> My test-environment on a usb-stick (used on differing hardware) is conceptually the same as Stefan's requirement to fail-over a saved config onto a cold standby box. While the impact on my usb test-build to correct persistent mac assignment is no real problem, if you are failing over a firewall you want a speedy swapover with as little messing as possible, assuming always that you have configured this upfront.
>
> Just patching /etc/init.d/network to call /sbin/nameif to align interfaces and mac-addresses will not, on it's own, address this scenario.
>
> What enabling a call to nameif and mactab does do is allow an administrator to take control of interface assignment, rather than having to work with whatever udev saves in 70-persistent-net.rules.
>
> My colleague Roy (the "linux-nut" of previous posts) has a proof-of-concept bash-script that reads a separate new config file /etc/mactable.conf pre-populated with multiple interface/mac-address details from *both* the current-active and the cold-standby hardware, and greps to populate /etc/mactab with only the entries relating to addresses discovered by "ifconfig -a". This would need to be called earlier in the startup sequence than network startup, which would then find a valid /etc/mactab for the booting hardware.
>
> Sequencing would need to be as follow (pseudo code):
>
>        if /etc/mactable.conf exists
>                then create or overwrite /etc/mactab from /etc/mactable.conf
>        fi
>        if /etc/mactab exists
>                then call nameif to use it
>        else
>                use the current behaviour (Eg: 70-persistent-net.rules)
>        fi
>
> So, if the requirement is to assign mac addresses to specific devices on a single system edit /etc/mactab, or If the requirement is to assign differect mac addresses to specific devices on a failover systems edit /etc/mactable.conf.
>
> Does this sound to be a way forward?
>
> Regards - Steve.
>

OK, thanks everyone.

Taking on board everyone's comments to date, I'll combine my initial bug/feature requests into a new proposal.

As the absence of "70-persistent-net.rules" may not generate the NIC assignments in the same order (which I agree could be disastrous for a firewall) then I now think that the present behaviour of save-config including "70-persistent-net.rules" should be retained.

My test-environment on a usb-stick (used on differing hardware) is conceptually the same as Stefan's requirement to fail-over a saved config onto a cold standby box. While the impact on my usb test-build to correct persistent mac assignment is no real problem, if you are failing over a firewall you want a speedy swapover with as little messing as possible, assuming always that you have configured this upfront.

Just patching /etc/init.d/network to call /sbin/nameif to align interfaces and mac-addresses will not, on it's own, address this scenario.

What enabling a call to nameif and mactab does do is allow an administrator to take control of interface assignment, rather than having to work with whatever udev saves in 70-persistent-net.rules.

My colleague Roy (the "linux-nut" of previous posts) has a proof-of-concept bash-script that reads a separate new config file /etc/mactable.conf pre-populated with multiple interface/mac-address details from *both* the current-active and the cold-standby hardware, and greps to populate /etc/mactab with only the entries relating to addresses discovered by "ifconfig -a". This would need to be called earlier in the startup sequence than network startup, which would then find a valid /etc/mactab for the booting hardware.

Sequencing would need to be as follow (pseudo code):

        if /etc/mactable.conf exists
                then create or overwrite /etc/mactab from /etc/mactable.conf
        fi
        if /etc/mactab exists
                then call nameif to use it
        else
                use the current behaviour (Eg: 70-persistent-net.rules)
        fi

So, if the requirement is to assign mac addresses to specific devices on a single system edit /etc/mactab, or If the requirement is to assign differect mac addresses to specific devices on a failover systems edit /etc/mactable.conf.

Does this sound to be a way forward?

Regards - Steve.

Stephen H F Ralph
Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell
Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
Email: ste...@sa...

Quoting Stefan Engel <ma...@en...>:

> Hi,
>
> I wanted to start a new 1.4 build with the current CVS snapshot, but
> update_src failed due to missing source archives. Last commit comment of
> CHANGES and md5sum.lst was
>
> - updated bind to 9.7.0-P1
> - updated dhcp to 4.1.1
> - updated dhcpcd to 5.2.2
> - updated otpd to 3.2.5
>
> Old packages have been removed, but new ones are nowhere to be found so
> far. Could you please upload them? Thank you.

Oops! "Somebody" forgot to upload them....
Files are on the ftp server now, sorry for that.

> Btw. only one of the mirrors defined in update_src is currently working.
> Besides the main archive site ftp.devil-linux.org only
> http://mirrors.ircam.fr seems to be up to date. ftp.univ-lille1.fr
> contains stuff from 2009 (VERSION still named 1.3), ftp.tu-graz.ac.at
> and xenia.sote.hu do not seem to host devil-linux any more.

Ah crap...
I'll have to dig through my old emails and find the admins of those servers.
Thanks for the info.

-- 

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


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

Hi,

I wanted to start a new 1.4 build with the current CVS snapshot, but
update_src failed due to missing source archives. Last commit comment of
CHANGES and md5sum.lst was

- updated bind to 9.7.0-P1
- updated dhcp to 4.1.1
- updated dhcpcd to 5.2.2
- updated otpd to 3.2.5

Old packages have been removed, but new ones are nowhere to be found so
far. Could you please upload them? Thank you.

Btw. only one of the mirrors defined in update_src is currently working.
Besides the main archive site ftp.devil-linux.org only
http://mirrors.ircam.fr seems to be up to date. ftp.univ-lille1.fr
contains stuff from 2009 (VERSION still named 1.3), ftp.tu-graz.ac.at
and xenia.sote.hu do not seem to host devil-linux any more.

Regards,
Stefan

Bruce,

>>>One solution would be to automatically detect a major hardware change and prompt the user for what to do.

Given we are specifically talking about interface names and MAC
addresses here, how about:

myHWChecksum=`ifconfig | grep HWaddr | md5sum`

eg;

root@gannet:~ # ifconfig | grep HWaddr
eth0      Link encap:Ethernet  HWaddr 00:40:F4:B8:DB:2F
eth1      Link encap:Ethernet  HWaddr 00:40:F4:B8:DB:2E
eth1:0    Link encap:Ethernet  HWaddr 00:40:F4:B8:DB:2E
eth2      Link encap:Ethernet  HWaddr 00:40:F4:B8:DB:2D
eth2:0    Link encap:Ethernet  HWaddr 00:40:F4:B8:DB:2D

root@gannet:~ # ifconfig | grep HWaddr | md5sum
e3f0bea9d48f267949cb060e553caa81  -

root@gannet:~ # ifconfig eth2:0 down

root@gannet:~ # ifconfig | grep HWaddr | md5sum
be7038a7bc2f03025e28e1395ab9785e  -

This would detect different mac addresses, and changed association
between interface name and mac address.

Not sure what we'd do with it though...

Regards - Steve

"Stephen H F Ralph" <shf...@gm...>

>
> Message: 1
> Date: Tue, 20 Apr 2010 12:53:52 -0400
> From: Bruce Smith <bw...@re...>
> Subject: Re: [Devil-linux-develop] Potential bug - save-config
>        includes        "/etc/udev/rules.d/70-persistent-net.rules"
> To: dev...@li...
> Message-ID:
>        <r2j...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> One solution would be to automatically detect a major hardware change
> and prompt the user for what to do.  Kinda like what happens with a
> new version of DL.  Although I'm not sure exactly how to detect a
> major hardware change, and what constitutes "major".
>
>  - BS
>

I need my firewall box to always assign the nics in the same order I
once configured them, regardless of whether I add new hardware, change
the card's pci slots, add a new kernel, etc. SuSe was once known to mess
up nic order when updating to a new kernel. AFAIK that was the time
before we had udev, but who knows what happens nowadays if you just
remove/do not save 70-persistent-net.rules and change anything on your
firewall machine. I do not want to dig around changing nic-names in
config files (dhcp, firewall scripts, ...), only because my former
interal eth1 is now reported as external eth0 and tries to serve the
internet via dhcp.

So not saving 70-persistent-net.rules or not having any other method to
always ensure that the nics come up in the right order is a no-go for me.

On the other hand, I have a replacement firewall on cold-standby, it's
the same machine, except for the mac-addresses of the nics. If I need
to, I just plug the usb stick with the firewall config into the
standby-box and start it. But ... now I have to be aware of the
persistent mac assignment. So a feature to have multiple sets of machine
specific nic-setups would really be nice. Identifier could be the mac
adresses. If mac address A is found, just use 70-persistent-net.rules
containing mac address A. Or something similar.

Regards,
Stefan

Dominic Raferd wrote:
> If you want to change NIC[s] or run the same DL configuration on 
> different hardware, temporarily remove 70-persistent-net.rules before 
> saving the configuration e.g.
> 
> mv /etc/udev/rules.d/70-persistent-net.rules /var/tmp/ && save-config -q 
> && mv /var/tmp/70-persistent-net.rules /etc/udev/rules.d/
> 
> It is automatically recreated at reboot.
> 
> Dominic
> 
> On 20/04/2010 18:01, Steve Ralph wrote:
>> If we leave save-config exactly as it is, but enable "/sbin/nameif" from init.d/network, do we get the best of both worlds?
>>
>> Steve.
>>
>> -----Original Message-----
>> From: Bruce Smith [mailto:bw...@re...]
>> Sent: 20 April 2010 17:54
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>>
>> One solution would be to automatically detect a major hardware change
>> and prompt the user for what to do.  Kinda like what happens with a
>> new version of DL.  Although I'm not sure exactly how to detect a
>> major hardware change, and what constitutes "major".
>>
>>   - BS
>>
>>
>> On Tue, Apr 20, 2010 at 12:50, Steve Ralph<Ste...@sa...>  wrote:
>>    
>>> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>>      
>>>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
>>>>>>            
>>> This would be a concern. I'd assumed the assignment would be consistent across boots.
>>>
>>> Is a valid distinction to say that "/etc/mactab" is for user-control while "<span class="inlinecode">" is under kernel control?
>>>
>>> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>>>
>>> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>>>
>>> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>>>
>>> Regards - Steve.
>>> Email: ste...@sa...
>>>
>>>
>>> -----Original Message-----
>>> From: Bruce Smith [mailto:bw...@re...]
>>> Sent: 20 April 2010 16:47
>>> To: dev...@li...
>>> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>>>
>>> My concern is if the computer has multiple NIC's of the same
>>> make/model and the interface numbers are dynamically assigned every
>>> time the computer is booted, it may not assign the same NIC to the
>>> same interface every time.
>>>
>>> It would probably assign them the same as long as nothing changes.
>>> But what if someone adds another piece of unrelated hardware that
>>> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
>>> patches or new versions of other network software?  I see a real
>>> possibility of the NIC/interface assignment changing upon boot.  And
>>> now your firewall has reversed NIC's, potentially allowing the
>>> Internet full access to your private network.
>>>
>>>   - BS
>>>
>>> and :
>>>
>>> Are you saying that /etc/mactab does the same thing as /etc/udev/rules.d/70-persistent-net.rules ?
>>>
>>> If so, should we do the same thing two different ways?
>>>
>>>   - BS
>>>
>>>
>>> On Tue, Apr 20, 2010 at 11:00, Steve Ralph<Ste...@sa...>  wrote:
>>>      
>>>> Hi there,
>>>>
>>>> I have been working to port some internal configuration scripts to
>>>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>>>> multiple different machines and continue work where I left off.
>>>>
>>>> When I boot from the original install and list the network interfaces
>>>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>>>> then boot from different hardware, I have an issue around the assignment of
>>>> the interface names.
>>>>
>>>> After some investigation, this seems to be because the file
>>>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>>>> created by save-config.  This file links the mac-address to the device name
>>>> (eg, 00:08:02:01:02:03 is named eth0).
>>>>
>>>> When this file already exists (eg, after save-config has been run), and the
>>>> usb-key boots on different hardware, udev says eth0 is already assigned
>>>> because the mac address of the previous machine is linked to eth0 in
>>>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>>>> seen on this hardware), and assigns the new mac-address to the next
>>>> available device, eg, eth1.
>>>>
>>>> If I save-config again the problem is exacerbated! On the second and
>>>> subsequent hardware, interfaces are assigned after the devices allocated in
>>>> 70-persistent-net.rules, but any statically configured addresses are
>>>> assigned to the original network devices.
>>>>
>>>> EG:
>>>>          1st machine
>>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>>>
>>>>          2nd machine
>>>>                  IF=eth0 MAC=00:08:02:01:02:06
>>>>                  IF=eth1 MAC=00:08:02:01:02:07
>>>>                  IF=eth2 MAC=00:08:02:01:02:08
>>>>
>>>>          When using the saved-config from the first machine on the second
>>>> machine
>>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>>>> Not available as MAC address not found!
>>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>>>> Not available as MAC address not found!
>>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>>>> Not available as MAC address not found!
>>>>                  IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>>>> available as MAC address found but NO IP Address assigned
>>>>                  IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>>>> available as MAC address found but NO IP Address assigned
>>>>                  IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>>>> available as MAC address found but NO IP Address assigned
>>>>
>>>> This issue could also occur if a pre-saved config file was installed on new
>>>> kit as part of a hardware only upgrade.
>>>>
>>>> I suggest a fix would be to exclude the file
>>>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>>>> save-config allowing this file to be dynamically created at boot up like on
>>>> the initial boot.
>>>>
>>>> Before I log a call on mantis I would appreciate a sanity check first, to
>>>> confirm that I haven't missed anything obvious.
>>>>
>>>> Additionally, although I have had no issues with the CD assignment, should
>>>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>>>> save-config?
>>>>
>>>> Regards - Steve.
>>>>        
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Devil-linux-develop mailing list
>> Dev...@li...
>> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>>
>>    
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
> 
> 

If you want to change NIC[s] or run the same DL configuration on 
different hardware, temporarily remove 70-persistent-net.rules before 
saving the configuration e.g.

mv /etc/udev/rules.d/70-persistent-net.rules /var/tmp/ && save-config -q 
&& mv /var/tmp/70-persistent-net.rules /etc/udev/rules.d/

It is automatically recreated at reboot.

Dominic

On 20/04/2010 18:01, Steve Ralph wrote:
> If we leave save-config exactly as it is, but enable "/sbin/nameif" from init.d/network, do we get the best of both worlds?
>
> Steve.
>
> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: 20 April 2010 17:54
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>
> One solution would be to automatically detect a major hardware change
> and prompt the user for what to do.  Kinda like what happens with a
> new version of DL.  Although I'm not sure exactly how to detect a
> major hardware change, and what constitutes "major".
>
>   - BS
>
>
> On Tue, Apr 20, 2010 at 12:50, Steve Ralph<Ste...@sa...>  wrote:
>    
>> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>      
>>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
>>>>>            
>> This would be a concern. I'd assumed the assignment would be consistent across boots.
>>
>> Is a valid distinction to say that "/etc/mactab" is for user-control while "<span class="inlinecode">" is under kernel control?
>>
>> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>>
>> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>>
>> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>>
>> Regards - Steve.
>> Email: ste...@sa...
>>
>>
>> -----Original Message-----
>> From: Bruce Smith [mailto:bw...@re...]
>> Sent: 20 April 2010 16:47
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>>
>> My concern is if the computer has multiple NIC's of the same
>> make/model and the interface numbers are dynamically assigned every
>> time the computer is booted, it may not assign the same NIC to the
>> same interface every time.
>>
>> It would probably assign them the same as long as nothing changes.
>> But what if someone adds another piece of unrelated hardware that
>> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
>> patches or new versions of other network software?  I see a real
>> possibility of the NIC/interface assignment changing upon boot.  And
>> now your firewall has reversed NIC's, potentially allowing the
>> Internet full access to your private network.
>>
>>   - BS
>>
>> and :
>>
>> Are you saying that /etc/mactab does the same thing as /etc/udev/rules.d/70-persistent-net.rules ?
>>
>> If so, should we do the same thing two different ways?
>>
>>   - BS
>>
>>
>> On Tue, Apr 20, 2010 at 11:00, Steve Ralph<Ste...@sa...>  wrote:
>>      
>>> Hi there,
>>>
>>> I have been working to port some internal configuration scripts to
>>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>>> multiple different machines and continue work where I left off.
>>>
>>> When I boot from the original install and list the network interfaces
>>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>>> then boot from different hardware, I have an issue around the assignment of
>>> the interface names.
>>>
>>> After some investigation, this seems to be because the file
>>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>>> created by save-config.  This file links the mac-address to the device name
>>> (eg, 00:08:02:01:02:03 is named eth0).
>>>
>>> When this file already exists (eg, after save-config has been run), and the
>>> usb-key boots on different hardware, udev says eth0 is already assigned
>>> because the mac address of the previous machine is linked to eth0 in
>>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>>> seen on this hardware), and assigns the new mac-address to the next
>>> available device, eg, eth1.
>>>
>>> If I save-config again the problem is exacerbated! On the second and
>>> subsequent hardware, interfaces are assigned after the devices allocated in
>>> 70-persistent-net.rules, but any statically configured addresses are
>>> assigned to the original network devices.
>>>
>>> EG:
>>>          1st machine
>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>>
>>>          2nd machine
>>>                  IF=eth0 MAC=00:08:02:01:02:06
>>>                  IF=eth1 MAC=00:08:02:01:02:07
>>>                  IF=eth2 MAC=00:08:02:01:02:08
>>>
>>>          When using the saved-config from the first machine on the second
>>> machine
>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>                  IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>                  IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>
>>> This issue could also occur if a pre-saved config file was installed on new
>>> kit as part of a hardware only upgrade.
>>>
>>> I suggest a fix would be to exclude the file
>>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>>> save-config allowing this file to be dynamically created at boot up like on
>>> the initial boot.
>>>
>>> Before I log a call on mantis I would appreciate a sanity check first, to
>>> confirm that I haven't missed anything obvious.
>>>
>>> Additionally, although I have had no issues with the CD assignment, should
>>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>>> save-config?
>>>
>>> Regards - Steve.
>>>        
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
>    

If you want to change NIC[s] or run the same DL configuration on 
different hardware, temporarily remove 70-persistent-net.rules before 
saving the configuration e.g.

mv /etc/udev/rules.d/70-persistent-net.rules /var/tmp/ && save-config -q 
&& mv /var/tmp/70-persistent-net.rules /etc/udev/rules.d/

It is automatically recreated at reboot.

Dominic

On 20/04/2010 18:01, Steve Ralph wrote:
> If we leave save-config exactly as it is, but enable "/sbin/nameif" from init.d/network, do we get the best of both worlds?
>
> Steve.
>
> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: 20 April 2010 17:54
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>
> One solution would be to automatically detect a major hardware change
> and prompt the user for what to do.  Kinda like what happens with a
> new version of DL.  Although I'm not sure exactly how to detect a
> major hardware change, and what constitutes "major".
>
>   - BS
>
>
> On Tue, Apr 20, 2010 at 12:50, Steve Ralph<Ste...@sa...>  wrote:
>    
>> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>      
>>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
>>>>>            
>> This would be a concern. I'd assumed the assignment would be consistent across boots.
>>
>> Is a valid distinction to say that "/etc/mactab" is for user-control while "<span class="inlinecode">" is under kernel control?
>>
>> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>>
>> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>>
>> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>>
>> Regards - Steve.
>> Email: ste...@sa...
>>
>>
>> -----Original Message-----
>> From: Bruce Smith [mailto:bw...@re...]
>> Sent: 20 April 2010 16:47
>> To: dev...@li...
>> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>>
>> My concern is if the computer has multiple NIC's of the same
>> make/model and the interface numbers are dynamically assigned every
>> time the computer is booted, it may not assign the same NIC to the
>> same interface every time.
>>
>> It would probably assign them the same as long as nothing changes.
>> But what if someone adds another piece of unrelated hardware that
>> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
>> patches or new versions of other network software?  I see a real
>> possibility of the NIC/interface assignment changing upon boot.  And
>> now your firewall has reversed NIC's, potentially allowing the
>> Internet full access to your private network.
>>
>>   - BS
>>
>> and :
>>
>> Are you saying that /etc/mactab does the same thing as /etc/udev/rules.d/70-persistent-net.rules ?
>>
>> If so, should we do the same thing two different ways?
>>
>>   - BS
>>
>>
>> On Tue, Apr 20, 2010 at 11:00, Steve Ralph<Ste...@sa...>  wrote:
>>      
>>> Hi there,
>>>
>>> I have been working to port some internal configuration scripts to
>>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>>> multiple different machines and continue work where I left off.
>>>
>>> When I boot from the original install and list the network interfaces
>>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>>> then boot from different hardware, I have an issue around the assignment of
>>> the interface names.
>>>
>>> After some investigation, this seems to be because the file
>>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>>> created by save-config.  This file links the mac-address to the device name
>>> (eg, 00:08:02:01:02:03 is named eth0).
>>>
>>> When this file already exists (eg, after save-config has been run), and the
>>> usb-key boots on different hardware, udev says eth0 is already assigned
>>> because the mac address of the previous machine is linked to eth0 in
>>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>>> seen on this hardware), and assigns the new mac-address to the next
>>> available device, eg, eth1.
>>>
>>> If I save-config again the problem is exacerbated! On the second and
>>> subsequent hardware, interfaces are assigned after the devices allocated in
>>> 70-persistent-net.rules, but any statically configured addresses are
>>> assigned to the original network devices.
>>>
>>> EG:
>>>          1st machine
>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>>
>>>          2nd machine
>>>                  IF=eth0 MAC=00:08:02:01:02:06
>>>                  IF=eth1 MAC=00:08:02:01:02:07
>>>                  IF=eth2 MAC=00:08:02:01:02:08
>>>
>>>          When using the saved-config from the first machine on the second
>>> machine
>>>                  IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>>> Not available as MAC address not found!
>>>                  IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>                  IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>                  IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>>> available as MAC address found but NO IP Address assigned
>>>
>>> This issue could also occur if a pre-saved config file was installed on new
>>> kit as part of a hardware only upgrade.
>>>
>>> I suggest a fix would be to exclude the file
>>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>>> save-config allowing this file to be dynamically created at boot up like on
>>> the initial boot.
>>>
>>> Before I log a call on mantis I would appreciate a sanity check first, to
>>> confirm that I haven't missed anything obvious.
>>>
>>> Additionally, although I have had no issues with the CD assignment, should
>>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>>> save-config?
>>>
>>> Regards - Steve.
>>>        
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Devil-linux-develop mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-develop
>
>    

If we leave save-config exactly as it is, but enable "/sbin/nameif" from init.d/network, do we get the best of both worlds?

Steve.

-----Original Message-----
From: Bruce Smith [mailto:bw...@re...]
Sent: 20 April 2010 17:54
To: dev...@li...
Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

One solution would be to automatically detect a major hardware change
and prompt the user for what to do.  Kinda like what happens with a
new version of DL.  Although I'm not sure exactly how to detect a
major hardware change, and what constitutes "major".

 - BS


On Tue, Apr 20, 2010 at 12:50, Steve Ralph <Ste...@sa...> wrote:
> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
> This would be a concern. I'd assumed the assignment would be consistent across boots.
>
> Is a valid distinction to say that "/etc/mactab" is for user-control while "70-persistent-net.rules" is under kernel control?
>
> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>
> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>
> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>
> Regards - Steve.
> Email: ste...@sa...
>
>
> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: 20 April 2010 16:47
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>
> My concern is if the computer has multiple NIC's of the same
> make/model and the interface numbers are dynamically assigned every
> time the computer is booted, it may not assign the same NIC to the
> same interface every time.
>
> It would probably assign them the same as long as nothing changes.
> But what if someone adds another piece of unrelated hardware that
> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
> patches or new versions of other network software?  I see a real
> possibility of the NIC/interface assignment changing upon boot.  And
> now your firewall has reversed NIC's, potentially allowing the
> Internet full access to your private network.
>
>  - BS
>
> and :
>
> Are you saying that /etc/mactab does the same thing as /etc/udev/rules.d/70-persistent-net.rules ?
>
> If so, should we do the same thing two different ways?
>
>  - BS
>
>
> On Tue, Apr 20, 2010 at 11:00, Steve Ralph <Ste...@sa...> wrote:
>> Hi there,
>>
>> I have been working to port some internal configuration scripts to
>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>> multiple different machines and continue work where I left off.
>>
>> When I boot from the original install and list the network interfaces
>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>> then boot from different hardware, I have an issue around the assignment of
>> the interface names.
>>
>> After some investigation, this seems to be because the file
>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>> created by save-config.  This file links the mac-address to the device name
>> (eg, 00:08:02:01:02:03 is named eth0).
>>
>> When this file already exists (eg, after save-config has been run), and the
>> usb-key boots on different hardware, udev says eth0 is already assigned
>> because the mac address of the previous machine is linked to eth0 in
>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>> seen on this hardware), and assigns the new mac-address to the next
>> available device, eg, eth1.
>>
>> If I save-config again the problem is exacerbated! On the second and
>> subsequent hardware, interfaces are assigned after the devices allocated in
>> 70-persistent-net.rules, but any statically configured addresses are
>> assigned to the original network devices.
>>
>> EG:
>>         1st machine
>>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>
>>         2nd machine
>>                 IF=eth0 MAC=00:08:02:01:02:06
>>                 IF=eth1 MAC=00:08:02:01:02:07
>>                 IF=eth2 MAC=00:08:02:01:02:08
>>
>>         When using the saved-config from the first machine on the second
>> machine
>>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>
>> This issue could also occur if a pre-saved config file was installed on new
>> kit as part of a hardware only upgrade.
>>
>> I suggest a fix would be to exclude the file
>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>> save-config allowing this file to be dynamically created at boot up like on
>> the initial boot.
>>
>> Before I log a call on mantis I would appreciate a sanity check first, to
>> confirm that I haven't missed anything obvious.
>>
>> Additionally, although I have had no issues with the CD assignment, should
>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>> save-config?
>>
>> Regards - Steve.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

One solution would be to automatically detect a major hardware change
and prompt the user for what to do.  Kinda like what happens with a
new version of DL.  Although I'm not sure exactly how to detect a
major hardware change, and what constitutes "major".

 - BS


On Tue, Apr 20, 2010 at 12:50, Steve Ralph <Ste...@sa...> wrote:
> During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
> This would be a concern. I'd assumed the assignment would be consistent across boots.
>
> Is a valid distinction to say that "/etc/mactab" is for user-control while "70-persistent-net.rules" is under kernel control?
>
> Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.
>
> Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.
>
> A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".
>
> Regards - Steve.
> Email: ste...@sa...
>
>
> -----Original Message-----
> From: Bruce Smith [mailto:bw...@re...]
> Sent: 20 April 2010 16:47
> To: dev...@li...
> Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"
>
> My concern is if the computer has multiple NIC's of the same
> make/model and the interface numbers are dynamically assigned every
> time the computer is booted, it may not assign the same NIC to the
> same interface every time.
>
> It would probably assign them the same as long as nothing changes.
> But what if someone adds another piece of unrelated hardware that
> causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
> patches or new versions of other network software?  I see a real
> possibility of the NIC/interface assignment changing upon boot.  And
> now your firewall has reversed NIC's, potentially allowing the
> Internet full access to your private network.
>
>  - BS
>
> and :
>
> Are you saying that /etc/mactab does the same thing as /etc/udev/rules.d/70-persistent-net.rules ?
>
> If so, should we do the same thing two different ways?
>
>  - BS
>
>
> On Tue, Apr 20, 2010 at 11:00, Steve Ralph <Ste...@sa...> wrote:
>> Hi there,
>>
>> I have been working to port some internal configuration scripts to
>> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
>> multiple different machines and continue work where I left off.
>>
>> When I boot from the original install and list the network interfaces
>> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
>> then boot from different hardware, I have an issue around the assignment of
>> the interface names.
>>
>> After some investigation, this seems to be because the file
>> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
>> created by save-config.  This file links the mac-address to the device name
>> (eg, 00:08:02:01:02:03 is named eth0).
>>
>> When this file already exists (eg, after save-config has been run), and the
>> usb-key boots on different hardware, udev says eth0 is already assigned
>> because the mac address of the previous machine is linked to eth0 in
>> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
>> seen on this hardware), and assigns the new mac-address to the next
>> available device, eg, eth1.
>>
>> If I save-config again the problem is exacerbated! On the second and
>> subsequent hardware, interfaces are assigned after the devices allocated in
>> 70-persistent-net.rules, but any statically configured addresses are
>> assigned to the original network devices.
>>
>> EG:
>>         1st machine
>>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>>
>>         2nd machine
>>                 IF=eth0 MAC=00:08:02:01:02:06
>>                 IF=eth1 MAC=00:08:02:01:02:07
>>                 IF=eth2 MAC=00:08:02:01:02:08
>>
>>         When using the saved-config from the first machine on the second
>> machine
>>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
>> Not available as MAC address not found!
>>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
>> available as MAC address found but NO IP Address assigned
>>
>> This issue could also occur if a pre-saved config file was installed on new
>> kit as part of a hardware only upgrade.
>>
>> I suggest a fix would be to exclude the file
>> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
>> save-config allowing this file to be dynamically created at boot up like on
>> the initial boot.
>>
>> Before I log a call on mantis I would appreciate a sanity check first, to
>> confirm that I haven't missed anything obvious.
>>
>> Additionally, although I have had no issues with the CD assignment, should
>> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
>> save-config?
>>
>> Regards - Steve.

During my investigations I thought this was all part of the same issue, and that /etc/mactab was the correct solution. After a debate with another linux nut at work, it seemed to be two different but related issues.
>>> ... are dynamically assigned every time the computer is booted, it may not assign the same NIC to the same interface every time.
This would be a concern. I'd assumed the assignment would be consistent across boots.

Is a valid distinction to say that "/etc/mactab" is for user-control while "70-persistent-net.rules" is under kernel control?

Certainly during my investigations, it seemed that /etc/mactab took precidence over "70-persistent-net.rules". I stopped the network, populated /etc/mactab, ran nameif, and restarted /etc/init.d/network to correct the issue on my test rig. Never thought to look if nameif updates 70-persistent-net.rules.

Around we go again as the config file would contain "/etc/mactab" and when used on new hardware would create the same issues I see with "70-persistent-net.rules " being saved.

A suggestion from the  "other linux nut at work" (his description not mine) was to have a separate file created by save-config which held machine specific hardware info like "/etc/mactab" and/or "70-persistent-net.rules".

Regards - Steve.
Email: ste...@sa...


-----Original Message-----
From: Bruce Smith [mailto:bw...@re...]
Sent: 20 April 2010 16:47
To: dev...@li...
Subject: Re: [Devil-linux-develop] Potential bug - save-config includes "/etc/udev/rules.d/70-persistent-net.rules"

My concern is if the computer has multiple NIC's of the same
make/model and the interface numbers are dynamically assigned every
time the computer is booted, it may not assign the same NIC to the
same interface every time.

It would probably assign them the same as long as nothing changes.
But what if someone adds another piece of unrelated hardware that
causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
patches or new versions of other network software?  I see a real
possibility of the NIC/interface assignment changing upon boot.  And
now your firewall has reversed NIC's, potentially allowing the
Internet full access to your private network.

 - BS

and :

Are you saying that /etc/mactab does the same thing as /etc/udev/rules.d/70-persistent-net.rules ?

If so, should we do the same thing two different ways?

 - BS


On Tue, Apr 20, 2010 at 11:00, Steve Ralph <Ste...@sa...> wrote:
> Hi there,
>
> I have been working to port some internal configuration scripts to
> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
> multiple different machines and continue work where I left off.
>
> When I boot from the original install and list the network interfaces
> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
> then boot from different hardware, I have an issue around the assignment of
> the interface names.
>
> After some investigation, this seems to be because the file
> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
> created by save-config.  This file links the mac-address to the device name
> (eg, 00:08:02:01:02:03 is named eth0).
>
> When this file already exists (eg, after save-config has been run), and the
> usb-key boots on different hardware, udev says eth0 is already assigned
> because the mac address of the previous machine is linked to eth0 in
> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
> seen on this hardware), and assigns the new mac-address to the next
> available device, eg, eth1.
>
> If I save-config again the problem is exacerbated! On the second and
> subsequent hardware, interfaces are assigned after the devices allocated in
> 70-persistent-net.rules, but any statically configured addresses are
> assigned to the original network devices.
>
> EG:
>         1st machine
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>
>         2nd machine
>                 IF=eth0 MAC=00:08:02:01:02:06
>                 IF=eth1 MAC=00:08:02:01:02:07
>                 IF=eth2 MAC=00:08:02:01:02:08
>
>         When using the saved-config from the first machine on the second
> machine
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>
> This issue could also occur if a pre-saved config file was installed on new
> kit as part of a hardware only upgrade.
>
> I suggest a fix would be to exclude the file
> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
> save-config allowing this file to be dynamically created at boot up like on
> the initial boot.
>
> Before I log a call on mantis I would appreciate a sanity check first, to
> confirm that I haven't missed anything obvious.
>
> Additionally, although I have had no issues with the CD assignment, should
> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
> save-config?
>
> Regards - Steve.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Devil-linux-develop mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/devil-linux-develop

Are you saying that /etc/mactab does the same thing as
/etc/udev/rules.d/70-persistent-net.rules ?

If so, should we do the same thing two different ways?

 - BS


On Tue, Apr 20, 2010 at 11:30, Steve Ralph <Ste...@sa...> wrote:
> Hi,
>
> As part of my investigations to the
> "/etc/udev/rules.d/70-persistent-net.rules" issue reported just now, I
> discovered the "/sbin/nameif" program, which reads the file "/etc/mactab" if
> it exists, and associates interface names with mac-address.
>
> It has to be run prior to the interface(s) starting, so I envisage it hooked
> into "/etc/init.d/network" to be called only if the file "/etc/mactab"
> exists. "jiim-barber" on one of the debian lists offers "[ -x /sbin/nameif ]
> && [ -r /etc/mactab ] && /sbin/nameif " as a code-frag that could be
> included in "/etc/init.d/network".
>
> The format of "/etc/mactab" is:
>
>         #--- /etc/mactab : associate network interfaces with MAC address
>         #
>         eth0    00:08:02:01:02:03
>         eth1    00:08:02:01:02:04
>         eth2    00:08:02:01:02:05
>         #
>         #--- End
>
> I'd assume that the default config would *not* include "/etc/mactab" which
> would only be created if the default udev-assignment needed to be modified.
>
> If this feature doesn't make it into release 1.4 I'll not be upset.
>
> Regards - Steve.

My concern is if the computer has multiple NIC's of the same
make/model and the interface numbers are dynamically assigned every
time the computer is booted, it may not assign the same NIC to the
same interface every time.

It would probably assign them the same as long as nothing changes.
But what if someone adds another piece of unrelated hardware that
causes IRQ's to be reassigned?  Or what if we upgrade DL to new kernel
patches or new versions of other network software?  I see a real
possibility of the NIC/interface assignment changing upon boot.  And
now your firewall has reversed NIC's, potentially allowing the
Internet full access to your private network.

 - BS


On Tue, Apr 20, 2010 at 11:00, Steve Ralph <Ste...@sa...> wrote:
> Hi there,
>
> I have been working to port some internal configuration scripts to
> DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from
> multiple different machines and continue work where I left off.
>
> When I boot from the original install and list the network interfaces
> (either ifconfig or ip addr show), all seems OK. Once I run save-config, and
> then boot from different hardware, I have an issue around the assignment of
> the interface names.
>
> After some investigation, this seems to be because the file
> "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball
> created by save-config.  This file links the mac-address to the device name
> (eg, 00:08:02:01:02:03 is named eth0).
>
> When this file already exists (eg, after save-config has been run), and the
> usb-key boots on different hardware, udev says eth0 is already assigned
> because the mac address of the previous machine is linked to eth0 in
> 70-persistent-net.rules (even if the listed mac-address is nowhere to be
> seen on this hardware), and assigns the new mac-address to the next
> available device, eg, eth1.
>
> If I save-config again the problem is exacerbated! On the second and
> subsequent hardware, interfaces are assigned after the devices allocated in
> 70-persistent-net.rules, but any statically configured addresses are
> assigned to the original network devices.
>
> EG:
>         1st machine
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24
>
>         2nd machine
>                 IF=eth0 MAC=00:08:02:01:02:06
>                 IF=eth1 MAC=00:08:02:01:02:07
>                 IF=eth2 MAC=00:08:02:01:02:08
>
>         When using the saved-config from the first machine on the second
> machine
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface
> Not available as MAC address not found!
>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface
> available as MAC address found but NO IP Address assigned
>
> This issue could also occur if a pre-saved config file was installed on new
> kit as part of a hardware only upgrade.
>
> I suggest a fix would be to exclude the file
> "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with
> save-config allowing this file to be dynamically created at boot up like on
> the initial boot.
>
> Before I log a call on mantis I would appreciate a sanity check first, to
> confirm that I haven't missed anything obvious.
>
> Additionally, although I have had no issues with the CD assignment, should
> "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the
> save-config?
>
> Regards - Steve.

Quoting Steve Ralph <Ste...@sa...>: 

> Hi there, 
>
> I have been working to port some internal configuration scripts to DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from multiple different machines and continue work where I left off. 
>
> When I boot from the original install and list the network interfaces (either ifconfig or ip addr show), all seems OK. Once I run save-config, and then boot from different hardware, I have an issue around the assignment of the interface names. 
>
> After some investigation, this seems to be because the file "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball created by save-config. This file links the mac-address to the device name (eg, 00:08:02:01:02:03 is named eth0). 
>
> When this file already exists (eg, after save-config has been run), and the usb-key boots on different hardware, udev says eth0 is already assigned 
> because the mac address of the previous machine is linked to eth0 in 70-persistent-net.rules (even if the listed mac-address is nowhere to be seen on this hardware), and assigns the new mac-address to the next available device, eg, eth1.  
>
> If I save-config again the problem is exacerbated! On the second and subsequent hardware, interfaces are assigned after the devices allocated in 70-persistent-net.rules, but any statically configured addresses are assigned to the original network devices. 
>
> EG: 
>         1st machine 
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24 
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24 
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24 
>
>         2nd machine 
>                 IF=eth0 MAC=00:08:02:01:02:06  
>                 IF=eth1 MAC=00:08:02:01:02:07  
>                 IF=eth2 MAC=00:08:02:01:02:08  
>
>         When using the saved-config from the first machine on the second machine 
>                 IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24     Interface Not available as MAC address not found! 
>                 IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24     Interface Not available as MAC address not found! 
>                 IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24     Interface Not available as MAC address not found! 
>                 IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned 
>                 IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned 
>                 IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned 
>
> This issue could also occur if a pre-saved config file was installed on new kit as part of a hardware only upgrade. 
>
> I suggest a fix would be to exclude the file "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with save-config allowing this file to be dynamically created at boot up like on the initial boot. 
>
> Before I log a call on mantis I would appreciate a sanity check first, to confirm that I haven't missed anything obvious. 
>
> Additionally, although I have had no issues with the CD assignment, should "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the save-config?

 During an upgrade to a newer DL version we automatically de-select those files. 

On one hand I'm a bit reluctant to remove them in save-config, but then on the other hand I never "upgrade" them either. 

Is anybody actually relying on these files?

-- 

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

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

Hi,

As part of my investigations to the "/etc/udev/rules.d/70-persistent-net.rules" issue reported just now, I discovered the "/sbin/nameif" program, which reads the file "/etc/mactab" if it exists, and associates interface names with mac-address.

It has to be run prior to the interface(s) starting, so I envisage it hooked into "/etc/init.d/network" to be called only if the file "/etc/mactab" exists. "jiim-barber"  on one of the debian lists offers "[ -x /sbin/nameif ] && [ -r /etc/mactab ] && /sbin/nameif " as a code-frag that could be included in "/etc/init.d/network".

The format of "/etc/mactab" is:

        #--- /etc/mactab : associate network interfaces with MAC address
        #
        eth0    00:08:02:01:02:03
        eth1    00:08:02:01:02:04
        eth2    00:08:02:01:02:05
        #
        #--- End

I'd assume that the default config would *not* include "/etc/mactab" which would only be created if the default udev-assignment needed to be modified.

If this feature doesn't make it into release 1.4 I'll not be upset.

Regards - Steve.

Stephen H F Ralph
Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell
Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
Email: ste...@sa...<mailto:ste...@sa...>

Hi there,

I have been working to port some internal configuration scripts to DL-1.4-RC3/486 and have installed to a USB key. This allows me to boot from multiple different machines and continue work where I left off.

When I boot from the original install and list the network interfaces (either ifconfig or ip addr show), all seems OK. Once I run save-config, and then boot from different hardware, I have an issue around the assignment of the interface names.

After some investigation, this seems to be because the file "/etc/udev/rules.d/70-persistent-net.rules " is included in the tarball created by save-config.  This file links the mac-address to the device name (eg, 00:08:02:01:02:03 is named eth0).

When this file already exists (eg, after save-config has been run), and the usb-key boots on different hardware, udev says eth0 is already assigned
because the mac address of the previous machine is linked to eth0 in 70-persistent-net.rules (even if the listed mac-address is nowhere to be seen on this hardware), and assigns the new mac-address to the next available device, eg, eth1.

If I save-config again the problem is exacerbated! On the second and subsequent hardware, interfaces are assigned after the devices allocated in 70-persistent-net.rules, but any statically configured addresses are assigned to the original network devices.

EG:
        1st machine
                IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24
                IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24
                IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24

        2nd machine
                IF=eth0 MAC=00:08:02:01:02:06
                IF=eth1 MAC=00:08:02:01:02:07
                IF=eth2 MAC=00:08:02:01:02:08

        When using the saved-config from the first machine on the second machine
                IF=eth0 MAC=00:08:02:01:02:03 IP=10.1.1.1/24    Interface Not available as MAC address not found!
                IF=eth1 MAC=00:08:02:01:02:04 IP=10.1.2.1/24    Interface Not available as MAC address not found!
                IF=eth2 MAC=00:08:02:01:02:05 IP=10.1.3.1/24    Interface Not available as MAC address not found!
                IF=eth3 MAC=00:08:02:01:02:06 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned
                IF=eth4 MAC=00:08:02:01:02:07 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned
                IF=eth5 MAC=00:08:02:01:02:08 IP=Unassigned     Interface available as MAC address found but NO IP Address assigned

This issue could also occur if a pre-saved config file was installed on new kit as part of a hardware only upgrade.

I suggest a fix would be to exclude the file "/etc/udev/rules.d/70-persistent-net.rules" from the tar created with save-config allowing this file to be dynamically created at boot up like on the initial boot.

Before I log a call on mantis I would appreciate a sanity check first, to confirm that I haven't missed anything obvious.

Additionally, although I have had no issues with the CD assignment, should "/etc/udev/rules.d/70-persistent-cd.rules" file also be excluded from the save-config?

Regards - Steve.

Stephen H F Ralph
Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell
Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
Email: ste...@sa...<mailto:ste...@sa...>

Hey,

does anybody see a reason not to release the official 1.4 ?
There are a few suggestions still in Mantis, but I have no time to  
work on them. Nothing in there I see as critical with the exception of  
#68.

-- 

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


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

Jan,

Quoting Jan Hugo Prins <jh...@jh...>:

> Hello,
>
> This week I have been rather busy trying to get a DL system up with the
> latest 1.4.0-rc3. Because this setup is going to be for a router that
> hardly needs anything more then just the firewall stuff and routing
> stuff I disabled almost everything in my config, but this resulted in a
> few little problems that were not properly fixed in the dependency tree
> (I think).

I have no doubt that you're right. ;-)

> 1. One of the scripts uses rsync to put some config in place, but if
> rsync is not available this fails. Have changed the script so it uses
> tar instead to copy the whole set of files that is needed.

Could you send in a patch for this, so we can fix it?

> 2. While parted is not needed in my setup as far as I know it was
> compiled anyway, but this failed because device-mapper support was not
> available. I change the --enable-device-mapper into
> --disable-device-mapper and that fixed the build of this package. Don't
> know the impact though, but I suspect none because I have not included
> parted in my system as far as I know.

We'll need to just add the 'menuconfig' stuff for it, anybody have a  
patch already?

> 3. I need wide-dhcpv6 to pickup a prefix delegation for my network from
> my ADSL profider. This was not available so I hacked it in myself. Is
> their any interest to put this package in the main tree?


-- 

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


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

Hello,

This week I have been rather busy trying to get a DL system up with the
latest 1.4.0-rc3. Because this setup is going to be for a router that
hardly needs anything more then just the firewall stuff and routing
stuff I disabled almost everything in my config, but this resulted in a
few little problems that were not properly fixed in the dependency tree
(I think).

1. One of the scripts uses rsync to put some config in place, but if
rsync is not available this fails. Have changed the script so it uses
tar instead to copy the whole set of files that is needed.

2. While parted is not needed in my setup as far as I know it was
compiled anyway, but this failed because device-mapper support was not
available. I change the --enable-device-mapper into
--disable-device-mapper and that fixed the build of this package. Don't
know the impact though, but I suspect none because I have not included
parted in my system as far as I know.

3. I need wide-dhcpv6 to pickup a prefix delegation for my network from
my ADSL profider. This was not available so I hacked it in myself. Is
their any interest to put this package in the main tree?


Greetings,
Jan Hugo Prins

Andrzej,

I put it into glibc script because exactly glibc installation breaks the
timezone symlink :)

If I put it into .bash_profile the link will be created only during the
chrooting, but usually I use build system more than once, i.e. several dozens of
rebuilds without re-login ( build session lives in "screen")

Serge


On 03/30/2010 06:13 AM, Andrzej Odyniec wrote:
> Serge Leschinsky wrote:
>> Hi Andrzej,
>>
>> this is my "hack":
> 
> Serge,
> 
> thanks for this idea. I entered it into my patches.
> 
> Maybe I should remove zic compilation from /root/.bash_profile for possibility
> to parallel chrooting into currently building system from second screen?
> 
> BTW. why don't enter this linking into /root/.bash_profile ?
> 
> Regards
> 

Heiko Zuerker wrote:

> I just uploaded my updates, see if the latest kernel + grsec behave
> better for you.

Thanks.

There is no difference. With last Grsecurity/PaX I obtain as usually:
> ./codec_g723-ast16-gcc4-glibc-core2-sse4.so: error while loading shared libraries:
>       ./codec_g723-ast16-gcc4-glibc-core2-sse4.so: cannot enable executable stack 
>       as shared object requires: Permission denied

So I sent this issue to proper author group 
http://groups.google.com/group/asterisk-g729/
and variant with Asterisk I'm compiling without Grsecurity.

Regards

-- 
Andrzej Odyniec