April 3, 201115 yr Hi everyone, I've set up Unraid on a new GA-E350-USB3 motherboard and it seems that it will connect to the network on 5.0beta6a, but not on 4.7. Trying to boot 4.7, the MAC address just doesn't pop up on the lan, but when I plug the box into a screen, both 5.0beta6 and 4.7 get to the point where it says "TOWER LOGIN:_". I'm unsure hot to post logs given that I can't telnet in to 4.7. Given that 5.0beta6a is unstable, is there any way I can presently have a working, stable Unraid rig? Thanks!
April 3, 201115 yr 4.7 absolutely has NIC drivers. Jump into the console and run "ifconfig -a" - will give you details of the NICs, IP addresses and other data.
April 4, 201115 yr 4.7 absolutely has NIC drivers. ... but it is entirely possible that the driver required for the GA-E350-USB3, which is a relatively new mobo, is only in 5.0. If this is a new unRAID installation, my advice would be to go with 5.0beta6. As far as I'm aware, the problem with b6 has only affected those upgrading from older versions and the problem only strikes at initial array start.
April 4, 201115 yr 4.7 absolutely has NIC drivers. ... but it is entirely possible that the driver required for the GA-E350-USB3, which is a relatively new mobo, is only in 5.0. If this is a new unRAID installation, my advice would be to go with 5.0beta6. As far as I'm aware, the problem with b6 has only affected those upgrading from older versions and the problem only strikes at initial array start. Correct. It is not an issue for new arrays. I'd go with 5.0beta6a in your case, since it has the new driver needed for your network interface.
April 4, 201115 yr Author Correct. It is not an issue for new arrays. I'd go with 5.0beta6a in your case, since it has the new driver needed for your network interface. Sensational. Thanks guys. Secondly, the array has crashed twice now in a couple of days running 5.0beta6a, both times doing parity rebuilds while transferring to it at full-tilt. Is this normal or a cause for major concern? That is, should I just leave it to build parity and then worry about crashes during normal operations, or should I try and get to the bottom of this issue now? Thanks!
April 4, 201115 yr It should not be crashing. Telnet to the server and run the tail command: tail -f /var/log/syslog This will capture the last few lines of the syslog before the crash.
April 5, 201115 yr Author It should not be crashing. Telnet to the server and run the tail command: tail -f /var/log/syslog This will capture the last few lines of the syslog before the crash. The Syslog seems to be overwritten each time the server boots up? Regardless, I'm going to start a new thread, because this is a separate issue. Thanks guys.
April 5, 201115 yr It should not be crashing. Telnet to the server and run the tail command: tail -f /var/log/syslog This will capture the last few lines of the syslog before the crash. The Syslog seems to be overwritten each time the server boots up? Regardless, I'm going to start a new thread, because this is a separate issue. Thanks guys. correct, the syslog is saved to RAM so when you reboot or the server crashes the syslog is lost. The above command given will follow the syslog as it is written to so you can see the last lines printed before the server goes down.
Archived
This topic is now archived and is closed to further replies.