So after probably 7 months of trouble free running, I came home one day to find I couldn't see any of my shares - I also couldn't bring up the web admin utility.  So I did a restart and all of the disks were spinning away for what ended up being hours.  I thought it might be somehow doing a parity check, although I still couldn't get to the web admin utility.

 

Eventually (not sure how long) the disks stop spinning, but I can neither see my shares, nor get to the admin utility.  Does anyone have any idea what might be wrong.  I have included the syslog here - but I'm afraid it doesn't mean an awful lot to me.

 

It has done the same thing each time I have tried it now - about 3 times.

Syslog looks relatively clean, no serious problems, networking appears to be working correctly, found a router at least.  There are a few small oddities, which may or may not be anything.  The system has started a parity check, which usually indicates an improper shutdown on the previous session, however it usually is also accompanied by a couple of transactions replayed on all of the data drives, and NONE were replayed on your system, which is a little odd.  According to the syslog at least, your server with v4.3.3 has fully booted and appears to be fully operational, but will be slow until parity check finishes.

 

After booting, a reset appears to be issued to the flash drive, but no errors or problems seem apparent, so there does not seem to be anything wrong with access to the flash drive.  That is important because if you lose access to the flash drive, networking may be affected or not be setup, and parity checks often are required on the subsequent boots.  The only reason I mention it is because a reset issued after boot and setup has finished is not normal, *may* indicate something is not right with the flash or the port it is using.  You might switch it to another USB port, when you next reboot.  Again, this may be nothing.

 

Also, an old AT type keyboard was found about 57 seconds after it should have been found, which is very unusual.  Again, there are no errors associated with it, but it may not be a good keyboard, since it took so long.

 

Since you have a keyboard attached, and apparently a PS/2 mouse, I would assume you also have a monitor connected?  What was (and is) showing on the monitor screen when you lose web access?  Also, does Telnet work?  This will ensure you have a network connection still, between your desktop and the server.

 

A small issue, not a priority, but all of your Seagate SATA drives appear to have their SATA I compatibility jumpers still installed.  Please see the Improving unRAID Performance, Remove SATA150 Jumper section.

Thanks Rob for the reply.

 

The keyboard message was probably when I plugged it in having realized it wasn't connected!

 

Not sure how to telnet into the box, so will look that up when I get home from work and see if i can do it - are there any instructions on this forum for those of us unfamiliar with telnet?

 

I will also find a remove the jumpers on the SATA drives - didn't realize I was slowing things down!  Will let you know how I get on with telnet-ing into the box.

How did you capture the syslog?   Didn't you use "telnet" to log onto the server to perform that task?  Or did you use the system console?

 

I'm so confused... 

 

Joe L.

Not sure how to telnet into the box, so will look that up when I get home from work and see if i can do it - are there any instructions on this forum for those of us unfamiliar with telnet?

You may not have noticed that I embedded a link to a (just like this one->) Telnet wiki page, when I mentioned it above.

 

I will also find a remove the jumpers on the SATA drives - didn't realize I was slowing things down!

You may not be able to see the improvement since there are other bottlenecks, and SATA at 1.5 Gbps is still faster than the individual drives themselves can transmit, but no reason not to take them off.  Who needs unnecessary handicaps?

 

The keyboard message was probably when I plugged it in having realized it wasn't connected!

That explains it, but I should caution you that it is considered dangerous to connect a non-USB keyboard while already powered up.  You are applying live power to the keyboard, and it has been known to damage the motherboard or keyboard (from old memories, can't recall any citations).  It has always been my understanding that it is much safer to attach non-USB keyboards and mice and VGA cables only when powered off.  Many have done so without issue though, and gotten away with it!

So I followed up on the help/ideas - thanks for the information....

 

I can't telnet into the tower from my PC.

 

I also tried pinging after checking the IP address in the syslog (manually assigned IP, rather than DHCP) - and it could not find that IP address on the network - I also confirmed that in my router IP address table - that IP address does not appear in that client list.  What was wierd was the ping response I got - it appeared to give me a response from a different IP address!  Never seen that before.

 

In response to the question as to how I captured the syslog - I simply had a keyboard and monitor connected to the tower and issued the commands to copy the syslog from there.

 

It's therefore wierd that the server appears to fully boot, appears to get an IP address, but I cannot connect in any way (telnet, ping, web admin utility, or user shares).  I am just wondering if there is a network issue here.  Are there any commands I can execute on the tower directly to test network connectivity or trouble shoot whether there is an issue with the NIC card in the server?

These lines in the syslog you posted seem to indicate the network is configured for IP address 192.168.1.150.    It appears as if you do not have DHCP enabled and this is an explicitly assigned IP address.

 

Jun 26 16:50:37 tower logger: /etc/rc.d/rc.inet1:  /sbin/ifconfig eth0 192.168.1.150 broadcast 192.168.1.255 netmask 255.255.255.0

 

Jun 26 16:50:37 tower ntpd[1818]: Listening on interface #2 eth0, 192.168.1.150#123 Enabled

Jun 26 16:50:37 tower ntpd[1818]: kernel time sync status 0040

Jun 26 16:50:37 tower ifplugd(eth0)[1842]: ifplugd 0.28 initializing.

Jun 26 16:50:37 tower ifplugd(eth0)[1842]: Using interface eth0/00:50:8D:9C:77:1D with driver <r8169> (version: 2.2LK-NAPI)

Jun 26 16:50:37 tower ifplugd(eth0)[1842]: Using detection mode: SIOCETHTOOL

Jun 26 16:50:37 tower ifplugd(eth0)[1842]: Initialization complete, link beat detected.

Jun 26 16:50:37 tower ifplugd(eth0)[1842]: Executing '/etc/ifplugd/ifplugd.action eth0 up'.

Jun 26 16:50:37 tower ifplugd(eth0)[1842]: Program executed successfully.

 

From your PC, can you ping 192.168.1.150 ?

 

Time to look more closely on how you have your router configured... and your PC, if you pinged one address, and were routed to another, then something in the PC or router is involved, and probably causing the issue you are seeing with connectivity.

 

To confirm on the unRAID server, try the following commands after you log in on the console:

ifconfig eth0

ethtool eth0

ping -c 5 192.168.1.1

net lookup google.com

 

ethtool output should have a line that says: Link detected: yes

ping should not time-out.  (I am assuming your router is at address 192.168.1.1, if not, change the ping as appropriate)

If you have a nameserver assigned, the lookup of google.com should also succeed.

 

Joe L.

Thanks for the input - I have now found the issue.

 

With the help of my trusty LAN tester, I found a suspect cable showing a short (looks like a repositioned piece of furniture pushed against the cable plugged into the wall LAN socket was the culprit).

 

I am so glad it was that simple - just replaced the plug and everything was fine.  So glad it wasn't a problem with the tower.

 

Thanks again for helping me narrow it down.