Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: medvedm on December 14, 2010, 01:02:34 PM
-
Hi-
I've run into an interesting situation with TC and I was hoping you guys would have some idea about what is going. I've got a system with 3 NICs, one on the main board, and two on an expansion board. The one on the main board is the only one I care about using right now, and I want it to be a static IP (of the 192.168.100.x variety). So I set it (both with ifconfig and the network app). It worked fine for a couple of reboots and then it lost the IP.
Except that what happened is that it didn't actually lose the IP. eth0 was still set as 192.168.100.10, but it suddenly couldn't ping anything any more. So I looked around in the dmesg log and saw that eth1 was reporting it was up... which shouldn't be possible because nothing is plugged into that port. Nevertheless, I configured eth1 to be the right IP and was now able to ping everyone.
Is there a way to hard associate an Ethernet adapter with eth0, eth1, or eth2? That way when the system boots up the right adapter is with the right device and gets the right IP address.
Or have I totally missed something?
-
udev rules. You can assign names by MAC address, for example.
-
Here is a link for writing udev rules for ethernet interfaces (http://reactivated.net/writing_udev_rules.html#example-netif).
-
Thanks, I think this got me what I needed.
-
Yeah, except I can't seem to make this work right.
I added a file to /etc/udev/rules.d/ called 10-local-network.rules with the following lines:
KERNEL=="eth*", ATTR{address}=="00:20:9d:15:54:72", NAME="eth0"
KERNEL=="eth*", ATTR{address}=="00:d0:81:07:00:36", NAME="eth2"
KERNEL=="eth*", ATTR{address}=="00:d0:81:07:00:37", NAME="eth1"
But, it is still totally random if 72 or 36 gets eth0. Of course, I added my file to filetool.lst so it gets backed up.
I checked the addresses using udevadm and they are right.
I'm sure I've missed something, help?
-
Another total newb question: in testing these changes I'm having to restart everytime, I"m sure I could do something easier like unload and reload the ethernet module, right?
To do so, I'd do something like this: modprobe -r e1000e
and then to relaod: modprobe -a e1000e
-
and then to relaod: modprobe -a e1000e
Where did you get the '-a' from?
-
BusyBox v1.17.2 (2010-09-24 12:19:23 PDT) multi-call binary.
Usage: modprobe [-alrqvsb] MODULE [symbol=value]...
Options:
-a Load multiple MODULEs
-l List (MODULE is a pattern)
-r Remove MODULE (stacks) or do autoclean
-q Quiet
-v Verbose
-s Log to syslog
-b Apply blacklist to module names too
-
I stand corrected. :-[
-
When testing, as root
#edit file
udevadm control --reload-rules
#remove module
udevadm trigger
Since backup is a bit too late in the boot process, you'll probably need something like that in bootsync.sh.
-
I'm not sure I know what you mean by "Since backup is a bit too late in the boot process, you'll probably need something like that in bootsync.sh."
Has anyone out there ever actually got this working? If so, I'd love to see a copy of your rules file for udev because everything I'm trying is not working at all. It seems a bunch of the udev stuff was borrowed from LFS, so I googled how LFS does at and still having no luck.
AGGHHH!!!!
This is another one of those things in the "should be easy but isn't" category.
-
http://www.debian-administration.org/article/Keeping_consistent_network_interface_names_with_ifrename
-
Works for me using instructions above.
etc/udev/rules.d/10-ethernet.rules
KERNEL=="eth*", ATTR{address}=="52:54:00:12:34:56", NAME="netc"
opt/bootsync.sh
#!/bin/sh
# put other system startup commands here, the boot process will wait until they complete.
# Use bootlocal.sh for system startup commands that can run in the background
# and therefore not slow down the boot process.
/opt/bootlocal.sh &
udevadm control --reload-rules
modprobe -r e1000
udevadm trigger
This works in Qemu, renaming the card from eth0 to netc.
I'm not sure I know what you mean by "Since backup is a bit too late in the boot process, you'll probably need something like that in bootsync.sh."
Backup happens quite late in the boot process, by this time the cards have already been brought up. This is why the module has to be removed, so that the new rules will be in effect.
edit: The busybox equivalent to ifrename is nameif, which can also be used.
-
Thanks for the tip about nameif (http://www.busybox.net/downloads/BusyBox.html#nameif). I did not think of that. It looks like that gives you two ways to solve the problem. You can save name/address pairs in /etc/mactab (http://www.linuxfromscratch.org/hints/downloads/files/nameif.txt):
# Begin /etc/mactab
# This file relates MAC addresses to interface names.
# We need this so that we can force the name we want
# even if the kernel finds the interfaces in the
# wrong order.
# eth0 under 2.4, eth1 under 2.6
beannet 00:60:97:52:9A:94
# eth1 under 2.4, eth0 under 2.6
sparenet 00:A0:C9:43:8F:77
# End /etc/mactab
-
Ahhhh, now the missing piece comes together. Once I added the code below to my bootsync.sh, this starting working out. I didn't understand that the actual /etc/udev/rules.d/10-network.rules files wasn't restored in time to be run by the udev tool. I guess in that case, udev obviously wouldn't rename the stuff correctly.
May I suggest a wiki page describing this? I'll even write up the first draft. The bootsync.sh file edit is incredibly important, and TC specific. Also, in my bootsynch.sh, I put the call to bootlocal.sh at the bottom... because in bootlocal, it calls the IP address config scripts, which I don't want to happen until AFTER I am sure the devices are named correctly.
Side note - most of the stuff I read on the web says not to use nameif, that udev is the way to do it.
Thanks for the help!
M