Re: Loss of lan after memory upgrade

[Gene Heskett]

On Thursday 14 January 2016 12:59:08 jdd wrote:

> Le 14/01/2016 17:23, Gary L. Roach a écrit :
> > On reboot, my router connection light is lit until the bios is
> > finished and the OS starts to load. At this point the light goes
> > out.
>
> what kind of router? ethernet link to the computer - usb or plugged
> card in a slot?
>
> may be you moved the card when working on the memory. try reinserting
> all cards
>
> jdd

I suspect the real problem here, and its devoured my lunch several times, 
is udevs rule that increments the device number everytime something new 
is installed, includeing system sw from an "upgrade" eth0 should remain 
eth0 if its the first interface found.

Check your dmesg after a fresh boot, it can be extremely enlightening. 
grep for eth and see what falls out.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Loss of lan after memory upgrade

[Don Armstrong]

On Thu, 14 Jan 2016, Gary L. Roach wrote:
> On reboot, my router connection light is lit until the bios is
> finished and the OS starts to load. At this point the light goes out.
> I thought at first I has a cable problem but have found this not to be
> the case. I have managed ( not sure how) to restore receiving but not
> sending capability. Ping to localhost works. Ping to the router
> doesn't. I have looked at all of the log files and have not been able
> to spot anything pertinent. I tried restoring part of the system from
> backup but that didn't work. The backup may be corrupted as well. All
> of the files seem to be ok but I am not completely sure.
>
> Has anyone had a similar problem and can suggest a fix. I will supply
> added information as needed.

I've had some problems with cheaper network cards behaving badly and
losing link once the firmware is loaded by the OS. Often this is fixed
by simply unplugging and re-plugging the cable.

But that said, I would suspect a bad cable, bad configuration, bad
router port, or similar first, as those tend to be far more likely.

What does ip link; say when things are plugged in? Do you get all of the
link lights? Does the output of ip addr; make sense for the network? Do
you see any useful packets inbound when you run tcpdump -i eth0 -n; ?


-- 
Don Armstrong  http://www.donarmstrong.com

If everything seems to be going well, you have obviously overlooked
something.
 -- Steven Wright

Re: Loss of lan after memory upgrade

[jdd]

Le 14/01/2016 17:23, Gary L. Roach a écrit :


On reboot, my router connection light is lit until the bios is finished
and the OS starts to load. At this point the light goes out.


what kind of router? ethernet link to the computer - usb or plugged card 
in a slot?


may be you moved the card when working on the memory. try reinserting 
all cards


jdd

Re: Loss of lan after memory upgrade

[Miles Fidelman]

It could be udev related.

Take a look at /etc/udev/rules.d/70-persistent-net.rules
Remove the lines starting with SUBSYSTEM containing the string "eth0"

Reboot
Udev will automatically detect and configure your network interfaces.

It won't hurt to try.

Miles Fidelman


On 1/14/16 11:23 AM, Gary L. Roach wrote:

Hi all;

I am not 100% sure that the lan problem is connected to the memory 
upgrade but the problem started right after I did the upgrade.


Setup:
Debian stretch
kde desktop
dp55kg motherboard
Increased ram from 4GB to 12GB Kingston sticks

I have run a complete memory test. All memory seems to be good.

On reboot, my router connection light is lit until the bios is 
finished and the OS starts to load. At this point the light goes out. 
I thought at first I has a cable problem but have found this not to be 
the case. I have managed ( not sure how)  to restore receiving but not 
sending capability. Ping to localhost works. Ping to the router 
doesn't. I have looked at all of the log files and have not been able 
to spot anything pertinent. I tried restoring part of the system from 
backup but that didn't work. The  backup may be corrupted as well. All 
of the files seem to be ok but I am not completely sure.


Has anyone had a similar problem and can suggest a fix. I will supply 
added information as needed.


Gary R.


--
In theory, there is no difference between theory and practice.
In practice, there is.   Yogi Berra

Re: Loss of lan after memory upgrade

[Charlie Kravetz]

On Thu, 14 Jan 2016 08:23:31 -0800
"Gary L. Roach"  wrote:

>Hi all;
>
>I am not 100% sure that the lan problem is connected to the memory 
>upgrade but the problem started right after I did the upgrade.
>
>Setup:
>Debian stretch
>kde desktop
>dp55kg motherboard
>Increased ram from 4GB to 12GB Kingston sticks
>
>I have run a complete memory test. All memory seems to be good.
>
>On reboot, my router connection light is lit until the bios is finished 
>and the OS starts to load. At this point the light goes out. I thought 
>at first I has a cable problem but have found this not to be the case. I 
>have managed ( not sure how)  to restore receiving but not sending 
>capability. Ping to localhost works. Ping to the router doesn't. I have 
>looked at all of the log files and have not been able to spot anything 
>pertinent. I tried restoring part of the system from backup but that 
>didn't work. The  backup may be corrupted as well. All of the files seem 
>to be ok but I am not completely sure.
>
>Has anyone had a similar problem and can suggest a fix. I will supply 
>added information as needed.
>
>Gary R.
>

What happened when you removed the new memory and just used the old
again? 

-- 
Charlie Kravetz
Linux Registered User Number 425914
[http://linuxcounter.net/user/425914.html]
Never let anyone steal your DREAM.   [http://keepingdreams.com]

Re: Loss of lan after memory upgrade (SOLVED)

[Gary Dale]

On 14/01/16 04:38 PM, Gary Roach wrote:
I want to thank everybody for their suggestions. I still don't know 
what the problem was but solved it by booting up the stretch 
installation / rescue disk. Going through the initial setup, including 
the network setup, cleared the problem.


A search of the web found reference to multiple cases of the same 
problem. They all have one thing in common. Tons of replies with no 
results. It seems that the first thing to try with this one is the 
rescue disk. Something gets tweeked somewhere and the rescue disk 
straightens it out. A puzzlement.


Gary R.


One thing it might have also have been is that ifupdown may have been 
removed by a recent upgrade. Reinstalling it worked for me.

Re: Loss of lan after memory upgrade

[Brian]

On Thu 14 Jan 2016 at 13:08:27 -0500, Gene Heskett wrote:

> On Thursday 14 January 2016 12:59:08 jdd wrote:
> 
> > Le 14/01/2016 17:23, Gary L. Roach a écrit :
> > > On reboot, my router connection light is lit until the bios is
> > > finished and the OS starts to load. At this point the light goes
> > > out.
> >
> > what kind of router? ethernet link to the computer - usb or plugged
> > card in a slot?
> >
> > may be you moved the card when working on the memory. try reinserting
> > all cards
> >
> > jdd
> 
> I suspect the real problem here, and its devoured my lunch several times, 
> is udevs rule that increments the device number everytime something new 
> is installed, includeing system sw from an "upgrade" eth0 should remain 
> eth0 if its the first interface found.

Which udev rule is this which changes the interface name when *any* new
hardware is installed? Perhaps you could quote it?

> Check your dmesg after a fresh boot, it can be extremely enlightening. 
> grep for eth and see what falls out.

Decent advice. He's on Stretch, so 'journalctl' may be something to use
as well.

Re: Loss of lan after memory upgrade

[Brian]

On Thu 14 Jan 2016 at 12:51:28 -0500, Miles Fidelman wrote:

> It could be udev related.
> 
> Take a look at /etc/udev/rules.d/70-persistent-net.rules
> Remove the lines starting with SUBSYSTEM containing the string "eth0"
> 
> Reboot
> Udev will automatically detect and configure your network interfaces.

With a predicatable name (which will not be eth0).

> It won't hurt to try.

Want to bet on this?

Re: Loss of lan after memory upgrade

[Gene Heskett]

On Thursday 14 January 2016 15:19:19 Brian wrote:

> On Thu 14 Jan 2016 at 15:00:59 -0500, Gene Heskett wrote:
> > On Thursday 14 January 2016 14:27:04 Brian wrote:
> > > Which udev rule is this which changes the interface name when
> > > *any* new hardware is installed? Perhaps you could quote it?
> >
> > 70-persistent-net in /etc/udev/rules.d
> >
> > I'd post it, but mine has been hacked, by moi, so it wouldn't apply
> > very many other places.  So has the one on the machine that drove me
> > to drink, so here is what it is now:
>
> You have to be driven to drink? That's grim. Steel up your loins! I
> find a little beckoning is sufficient.
>
> > gene@GO704:~$ cat /etc/udev/rules.d/70-persistent-net.rules
> > # This file was automatically generated by the
> > /lib/udev/write_net_rules # program, run by the
> > persistent-net-generator.rules rules file. #
> > # You can modify it, as long as you keep each rule on a single
> > # line, and change only the value of the NAME= key.
> >
> > # PCI device
> > 0x14e4:/sys/devices/pci:00/:00:1c.4/:03:00.0 (tg3)
> > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
> > ATTR{address}=="00:1a:a0:a7:a8:d4", ATTR{dev_id}=="0x0",
> > ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> >
> > ISTR its also marked immutable to keep udevs rule generator from
> > "fixing" it.  That hard drive, with a complete, debian wheezy based
> > LinuxCNC install on it, had been in 4 computers while I was looking
> > for one that actually worked well full time.  And every time I moved
> > the drive, I lost my networking, so I finally fixed it my way. Now
> > it works, even if that Dell Dimension 745 upchucks tomorrow and I
> > have to go & buy another that has a different network chip in it.
> >
> > It may not be correct in the udev authors opinion, but at least it
> > works here, and that, to this user, IS the bottom line.
>
> Whether the OP has /etc/udev/rules.d/70-persistent-net.rules depends
> on whether his Stretch install is a new one or not.

These install are all based on wheezy.  And I failed to note above, that 
if a new machine gets that drive, this must be reset with the dmesg 
discovery data:
  0x14e4:/sys/devices/pci:00/:00:1c.4/:03:00.0 (tg3)

And it might be potentially useful to be using the same MAC address, but 
to be pure, that should also be obtained from dmesg.  That depends on 
how persnickety the rest of ones local network is about it.  dhcp comes 
to mind as a potential problem child, but thats one daemon that never 
gets started anyplace but my router. YMMV.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Loss of lan after memory upgrade (SOLVED)

[Gary Roach]

I want to thank everybody for their suggestions. I still don't know what 
the problem was but solved it by booting up the stretch installation / 
rescue disk. Going through the initial setup, including the network 
setup, cleared the problem.


A search of the web found reference to multiple cases of the same 
problem. They all have one thing in common. Tons of replies with no 
results. It seems that the first thing to try with this one is the 
rescue disk. Something gets tweeked somewhere and the rescue disk 
straightens it out. A puzzlement.


Gary R.

On 01/14/2016 08:23 AM, Gary L. Roach wrote:

Hi all;

I am not 100% sure that the lan problem is connected to the memory 
upgrade but the problem started right after I did the upgrade.


Setup:
Debian stretch
kde desktop
dp55kg motherboard
Increased ram from 4GB to 12GB Kingston sticks

I have run a complete memory test. All memory seems to be good.

On reboot, my router connection light is lit until the bios is 
finished and the OS starts to load. At this point the light goes out. 
I thought at first I has a cable problem but have found this not to be 
the case. I have managed ( not sure how)  to restore receiving but not 
sending capability. Ping to localhost works. Ping to the router 
doesn't. I have looked at all of the log files and have not been able 
to spot anything pertinent. I tried restoring part of the system from 
backup but that didn't work. The  backup may be corrupted as well. All 
of the files seem to be ok but I am not completely sure.


Has anyone had a similar problem and can suggest a fix. I will supply 
added information as needed.


Gary R.

Re: Loss of lan after memory upgrade

[Gene Heskett]

On Thursday 14 January 2016 14:27:04 Brian wrote:

> On Thu 14 Jan 2016 at 13:08:27 -0500, Gene Heskett wrote:
> > On Thursday 14 January 2016 12:59:08 jdd wrote:
> > > Le 14/01/2016 17:23, Gary L. Roach a écrit :
> > > > On reboot, my router connection light is lit until the bios is
> > > > finished and the OS starts to load. At this point the light goes
> > > > out.
> > >
> > > what kind of router? ethernet link to the computer - usb or
> > > plugged card in a slot?
> > >
> > > may be you moved the card when working on the memory. try
> > > reinserting all cards
> > >
> > > jdd
> >
> > I suspect the real problem here, and its devoured my lunch several
> > times, is udevs rule that increments the device number everytime
> > something new is installed, includeing system sw from an "upgrade"
> > eth0 should remain eth0 if its the first interface found.
>
> Which udev rule is this which changes the interface name when *any*
> new hardware is installed? Perhaps you could quote it?
>
70-persistent-net in /etc/udev/rules.d

I'd post it, but mine has been hacked, by moi, so it wouldn't apply very 
many other places.  So has the one on the machine that drove me to drink, 
so here is what it is now:

gene@GO704:~$ cat /etc/udev/rules.d/70-persistent-net.rules 
# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x14e4:/sys/devices/pci:00/:00:1c.4/:03:00.0 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="00:1a:a0:a7:a8:d4", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
KERNEL=="eth*", NAME="eth0"

ISTR its also marked immutable to keep udevs rule generator from "fixing"
it.  That hard drive, with a complete, debian wheezy based LinuxCNC install
on it, had been in 4 computers while I was looking for one that actually 
worked well full time.  And every time I moved the drive, I lost my networking,
so I finally fixed it my way. Now it works, even if that Dell Dimension
745 upchucks tomorrow and I have to go & buy another that has a different
network chip in it.

It may not be correct in the udev authors opinion, but at least it works 
here, and that, to this user, IS the bottom line.

> > Check your dmesg after a fresh boot, it can be extremely
> > enlightening. grep for eth and see what falls out.
>
> Decent advice. He's on Stretch, so 'journalctl' may be something to
> use as well.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

Re: Loss of lan after memory upgrade

[Brian]

On Thu 14 Jan 2016 at 15:00:59 -0500, Gene Heskett wrote:

> On Thursday 14 January 2016 14:27:04 Brian wrote:
> 
> > Which udev rule is this which changes the interface name when *any*
> > new hardware is installed? Perhaps you could quote it?
> >
> 70-persistent-net in /etc/udev/rules.d
> 
> I'd post it, but mine has been hacked, by moi, so it wouldn't apply very 
> many other places.  So has the one on the machine that drove me to drink, 
> so here is what it is now:

You have to be driven to drink? That's grim. Steel up your loins! I find a 
little
beckoning is sufficient.

> gene@GO704:~$ cat /etc/udev/rules.d/70-persistent-net.rules 
> # This file was automatically generated by the /lib/udev/write_net_rules
> # program, run by the persistent-net-generator.rules rules file.
> #
> # You can modify it, as long as you keep each rule on a single
> # line, and change only the value of the NAME= key.
> 
> # PCI device 0x14e4:/sys/devices/pci:00/:00:1c.4/:03:00.0 (tg3)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
> ATTR{address}=="00:1a:a0:a7:a8:d4", ATTR{dev_id}=="0x0", ATTR{type}=="1", 
> KERNEL=="eth*", NAME="eth0"
> 
> ISTR its also marked immutable to keep udevs rule generator from "fixing"
> it.  That hard drive, with a complete, debian wheezy based LinuxCNC install
> on it, had been in 4 computers while I was looking for one that actually 
> worked well full time.  And every time I moved the drive, I lost my 
> networking,
> so I finally fixed it my way. Now it works, even if that Dell Dimension
> 745 upchucks tomorrow and I have to go & buy another that has a different
> network chip in it.
> 
> It may not be correct in the udev authors opinion, but at least it works 
> here, and that, to this user, IS the bottom line.

Whether the OP has /etc/udev/rules.d/70-persistent-net.rules depends on
whether his Stretch install is a new one or not.