Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I just tried to fall back to the older kernel....it insists on using e100 for eth0.
OK. Thank you for trying this. I was wondering if there was a newer-kernel bug that was introduced by your updates (post #1), but it seems it is not a kernel bug, but a config-file bug somewhere.
Quote:
after I rename the file, and run locate, i get the old name back, though this file is not present in the folder
That is because locate consults its database which was out of date the moment you renamed that file. You can bring things up to date with (as root) locate -u or updatedb (depending, and I do not run Debian) [ These commands are usually run daily by (ana)cron so the database of what is where is generally never more than one day old ]. Then try the locate comand again, the old file should be gone.
[ You might want to leave the e100.ko named as it should be in case you add hardware in the future and wonder why it doesn't work (because it really needs the e100 module) Reminder: "Change ONE thing at a time, and remember to write down what you changed, or you may end up in a BIG mess that calls for a reinstall ]
You then tried removing the e100 and tg3 modules, them modprobe-ing tg3
You ended up with two interfaces - eth0 and eth2.
Q1] Are they working as expected?
Q2] Does this match your hardware - do you have only two ethernet interfaces?
Something is still loading the e100 module when you do not want it to be loaded. I do not know why it is being loaded. It should not be loaded for your hardware. We tried blacklisting it - that didn't work.
Progress is "promising" because if we can disable e100 then both cards look as though they'll use tg3, and work.
Q3] Maybe it's time to try update-initramfs, or substitute an "ugly hack" (but I'd rather not do that). Are you ready?
I think that's the step we need to take. If you back up your current /boot/init.rd.img-kernelnumber to /boot/init.rd.img-kernelnumber-my-backup you should be OK to proceed. Make sure you have a live CD to boot from, or can select a previous kernel to boot from in case of a mistake.
Last edited by tredegar; 05-31-2009 at 03:56 PM.
Reason: italics for clarity
[ You might want to leave the e100.ko named as it should be in case you add hardware in the future and wonder why it doesn't work (because it really needs the e100 module) Reminder: "Change ONE thing at a time, and remember to write down what you changed, or you may end up in a BIG mess that calls for a reinstall ]
Renamed back to e100.ko. I am not doing more than what I write here, because I am pretty sure that I can forget what changes have been applied.
Quote:
You ended up with two interfaces - eth0 and eth2.
Q1] Are they working as expected?
Yes, everything works fine with eth0 and eth2 specified in /etc/network/interfaces.
Quote:
Q2] Does this match your hardware - do you have only two ethernet interfaces?
Q3] Maybe it's time to try update-initramfs, or substitute an "ugly hack" (but I'd rather not do that). Are you ready?
I think that's the step we need to take. If you back up your current /boot/init.rd.img-kernelnumber to /boot/init.rd.img-kernelnumber-my-backup you should be OK to proceed. Make sure you have a live CD to boot from, or can select a previous kernel to boot from in case of a mistake.
Yes, it seems that I do not have any other options at the moment. I will try to do so tomorrow, since it is pretty late at the moment.
Another thing.
This post seems to have some problems with tg3 and e100. http://www.centos.org/modules/newbb/...er=ASC&start=0
The person is just modifying the modprobe.conf file directly...though it is said in the file not to do so.
Code:
[root@localhost ~]# cat /etc/modprobe.conf
alias eth0 tg3
alias eth1 e100
alias scsi_hostadapter aic7xxx
alias scsi_hostadapter1 aacraid
alias net-pf-10 off
So, can we actually modify the modprobe.conf directly or not?
What would be the effects?
Quite obviously, at this point you are up and running.
I can't tell you offhand why you have eth2 instead of eth1; I presume that someplace along the way of changing the drivers, the system had an eth1 which later got destroyed. It might have been left over from the initial ram filesystem.
I would guess that if you rename the e100.ko file to something else and reboot, your system will come up correctly with the proper drivers. Alternatively, try following tredegar's instructions to use update-initramfs.
You attempted to use the /etc/modprobe.d/blacklist file to blacklist the e100 module that is being loaded by the kernel. the first paragraph in the blacklist file says..
Quote:
it-lenny:# cat /etc/modprobe.d/blacklist
# This file lists modules which will not be loaded as the result of
# alias expansion, with the purpose of preventing the hotplug subsystem
# to load them. It does not affect autoloading of modules by the kernel.
# This file is provided by the udev package.
I would also look at /etc/udev/rules.d/70-persistent-net.rules to see what the udev rules are saying about your network interfaces.. might be a simple fix in there as well. (renaming interfaces, etc.)
Before I proceed any further, I have to resolve another problem. Now, I tried to restart it once again, to see which modules load. In the boot process, the box hangs at the point where it says:
"Starting openntpd:"
Nothing else happens. I tried to restart it a couple of times and to load a different kernel, but no :|
How could any of the modifications I introduced affect an ntpd??
Edit: The only ntp server runs on this machine, i just found out.
Is there a way to "skip" the starting of openntpd at the boot process?
Problem with interfaces => problem with openntpd in this case?
Edit2: After some period of time (5-10 minutes), the following message is printed, and nothing else is happening:
Quote:
Starting openntpd:
3w-9xxx: scsi0: AEN: INFO (0x04:0x000C): Initialize started: unit=1.
Then I got another message:
Quote:
3w-9xxx: scsi0: AEN: INFO (0x04: 0x0007) : Initializing completed:unit=0 subunit=0
Both of these messages come from the RAID, and mean "Initialize started" and "Initialize completed". Nothing happens afterwards though. I don't like these two messages...
I can ping it from machines on the local net. But cannot access it via ssh (due to internal limitations, i.e., I do not have an access to the box from other boxes on the same net).
Previously i used to access it with a key from my laptop, but now that interface is down. I modified the /etc/network/interfaces to be set up for eth0 and eth1 before I reboot, so I lost eth2...
Last edited by brownflamigo1; 06-01-2009 at 09:32 AM.
Thanks, farslayer, for the definitive link to module blacklisting for Debian.
@brownflamigo1
Things appear to be getting worse.
openntpd needs the internet, so maybe that is why it is getting stuck.
I can't help you with your RAID errors, if that is what they are, but can suggest that you try booting into "Recovery Mode" (well, that's what the buntus call it) = "Single user mode" at the grub menu.
This should give you a minimal console-only system that you can use to find out and repair whatever is broken.
The ntpd shouldn't start, and you'll usually be able to see any errors during the boot process on the <CTRL><ALT><F1> console.
If the RAID error is preventing your boot process from completing, I suggest you start another thread to resolve it independently of this thread.
Then you should be able to blacklist e100 by following farslayer's post at #21.
You'll remember that the command to shutdown from the command line is /sbin/shutdown -h now
Yes, it would seem unlikely that a problem with SCSI or RAID would have anything to do with the e100 driver. Booting into recovery mode is the way to go. And I would not expect ntpd getting stuck to hang the boot process.
You can kill ntpd at boot time by going to /etc/rcX.d (where X is 1 to 6, depending on your startup mode) and removing the link that refers to the ntp daemon. It will be of the form Sxyntpd where xy is a two digit number from 01 to 99 which is used to set startup order.
Sorry for the delay. There was finally an access to the single user mode. We removed the e100 from the blacklist and restarted. Everything worked out well. Later that day, we realized that the box actually has 3 interfaces and not two... So, we decided to keep them as such, with eth1 and eth2 having a connection.
Thanks everyone for the help and timely responses.
Ah so the appropriate way to start here would have been ..
lshw -c network
I do not understand why the intel card didn't show up in your lspci output though..
Now that I looked at the output of 'lshw -class network' I saw that the third controller was manufactured by a different vendor and was located separately from the other two..
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
