January 8, 20188 yr Successful update from rc18 to rc20 on Ryzen. System once again indicated unclean shutdown. Edit: The Win10 VM (has GPU passthrough) seems to have hanged on boot. Other two Linux VMs and Docker containers have auto-started successfully. Edited January 9, 20188 yr by realies
January 8, 20188 yr Not sure if this was caused by the rc (but the prior one I was running, rc15e (?) didn't have it)... I have 2 network interfaces that created a br0. br0 shows as using an assigned IP (192.168.1.x) but unRAID seems to think my IP is an unassigned 169.x IP address. This naturally causes problems with my dockers. If I try to statically set 192.168.1.x for one of my ethernet interfaces, the web interface stops responding (I wonder if it creates an IP address conflict by having br0 and eth0 have it?). See here for screenshots. Thoughts? Edited January 8, 20188 yr by atl-far-east
January 8, 20188 yr You have bonding enabled with eth0 and eth1 as members, therefor no configuration of eth1 is required. A 169.254.x.x address indicates no communication with a DHCP server. Check your cables. E.g. disconnect one after the other to determine the correctness of each cable.
January 8, 20188 yr Yes, thanks - that I understand. My point is my system is getting an IP correctly, unRAID is just seeming to use the wrong one for system purposes. My DHCP server is working just fine, since br0 is getting an IP. E.g.: root@Tower:/mnt/user/appdata/letsencrypt/nginx/site-confs# ifconfig bond0: flags=5443<UP,BROADCAST,RUNNING,PROMISC,MASTER,MULTICAST> mtu 1500 inet6 fe80::225:90ff:fe2b:104 prefixlen 64 scopeid 0x20<link> ether 00:25:90:2b:01:04 txqueuelen 1000 (Ethernet) RX packets 575490 bytes 783274307 (746.9 MiB) RX errors 0 dropped 104 overruns 0 frame 0 TX packets 53312 bytes 8696214 (8.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.106 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::e8a3:6eff:fedb:3884 prefixlen 64 scopeid 0x20<link> ether 00:25:90:2b:01:04 txqueuelen 1000 (Ethernet) RX packets 350184 bytes 763473005 (728.1 MiB) RX errors 0 dropped 42 overruns 0 frame 0 TX packets 51026 bytes 8525269 (8.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 172.17.0.1 netmask 255.255.0.0 broadcast 0.0.0.0 inet6 fe80::42:c2ff:fe48:bacf prefixlen 64 scopeid 0x20<link> ether 02:42:c2:48:ba:cf txqueuelen 0 (Ethernet) RX packets 44959 bytes 6085598 (5.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 302593 bytes 609460023 (581.2 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether 00:25:90:2b:01:04 txqueuelen 1000 (Ethernet) RX packets 394865 bytes 567704913 (541.4 MiB) RX errors 0 dropped 52 overruns 0 frame 0 TX packets 1074 bytes 121170 (118.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xc0600000-c061ffff eth1: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500 ether 00:25:90:2b:01:04 txqueuelen 1000 (Ethernet) RX packets 180625 bytes 215569394 (205.5 MiB) RX errors 0 dropped 52 overruns 0 frame 0 TX packets 52238 bytes 8575044 (8.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device memory 0xc0660000-c067ffff
January 8, 20188 yr Before the update my plex server running on my i7-970 box could not live encode faster than 0.7 (1.0 beeing realtime) After the update, it is up to 1.5 Edited January 8, 20188 yr by isvein
January 8, 20188 yr 38 minutes ago, isvein said: Before the update my plex server running on my i7-970 box could not live encode faster than 0.7 (1.0 beeing realtime) After the update, it is up to 1.5 You should send @limetech some money for the bonus cpu power.
January 8, 20188 yr OK so I upgraded a z400 that only runs 2 vm's. ran cinebench before and after on 4vcpus. on rc19 175 on rc20 199 ¯\_(ツ)_/¯
January 8, 20188 yr 3 hours ago, atl-far-east said: My point is my system is getting an IP correctly, unRAID is just seeming to use the wrong one for system purposes. My DHCP server is working just fine, since br0 is getting an IP. Somehow the GUI went out of sync. Can you do create_network_ini And refresh the network settings page
January 8, 20188 yr That fixed it - thanks! Never had to do that on any prior RCs/versions, so thought I'd flag. Thanks!
January 9, 20188 yr On 1/7/2018 at 10:42 PM, JustinChase said: I've just noticed that I no longer seem to have write permissions for one of my user shares. It's set as hidden/public, as it has been for a long time. I just tried to add a folder in windows, and it's telling me "Destination Folder Access Denied - You need permission to perform this action" It's letting me write to if from within my media center program, but not from windows. I disconnected the share and re-mapped it, but same issue. Unclear why you are posting in this thread. Are you sure it was working correctly immediately before updating to this version?
January 9, 20188 yr On 1/8/2018 at 9:02 AM, realies said: Successful update from rc18 to rc20 on Ryzen. System once again indicated unclean shutdown. Edit: The Win10 VM (has GPU passthrough) seems to have hanged on boot. Other two Linux VMs and Docker containers have auto-started successfully. MS pulled the patch for AMD reasons, I know you are on Ryzen but might’ve affected you. I think I got lucky with mine.
January 9, 20188 yr Author On 1/8/2018 at 7:02 AM, realies said: Successful update from rc18 to rc20 on Ryzen. System once again indicated unclean shutdown. There should have been a diagostics zip file in flash config/logs directory. Do you see one corresponding to your shutdown? If so, please post.
January 10, 20188 yr 8 hours ago, limetech said: There should have been a diagostics zip file in flash config/logs directory. Do you see one corresponding to your shutdown? If so, please post. I’m also on Ryzen and shutdown my VMs prior to upgrade due to issues with “unclean shutdown” notifications tripping a parity check. Don’t think this is isolated.
January 10, 20188 yr Author 2 minutes ago, phbigred said: I’m also on Ryzen and shutdown my VMs prior to upgrade due to issues with “unclean shutdown” notifications tripping a parity check. Don’t think this is isolated. That's wonderful, got diags from such an instance?
January 10, 20188 yr Is there a way, or kernel option to not patch the Meltdown vulnerability? I'd rather not lose the 30% performance hit in a home server.
January 10, 20188 yr Author 19 minutes ago, daze said: Is there a way, or kernel option to not patch the Meltdown vulnerability? I'd rather not lose the 30% performance hit in a home server. There is. Add 'pti=off' to end of your APPEND line in proper section of syslinux.cfg. Note we have not tested this and don't know if it works or not. Use at your own risk. Have you seen a 30% drop? I think that is way overstated in the press.
January 10, 20188 yr Unclear why you are posting in this thread. Are you sure it was working correctly immediately before updating to this version?because I think this issue is related to this new version, obviously.it's been some time since I've tried to create a new folder with Windows, and it's always worked previously.how might I figure out the cause of this new issueSent from my HTC6545LVW using Tapatalk
January 10, 20188 yr 57 minutes ago, JustinChase said: because I think this issue is related to this new version, obviously. it's been some time since I've tried to create a new folder with Windows, and it's always worked previously. how might I figure out the cause of this new issue Sent from my HTC6545LVW using Tapatalk Roll back to the previous version you were running and see if doing the same thing works. That's what I'd do.
January 10, 20188 yr Intel has released this to fix one of the security issues from the past week. https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=873 New microcode. Version: 20180108 Edited January 10, 20188 yr by Dazog
January 10, 20188 yr My ryzen stability happiness lasted 30 days of continuous uptime on RC14. When it crashed I updated unRaid to RC19, had a daily crash and now I am on RC20 with crash once a day again. I have disabled Global C-states i BIOS. If it crashes again I will try with the zenstates python script.
January 10, 20188 yr Author 1 hour ago, Dazog said: Intel has released this to fix one of the security issues from the past week. Got it, thank you.
January 10, 20188 yr Author 14 minutes ago, JohanSF said: I have disabled Global C-states i BIOS. If it crashes again I will try with the zenstates python script. You can use our version of zenstates that supports enabling/disabling/listing C6 state. See OP.
January 10, 20188 yr @limetech u say 30% decreased pferformance is too much. But could you please test how much it affects us? VM Windows? VM Linux? SMB Speeds?
January 10, 20188 yr 9 hours ago, limetech said: That's wonderful, got diags from such an instance? Like bringing a car to a mechanic I went back to rc14 turning VMs off and rebooting, no issue. Updated to rc20a and rebooted without turning off no issue. Need to play with it for a while to see if I can trip it again. I know I had an issue with rc9 that’s how I figured out the workaround.
Archived
This topic is now archived and is closed to further replies.