Flavio61 Posted December 8, 2011 Share Posted December 8, 2011 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!!!!! Quote Link to comment
Joe L. Posted December 8, 2011 Share Posted December 8, 2011 put your .key file back on the flash drive and reboot. Quote Link to comment
Flavio61 Posted December 8, 2011 Share Posted December 8, 2011 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" Quote Link to comment
Interstellar Posted December 8, 2011 Share Posted December 8, 2011 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 Quote Link to comment
RobJ Posted December 9, 2011 Share Posted December 9, 2011 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. Quote Link to comment
Interstellar Posted December 9, 2011 Share Posted December 9, 2011 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! Quote Link to comment
BRiT Posted December 9, 2011 Share Posted December 9, 2011 No, that showed up earlier than b14. Quote Link to comment
Interstellar Posted December 9, 2011 Share Posted December 9, 2011 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! Quote Link to comment
WallaceTech Posted December 11, 2011 Share Posted December 11, 2011 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. Quote Link to comment
bubbaQ Posted December 11, 2011 Share Posted December 11, 2011 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? Quote Link to comment
rob Posted December 11, 2011 Share Posted December 11, 2011 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! Quote Link to comment
FrackinFrog Posted December 12, 2011 Share Posted December 12, 2011 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. Quote Link to comment
Interstellar Posted December 12, 2011 Share Posted December 12, 2011 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) Quote Link to comment
PeterB Posted December 12, 2011 Share Posted December 12, 2011 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. Quote Link to comment
WeeboTech Posted December 12, 2011 Share Posted December 12, 2011 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? Quote Link to comment
PeterB Posted December 12, 2011 Share Posted December 12, 2011 ... 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. Quote Link to comment
elkay14 Posted December 13, 2011 Share Posted December 13, 2011 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.) Quote Link to comment
JackBauer Posted December 13, 2011 Share Posted December 13, 2011 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. Quote Link to comment
purko Posted December 13, 2011 Share Posted December 13, 2011 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. Quote Link to comment
PeterB Posted December 13, 2011 Share Posted December 13, 2011 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! Quote Link to comment
Thornwood Posted December 16, 2011 Share Posted December 16, 2011 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 Quote Link to comment
peter_sm Posted December 16, 2011 Share Posted December 16, 2011 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 Quote Link to comment
PeterB Posted December 17, 2011 Share Posted December 17, 2011 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. Quote Link to comment
HarryRosen Posted December 17, 2011 Share Posted December 17, 2011 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? Quote Link to comment
Frank1940 Posted December 17, 2011 Share Posted December 17, 2011 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.