March 14, 20188 yr upgraded an hp workstation and proliant from RC5 with no issues observed. many thanks.
March 14, 20188 yr Updated server without issue, with the exception of the following: Mar 14 12:36:54 server root: error: /webGui/include/ProcessStatus.php: wrong csrf_token Which doesn't seem to have affected anything.
March 14, 20188 yr 3 minutes ago, -Daedalus said: Updated server without issue, with the exception of the following: Normal behavior. You rebooted your server and left the browser open.
March 14, 20188 yr I submitted a feature request via the web gui (for multiple cache pools, surprise surprise) and this is what it showed after I submitted it. Nothing major, but just thought I'd share!
March 14, 20188 yr 1 hour ago, s.Oliver said: Updated from 6.4.1 and it seems to good at first sight – besides: Docker seems to have seen a change in how access to USB devices is granted. got a docker running which accesses a usb-card reader and after the update to v6.5 it spits out access denied errors like "ERROR: Opening device /dev/bus/usb/003/003 (errno=13 Permission denied)". tried already to give "Privileged" rights to the docker = no change. tried to change from "/dev/ttyUSB0" to "/dev/bus/usb/003/003" but same access denied errors. need help here. please. thx. This is likely a docker permission issue, not a unRAID issue.
March 14, 20188 yr After upgrading to 6.5, manually copying files from my cache (ssd) to the array is lightning fast now. I don't know what you did LT but I like it. Edited March 14, 20188 yr by TUMS
March 14, 20188 yr 7 minutes ago, bonienl said: This is likely a docker permission issue, not a unRAID issue. Well... It's either a kernel change or docker change. Permissions on the device is not honored inside the container. It's changed to root:root whatever the host permission is. I was thinking to downgrade the docker version, but didn't find out how it is installed on Slackware, so gave up. But didn't use much time on it.
March 14, 20188 yr I noticed that the mover no longer shows a "mover: started" and "mover: finished". Which means if your like me, I run mover before upgrading in case there is an issue I dont want stuff just sitting on the cache drivers, your stuck twiddling your thumbs if the mover is still running when looking at the log.. can you add those lines back? upgraded to 6.5.0 from 6.4.1 without any problems. Edited March 14, 20188 yr by zoggy
March 14, 20188 yr 8 hours ago, itimpi said: There have been reports of some people only being able to load in one of the standard/GUI modes for some reason. If you are not using GUI mode then try that. Also, have you tried Safe Mode in case you have an incompatible plugin trying to load? Sorry, failed to mention that I had tried both GUI mode and Safe Mode with the same results (stuck at loading /bzroot) ...however, I just downloaded 6.5.0 again and rebooted. Still no luck at all with the default mode or Safe mode. This time it did boot into GUI mode, so, I am up and running on 6.5.0 on main server. Diagnostics are attached. This is the first release that has ever failed to boot on my server in normal mode; fortunately GUI mode worked on the second try. medianas-diagnostics-20180314-0323.zip
March 14, 20188 yr 13 minutes ago, Hoopster said: This time it did boot into GUI mode, so, I am up and running on 6.5.0 on main server Intermittent problem throughout 6.4/6.5 AFAIK no solution has ever been found. Just edit syslinux.cfg and move the menu default line so that it'll always boot to GUI mode.
March 14, 20188 yr 6 minutes ago, Squid said: Intermittent problem throughout 6.4/6.5 AFAIK no solution has ever been found. Well, in my case at least, something changed in 6.5.0 stable that was not present in any prior release. I never ran the 6.5.0 RCs on this server, just on my backup server. Perhaps I would have seen the issue earlier on this server in the RCs. 6.4.1 and all prior releases presented no such problems. 8 minutes ago, Squid said: Just edit syslinux.cfg and move the menu default line so that it'll always boot to GUI mode. Yep, already did this since it is the only mode in which the server will boot. I have now successfully rebooted three times in GUI mode, but, its still a no go for the other modes. I read in another thread that this was resolved (with a 6.3.5 release) for another user by clearing CMOS and manually selecting "normal" mode from the menu after setting GUI mode as the default. Perhaps I will give that a try.
March 14, 20188 yr Is it recommended to change the NTP server to point at Google now for existing installs (noticed it's not default for new installs)? If so, why? More reliable than the ntp pool?
March 14, 20188 yr 6 minutes ago, NNate said: Is it recommended to change the NTP server to point at Google now for existing installs (noticed it's not default for new installs) Its a licencing thing. No difference to the user.
March 14, 20188 yr 6 hours ago, s.Oliver said: Updated from 6.4.1 and it seems to good at first sight – besides: Docker seems to have seen a change in how access to USB devices is granted. got a docker running which accesses a usb-card reader and after the update to v6.5 it spits out access denied errors like "ERROR: Opening device /dev/bus/usb/003/003 (errno=13 Permission denied)". tried already to give "Privileged" rights to the docker = no change. tried to change from "/dev/ttyUSB0" to "/dev/bus/usb/003/003" but same access denied errors. need help here. please. thx. Same issue here... ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied) when I ls -la inside the /dev/ folder the permissions is following crw--w---- 1 root tty 4, 9 Mar 14 19:56 tty9 crw-rw---- 1 root dialout 4, 64 Mar 14 19:56 ttyS0 crw-rw---- 1 root dialout 188, 0 Mar 14 19:56 ttyUSB0 crw------- 1 root root 3, 0 Mar 14 19:56 ttyp0 crw------- 1 root root 3, 1 Mar 14 19:56 ttyp1 maybe something wrong here?
March 14, 20188 yr 3 minutes ago, eikum said: Same issue here... ERROR: Opening device /dev/ttyUSB0 (errno=13 Permission denied) when I ls -la inside the /dev/ folder the permissions is following crw--w---- 1 root tty 4, 9 Mar 14 19:56 tty9 crw-rw---- 1 root dialout 4, 64 Mar 14 19:56 ttyS0 crw-rw---- 1 root dialout 188, 0 Mar 14 19:56 ttyUSB0 crw------- 1 root root 3, 0 Mar 14 19:56 ttyp0 crw------- 1 root root 3, 1 Mar 14 19:56 ttyp1 maybe something wrong here? see here:
March 14, 20188 yr 4 hours ago, zoggy said: I noticed that the mover no longer shows a "mover: started" and "mover: finished". Which means if your like me, I run mover before upgrading in case there is an issue I dont want stuff just sitting on the cache drivers, your stuck twiddling your thumbs if the mover is still running when looking at the log.. can you add those lines back? upgraded to 6.5.0 from 6.4.1 without any problems. I second this request. I too like to run the Mover, stop Dockers, and stop Array prior to updating to reduce the risk of failure.
March 14, 20188 yr Is anyone else having problems downloading this? I'm getting <3kb/s and 60% packet loss to s3.amazonaws.com
March 14, 20188 yr Having problems downloading as well. Also having trouble updating dockers Edited March 14, 20188 yr by Cessquill forgot to quote post I was replying to
March 14, 20188 yr 1 hour ago, Cessquill said: Having problems downloading as well. Also having trouble updating dockers Seems to be OK now - think Amazon was having a blip.
Archived
This topic is now archived and is closed to further replies.