LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   Slackware 13 Network Problem, Odd Problem With 70-persistent net.rules (https://www.linuxquestions.org/questions/slackware-14/slackware-13-network-problem-odd-problem-with-70-persistent-net-rules-796314/)

pghsteel 03-18-2010 11:33 AM

Slackware 13 Network Problem, Odd Problem With 70-persistent net.rules
 
Hello:
I have a master Slackware 13 drive that I was using to clone multiple HDD's. They are all going into identical machines. The only issue I had was having to change the "/etc/udev.rules.d/70-persistent-net.rules" file. It showed the correct MAC address but was incrementing the interface name to eth1. so I just changed the 1 to a 0 and it worked fine. All was going well until I accidentally let the master HDD boot on the machine that was doing the cloning. Now the clones I make can't access the network device reliably. The "rules" file shows the correct MAC address and "eth0" as it should but ifconfig shows only "IO", no "eth0". I can fix this by deleting the file and rebooting or deleting the name in the file and rebooting. I can reboot many times after that and have good network interface but if the power dies then I reboot, I have no network. Ifconfig again returns "IO" and no "eth0" but the "net.rules" file is correct; Right MAC address and "eth0". I can't just get a good network connection from a powered down state. I have to modify or delete the "rules" file and type reboot to get it to work. Any assistance would be greatly appreciated. Knowing where in Slackware 13 the previous NIC's MAC addresses are stored might help.

Thanx; Rick

Drakeo 03-18-2010 10:44 PM

you never had to do that. all you needed to do was edit the /etc/rc.d/rc.inet1.config
then when Slackware scripts do the rest. udev will re-write the rules.d every nic has a different mac unless
you flash new ones.

open a console as root type pkgtool select run scripts choose configure net.

or as root type netconfig.
rules have nothing to do with good connection it creates the device as the module is load then sets the permission per hal
location of mac
eth0 is default you change it only if you have two nic.
as root type
Quote:

ifconfig eth0 up
OR
Quote:

ifconfig eth1 up
then you type ifconfig you will see something like this
Quote:

bash-4.1# ifconfig
eth0 Link encap:Ethernet HWaddr 00:24:8c:3e:db:74 <-------mac
inet addr:192.168.11.2 Bcast:192.168.11.255 Mask:255.255.255.0
inet6 addr: fe80::224:8cff:fe3e:db74/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:331716 errors:0 dropped:0 overruns:0 frame:0
TX packets:309260 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:324031872 (309.0 MiB) TX bytes:48022317 (45.7 MiB)
Interrupt:27 Base address:0x4000
if not you will have to type dmesg and look for your device and mac as they are being loaded into the kernel

allend 03-18-2010 11:16 PM

Zordrak has a nice explanation of this:
http://blog.tpa.me.uk/2009/12/03/mig...-new-hardware/

pghsteel 03-22-2010 12:25 PM

Solved: Network Problem, Biostar G31-M7_TE
 
Hi:
Thanks for the help. The solution was as unexpected and weird as the problem. Here's a brief corrected update of the fault:

"eth0" fails to become active on any boot that involves a powered off state. If I type reboot and restart the system that way, it always comes up OK, every time, regardless of the starting status. The /etc/udev/rules.d/70-persistent-network.rules file is correct and doesn't change regardless of the link status (After the network comes up properly at least one time the "rules" file is correct). The dmesg when faulted shows no link and doesn't appear to show any signs it tried to bring up the link, Linux forgot to try. This only happened on two units! Swapped hard drives with known good units and the problem stayed with the bad units. How did I solve it?

I punted; I tried a bunch of things that didn't seem obvious, I just thought I'd try them. What did it? Clearing CMOS and starting from scratch. I had previously gone over the BIOS, screen by screen with a good unit as my reference, they were the same. Something in there wasn't happy though. It's working now. This is a Biostar G31-M7 TE motherboard. I wish I could say definitively what the problem was but at least I can say what the solution is, I'll take that.


Rick

heinblöd 08-16-2010 03:58 AM

I have the same problem on an asus p4-800 mainboard with 2 nics (sis900 onboard and rtl 8169).
It happens exactly as pghsteel said almost everytime the computer has been cut off from power .
Only solution is to delete udev.rules and reboot


All times are GMT -5. The time now is 07:15 PM.