On Mon, May 14, 2007 at 10:28:38PM -0500, Mumia W.. wrote: > On 05/14/2007 12:45 PM, Tim Johnson wrote: > > I'm going to try to attach a dump of ps -aux as ps.txt > > I don't know if the list will allow the attachment, but we'll see. > > It will be easier to read than if pasted into kmail, I think. > >trying attachment..... > >tim > > come in a bit late but, as far as i understand when you boot up the network works for a bit and then stop after a short period of time. We know there are no iptables fulesets in place. There is only 1 interface. Some things I would suggest trying a) Have you tried a tcpdump whilst attempting to ping the default gateway ? b) have you looked at arp -n after a ping - will tell you if you are getting/sending arp packets c) use ifconfig eth0 and check the usage counter whilst trying to ping - will show you that packets are coming/going from the interface d) can you ping 127.0.0.1 - see if the stack is working e) have you loaded any modules that might be affecting this f) do you have selinux turned on - and played with the policies ?? (wild guess 8)) ) g) I would suggest a slight change to the attack below. at the grub boot prompt edit your default boot add this as a kernel option init=/bin/bash This will boot your kernel, run your initrd and then run bash instead of init. You will need to mount proc 'mount -t proc /proc /proc' and maybe tmp. Your root should be mounted ro - shouldn't need to change that. you should be able to turn on your networking 'ifup eth0' and test pinging the default gateway. Now run all the S* files one by one in /etc/rcS.d and test ping between each one. Then goto /etc/rc2.d and do the same thing. Time consuming and a bit of a pain but it will give you control and let you do what the boot process does. Some scripts might fail cause they will not be able to write to /, you can always remount / with 'mount -o remount,rw /' alex > > I suggest that you dedicate a runlevel, say 3, to debugging this > problem. For RL (runlevel) 3, disable as many services as > possible--making it almost the same as RL 1; then re-enable only those > services that get you basic network connectivity. Note the configuration. > > Then re-enable more services until network connectivity is broken again. > The last service that you enabled will probably be the culprit. > > I didn't see you say specifically whether or not you installed the beta > version of Etch. Certainly if you still have the beta Etch, it's a good > idea to update; I know, it's a catch-22 with the network down, but > sneakernet (walking CD-ROMs from one machine to another) is an option. > You could be facing a bug in the beta that has been fixed in the release > version of Etch. > > Back in RL 2, see if you can get the output from "route -n" before the > connectivity is broken; after connectivity is broken, do another "route > -n" and capture the output; post both output files here. > > BTW, the "script" command is great for recording all text data from a > terminal session. > > > > -- > To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmaster@lists.debian.org > >
Attachment:
signature.asc
Description: Digital signature