December 8, 201114 yr Ok! Now the system is up but it is in Basic Version and no my PRO version that I have in 4.7. Help-me please!!!!!
December 8, 201114 yr Hi Joe I make some try but the problem isn't solved. Only one time the server it was accessible from web GUI but in basic version. I notice a problem that I think is on my USB key: if I access via Telnet to the server and I move to the /boot folder inside is only present a empty /config folder no other files. If I try to copy the syslog file on /boot and make it visible (-ax-) I can see the syslog file but as I insert the USB flash on my Windows PC this file is no longer present and I can see all other files and folder. In syslog there are several error concerning the USB key: "Tower kernel: hub 1-0:1.0: unable to enumerate USB device on port 1 1-0" This error repeat for 10/15 time. I returned on 4.7 version and all works, but sometimes the server don't start with an error "no such file or directory network.cfg"
December 8, 201114 yr Any ideas why I'm getting these network errors? Performance doesn't seem to be effected (not benchmarked however) but I remember these error messages were an issue before, so what is happening now? Tom, any ideas on anything I should try, r8168 mod probe or something (Give me a guide if you have any ideas!) Realtek 8112L on AM3 board. Syslog coming... Cheers Dec 8 13:07:02 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:07:28 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:08:13 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:08:18 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:08:49 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:09:38 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:10:29 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:11:37 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:12:51 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:13:30 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:14:44 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:15:25 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:15:33 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:16:35 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:16:57 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:17:08 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:17:21 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:18:31 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:19:31 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:19:44 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:20:09 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:20:28 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:20:51 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:21:37 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:22:34 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:24:12 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:25:59 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:26:37 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:27:44 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:28:22 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:28:30 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:28:45 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:29:37 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:30:23 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:30:46 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Also, any ideas why I keep getting: Dec 8 20:04:18 Tower emhttp: shcmd (69): /usr/sbin/hdparm -y /dev/sda &> /dev/null syslog-2011-12-08.txt
December 9, 201114 yr Any ideas why I'm getting these network errors? Performance doesn't seem to be effected (not benchmarked however) but I remember these error messages were an issue before, so what is happening now? Dec 8 13:07:02 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:07:28 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:08:13 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:08:18 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) ... Dec 8 13:29:37 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:30:23 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:30:46 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) I'm rather rusty and there are a few things in your syslog I haven't seen before, and I don't know anything about your previous network issues, so my comments may or may not be helpful. The "link up" messages are not errors, just an indication of a connection (or reconnection) to the physical network. There are a batch of these messages late in your syslog that do seem odd, in that they have no corresponding "link down" message, but I don't know the significance. They seem harmless, but the network driver may be a bit confused. Also, any ideas why I keep getting: Dec 8 20:04:18 Tower emhttp: shcmd (69): /usr/sbin/hdparm -y /dev/sda &> /dev/null That is just the manual command to the Cache drive to spin down. It is not an array drive, so spin down is handled differently. Completely normal.
December 9, 201114 yr Also, any ideas why I keep getting: Dec 8 20:04:18 Tower emhttp: shcmd (69): /usr/sbin/hdparm -y /dev/sda &> /dev/null That is just the manual command to the Cache drive to spin down. It is not an array drive, so spin down is handled differently. Completely normal. I've never got those before Must be a b14 thing!
December 9, 201114 yr No, that showed up earlier than b14. Hmm Oh well, nevermind then, it works, and the parity check ran A-ok so I'm happy!
December 11, 201114 yr Any ideas why I'm getting these network errors? Performance doesn't seem to be effected (not benchmarked however) but I remember these error messages were an issue before, so what is happening now? Dec 8 13:07:02 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:07:28 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:08:13 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:08:18 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) ... Dec 8 13:29:37 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:30:23 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:30:46 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) I'm rather rusty and there are a few things in your syslog I haven't seen before, and I don't know anything about your previous network issues, so my comments may or may not be helpful. The "link up" messages are not errors, just an indication of a connection (or reconnection) to the physical network. There are a batch of these messages late in your syslog that do seem odd, in that they have no corresponding "link down" message, but I don't know the significance. They seem harmless, but the network driver may be a bit confused. Also, any ideas why I keep getting: Dec 8 20:04:18 Tower emhttp: shcmd (69): /usr/sbin/hdparm -y /dev/sda &> /dev/null That is just the manual command to the Cache drive to spin down. It is not an array drive, so spin down is handled differently. Completely normal. Hello. Just my 2p and may not be any use. What type of switch do you have that your are plugged in to? I have seen messages like that on other systems when the network port is flapping, ie coming up and down. Sometimes this is due to a speed and duplex issues between the device and the switch. Just a thought.
December 11, 201114 yr In working on updating some plugins and utilities for the 5.0 series, I noticed something missing in B14, that I think began sooner, but I didn't catch it till now. /proc/mdcmd does not return two ignorant pieces of information any longer: diskModel; diskSerial; Was that intentional? Can we have them back?
December 11, 201114 yr I am currently using beta 9 but I want to have plugin support which is beta 11+. Would you guys say that this would be the best version to use? Or one of the previous versions? Thanks!
December 12, 201114 yr I am currently using beta 9 but I want to have plugin support which is beta 11+. Would you guys say that this would be the best version to use? Or one of the previous versions? Thanks! I've found Beta 12a to be the most stable for my purposes.
December 12, 201114 yr Any ideas why I'm getting these network errors? Performance doesn't seem to be effected (not benchmarked however) but I remember these error messages were an issue before, so what is happening now? Dec 8 13:07:02 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:07:28 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:08:13 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:08:18 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) ... Dec 8 13:29:37 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:30:23 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) Dec 8 13:30:46 Tower kernel: r8169 0000:02:00.0: eth0: link up (Network) I'm rather rusty and there are a few things in your syslog I haven't seen before, and I don't know anything about your previous network issues, so my comments may or may not be helpful. The "link up" messages are not errors, just an indication of a connection (or reconnection) to the physical network. There are a batch of these messages late in your syslog that do seem odd, in that they have no corresponding "link down" message, but I don't know the significance. They seem harmless, but the network driver may be a bit confused. Also, any ideas why I keep getting: Dec 8 20:04:18 Tower emhttp: shcmd (69): /usr/sbin/hdparm -y /dev/sda &> /dev/null That is just the manual command to the Cache drive to spin down. It is not an array drive, so spin down is handled differently. Completely normal. Hello. Just my 2p and may not be any use. What type of switch do you have that your are plugged in to? I have seen messages like that on other systems when the network port is flapping, ie coming up and down. Sometimes this is due to a speed and duplex issues between the device and the switch. Just a thought. Gigabit Airport Extreme from mid-2007. MBP <-> MP don't have any issues (Hit 90+MB/sec)
December 12, 201114 yr I am currently using beta 9 but I want to have plugin support which is beta 11+. Would you guys say that this would be the best version to use? Or one of the previous versions? Thanks! I've found Beta 12a to be the most stable for my purposes. ... and for me, Beta 11 is he best, since NFS is badly broken in all subsequent releases.
December 12, 201114 yr I am currently using beta 9 but I want to have plugin support which is beta 11+. Would you guys say that this would be the best version to use? Or one of the previous versions? Thanks! I've found Beta 12a to be the most stable for my purposes. ... and for me, Beta 11 is he best, since NFS is badly broken in all subsequent releases. How badly broken?
December 12, 201114 yr ... and for me, Beta 11 is he best, since NFS is badly broken in all subsequent releases. How badly broken? For me, reading a file via NFS can simply hang after a few seconds, with no error being logged. Others have reported that subtitles simply stop displaying when playing movies.
December 13, 201114 yr There is one nfs fix in one of the patches between 3.1.1 and 3.1.5 (current) but I have no idea if it is relevant. I have 3.1.5 running on my test unraid server with beta 14. If you're interested in testing it, let me know (I don't use nfs.)
December 13, 201114 yr 3.2 is up to rc5, so hopefully that will be out soon... And maybe it has even more fixes so that V5 can go RC.
December 13, 201114 yr I'd rather have 3.1.5 (current) than 3.2.0. It's more mature. As for nfs, fixes are mentioned a bunch of times in the changelogs between 3.1.0 and 3.1.5.
December 13, 201114 yr I have 3.1.5 running on my test unraid server with beta 14. If you're interested in testing it, let me know (I don't use nfs.) Thank you for allowing me to test the kernel 3.1.5/beta14 combination. Unfortunately, an nfs file transfer (from a disk share) still hangs during copying the first file. Back to b11 for me!
December 16, 201114 yr You might want to try the Kernel that is in B11 in beta 14 and see if NFS is fixed if so then it is a Kernel problem but if not then Unraid Might have a problem. Thank you
December 16, 201114 yr That would be interesting!! but I think we lose SMB2? or it possible to add that to kernel in B11, would be nice to try anyway
December 17, 201114 yr You might want to try the Kernel that is in B11 in beta 14 and see if NFS is fixed if so then it is a Kernel problem but if not then Unraid Might have a problem. Indeed, that is a sensible suggestion. The problem is that I simply don't have the knowledge to enable me to do that, and I suspect that it would take me a long time to find the information. My suspicion is that something associated with nfs has changed in the 3.x kernel and unRAID makes some assumption about nfs which only worked with earlier kernels.
December 17, 201114 yr Just installed b14, first time using a beta, just wondering if this is normal, when under the shares tab and I click the 'Complete.ssz'&runCmd=Start button, it also shows the command on the main terminal screen. is that normal? or should I be concerned?
December 17, 201114 yr I hesitated to write and post this message. It is not my intention to start any type of flame war. I am quite new to the world of unRAID and the equipment that I have currently devoted to it should probably be donated to a museum. (The motherboard and processor were purchased back in 2005 for use in a box to evaluate Linux.) You can see the complete equipment list in my signature. I put together this setup together to evaluate the interface and usability of unRAID to replace FreeNAS on my Media Server. I have been running both beta 13 and beta 14 as a part of my evaluation. Since there is only 100GB of total storage space on this test system, I could only load four movies on it-- Two Blu-ray's and Two DVD's--- all in ISO format. I play these movies on a Netgear NTV-550 media player. My unRAID setup has unMenu and the "Simple Features" plug-ins currently installed. (I consider these tow pieces of software ABSOLUTELY essential if I would to ever switch to unRAID!) Now, as to why am I write this post. It is because I have had no problems streaming blu-ray content with NFS. I have had no problems streaming Blu-ray content with CIFS. (My FreeNAS does have problems doing this!!!) This morning, I decided to run a controlled experiment which I conducted under controlled conditions and recorded the conditions and results as I was doing them. I took my netbook downstairs to the Netgear/TV seup so that I could monitor both the playback on the TV and control unRAID through the menu interface. Using NFS, I selected Avatar (ready for the 'play' button) and then manually spun down all disks. Waited for approximately one minute. I played Avatar for a minimum of five minutes-- No problems. I then repeated the sequence for Rio. Again, no problems. I next tried CIFS (Samba), used the same procedures and had the same result--- No problems. (This portion of the test was done because I was curious about unRAID's CIFS performance.) I now decided to see if I could create a problem using the NFS protocol. I started Avatar playing. I then paused the playback. I spun down all the disks manually using the interface. I pressed play again. The movie would play for a few seconds. Then the video and audio would both pause (or freeze in the case of the video) for perhaps two seconds. The video would restart and a couple of seconds after that, the audio would restart. This action was repeatable. I hope this helps someone to begin to unravel the problems with NFS and beta 13 and 14. EDIT: I used User Shares and NOT Disk Share for all of my testing.
Archived
This topic is now archived and is closed to further replies.