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 [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
>
>
signature.asc
Description: Digital signature
