S80_UK Posted March 2, 2021 Share Posted March 2, 2021 2 hours ago, AgentXXL said: I've upgraded both of my systems to 6.9.0 with no major issues, the backup going from 6.8.3 and the media from 6.9 RC2. Really the only issue that I'm seeing is like @S80_UK and @doron reported. Both systems showed numerous notifications that 'drive utilization returned to normal'. Tom @limetech provided a link to the docs for this... https://wiki.unraid.net/Unraid_OS_6.9.0#SMART_handling_and_Storage_Threshold_Warnings There are changes to the way that drive specific data (such as SMART) are stored, and the utilisation thresholds are also affected by this. Quote Link to comment
Gragorg Posted March 2, 2021 Share Posted March 2, 2021 Upgrade to 6.9.0 from 6.8.3 without issues so far. Keep up the great work! Quote Link to comment
takkkkkkk Posted March 2, 2021 Share Posted March 2, 2021 1 hour ago, SimonF said: Are you using telegraf, Autofan or anything that may be using smartctl outside of the array functions? That seemed to have done it! thank you!! Quote Link to comment
AgentXXL Posted March 2, 2021 Share Posted March 2, 2021 (edited) 1 hour ago, S80_UK said: Tom @limetech provided a link to the docs for this... https://wiki.unraid.net/Unraid_OS_6.9.0#SMART_handling_and_Storage_Threshold_Warnings There are changes to the way that drive specific data (such as SMART) are stored, and the utilisation thresholds are also affected by this. Yes, I saw that in the release notes. I noted in my post that I have re-configured my thresholds but the issue persists. Perhaps I need to reboot so I'll try that. EDIT: After another reboot it still shows the drives in green on the Dashboard tab, and red on the Main tab. Another possible issue - again, after the reboot it reports an unclean shutdown, yet no errors were noticed during the reboot on the monitor directly attached to the system. I'm finished my other maintenance so I've started the system and am letting it proceed with the parity check. Something tells me it'll be fine, but I'll let unRAID do its thing. Edited March 2, 2021 by AgentXXL Updated info on persisting capacity threshold error Quote Link to comment
5STAR Posted March 2, 2021 Share Posted March 2, 2021 (edited) All upgraded to 6.9. Only issue I had was the nvidia plugin used on 6.8 didn't work. I had to uninstall that and install the NEW nvidia driver from community apps. Worked great after reboot. Also had to do the same and remove / reinstall GPU statistics and reselect NVIDIA as the hardware type. Everything seems to be working great it looks like including my Plex Server Docker. Edited March 2, 2021 by 5STAR Quote Link to comment
italeffect Posted March 2, 2021 Share Posted March 2, 2021 I have all these IPV6 "Multicast" entries after the upgrade to 6.9. I have IPV6 turned off. Am I safe to delete them all? I have been unable to find anything that explains what they are. Thanks! (Perfectly smooth upgrade from Beta30 BTW). Quote Link to comment
Rick Gillyon Posted March 2, 2021 Share Posted March 2, 2021 5 hours ago, BVD said: I put the command up further back, just head to earlier comments: Okay, so I ran the "touch /boot/config/modprobe.d/i915.conf", took the entries out of my go file and rebooted. Now I have no hardware encoders or decoders available in Emby. Was there something else I needed to do? Thanks for the assistance! Quote Link to comment
BVD Posted March 2, 2021 Share Posted March 2, 2021 24 minutes ago, Rick Gillyon said: Okay, so I ran the "touch /boot/config/modprobe.d/i915.conf", took the entries out of my go file and rebooted. Now I have no hardware encoders or decoders available in Emby. Was there something else I needed to do? Thanks for the assistance! That file just overwrites the blacklist, allowing you to use the driver either via hypervisor or docker/vm by loading the driver wherever its needed. To load it in unraid, it's just "modprobe i915", or you can add it to the file to run it automatically on boot. 1 Quote Link to comment
Rick Gillyon Posted March 2, 2021 Share Posted March 2, 2021 1 minute ago, BVD said: That file just overwrites the blacklist, allowing you to use the driver either via hypervisor or docker/vm by loading the driver wherever its needed. To load it in unraid, it's just "modprobe i915", or you can add it to the file to run it automatically on boot. Thanks. Add it to the go file or i915.conf? Quote Link to comment
BVD Posted March 2, 2021 Share Posted March 2, 2021 If you want to load it on boot every time and never use it in a vm, yeah. Otherwise I'd add it to a user script so you can decide when and where you want to use those resources. 1 Quote Link to comment
jpowell8672 Posted March 2, 2021 Share Posted March 2, 2021 (edited) Upgraded from 6.8.3 to 6.9.0 stable with issue of CPU Temp reporting incorrectly high now. Found second issue with Cache Warning Critical temp change. I have 2 NVME 1TB M.2 in Raid 0 pool and when I change the default from 50 & 55 to 70 & 75 it has to be done twice to make it apply but when I do same for second M.2 in pool it resets first one back to default 50 & 55. Then When I change the first one to 70 & 75 again it resets the second one back to default 50 & 55 again. Found third issue of several installed dockers from CA Apps shows as not installed when you search for them, Instead of settings Icon it has the Download Icon but under installed apps it shows correctly. It does it with apps from even different authors repository's. Edited March 9, 2021 by jpowell8672 Quote Link to comment
Rick Gillyon Posted March 2, 2021 Share Posted March 2, 2021 1 minute ago, BVD said: If you want to load it on boot every time and never use it in a vm, yeah. Otherwise I'd add it to a user script so you can decide when and where you want to use those resources. I just need it available in a docker, I don't have any VMs. But after running "modprobe i915" in shell and restarting the docker, still no joy. Quote Link to comment
cmannes Posted March 3, 2021 Share Posted March 3, 2021 Did the 6.9 update. Started my shares. They seem fine. Docker won't start though, and in the System Log I see.. Mar 2 18:06:30 Cube emhttpd: shcmd (323): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 30 Mar 2 18:06:32 Cube kernel: BTRFS: device fsid 405485a6-6ae3-4031-affd-458b900c4624 devid 1 transid 1037304 /dev/loop2 scanned by mount (15723) Mar 2 18:06:32 Cube kernel: BTRFS info (device loop2): enabling free space tree Mar 2 18:06:32 Cube kernel: BTRFS info (device loop2): using free space tree Mar 2 18:06:32 Cube kernel: BTRFS info (device loop2): has skinny extents Mar 2 18:06:32 Cube kernel: BTRFS info (device loop2): bdev /dev/loop2 errs: wr 91, rd 0, flush 0, corrupt 0, gen 0 Mar 2 18:06:33 Cube kernel: BTRFS info (device loop2): enabling ssd optimizations Mar 2 18:06:33 Cube kernel: BTRFS info (device loop2): creating free space tree Mar 2 18:06:33 Cube kernel: BTRFS critical (device loop2): corrupt leaf: block=11351392256 slot=16 extent bytenr=492818432 len=4096 invalid data ref offset, have 4294936711 expect aligned to 4096 Mar 2 18:06:33 Cube kernel: BTRFS error (device loop2): block=11351392256 read time tree block corruption detected Mar 2 18:06:33 Cube kernel: BTRFS critical (device loop2): corrupt leaf: block=11351392256 slot=16 extent bytenr=492818432 len=4096 invalid data ref offset, have 4294936711 expect aligned to 4096 Mar 2 18:06:33 Cube kernel: BTRFS error (device loop2): block=11351392256 read time tree block corruption detected Mar 2 18:06:33 Cube kernel: BTRFS critical (device loop2): corrupt leaf: block=11351392256 slot=16 extent bytenr=492818432 len=4096 invalid data ref offset, have 4294936711 expect aligned to 4096 Mar 2 18:06:33 Cube kernel: BTRFS error (device loop2): block=11351392256 read time tree block corruption detected Mar 2 18:06:33 Cube kernel: BTRFS: error (device loop2) in btrfs_create_free_space_tree:1189: errno=-5 IO failure Mar 2 18:06:33 Cube kernel: BTRFS warning (device loop2): failed to create free space tree: -5 Mar 2 18:06:33 Cube kernel: BTRFS error (device loop2): commit super ret -30 Mar 2 18:06:33 Cube root: mount: /var/lib/docker: can't read superblock on /dev/loop2. Mar 2 18:06:33 Cube kernel: BTRFS error (device loop2): open_ctree failed Mar 2 18:06:33 Cube root: mount error Mar 2 18:06:33 Cube emhttpd: shcmd (323): exit status: 1 Mar 2 18:06:33 Cube emhttpd: shcmd (336): /usr/local/sbin/mount_image '/mnt/user/system/libvirt/libvirt.img' /etc/libvirt 1 So it's looking like my docker.img got a wee bit horked. I'm doing my due-diligence of googling for ideas on how to fix. Quote Link to comment
cmannes Posted March 3, 2021 Share Posted March 3, 2021 Read a lot about how to handle btrfs errors. And btrfs check --repair docker.img appears to have done the magic. My dockers all started correctly now, and appear to be working as expected. I'm going to assume user error. I probably should have stopped all my dockers before running the 6.9 update. (Which of course occurred to me shortly after clicking the button.) Quote Link to comment
John_M Posted March 3, 2021 Share Posted March 3, 2021 1 hour ago, Rick Gillyon said: Add it to the go file or i915.conf? Neither. Once you've run touch /boot/config/modprobe.d/i915.conf to override the blacklisting, the module will be loaded each time you boot so you don't need to modprobe it. If you type ls /dev the output should include the dri directory. If it does and your docker container still can't make use of it, then the permissions on the /dev/dri directory and its contents are probably incorrect, depending on how the container is configured. 1 Quote Link to comment
ross232 Posted March 3, 2021 Share Posted March 3, 2021 (edited) Upgraded from 6.9.0 rc-2. Disks won't spin down for me now. It's weird because one of the disks has nothing on it but I'm periodically seeing reads/writes to it. EDIT: Disabling the TurboWrite plugin prevents this problem. I'm not sure why it worked ok in RC2 but now now. Edited March 3, 2021 by Ross Cannizzaro Quote Link to comment
muwahhid Posted March 3, 2021 Share Posted March 3, 2021 (edited) Question about docker image. My cache disk was formatted in XFS, and the image itself was in BTRFS. Now I tried the option when it's just in folders. And it now takes up twice as much space as the image of the BTRFS. Are there any other disadvantages to this option? Except that it just takes up more space. (this is a minus, but NOT sensitive for me). By the number of records, it can be seen that this option makes fewer rewrites, and this is good news. But what about performance and any other disadvantages? Can you tell me? Edited March 3, 2021 by muwahhid Quote Link to comment
Alexandro Posted March 3, 2021 Share Posted March 3, 2021 Smooth update to 6.9.0 from 6.8.3. All dockers/VMs started as expected. All my disks reported "back to normal utilization levels" message. Thank you. Quote Link to comment
Zonediver Posted March 3, 2021 Share Posted March 3, 2021 Updated from 6.8.3 and almost everything works - except for sleep. If the sleep plug-in is active, you have to enter all drives under "Monitor disks outside array:" - that is exactly the other way around. If you don't do that, v6.9 does not recognize the disks as active and puts the server into sleep. Otherwise everything works so far - well done Limetech - i am happy with the new release 👍👍👍 Quote Link to comment
TechGeek01 Posted March 3, 2021 Share Posted March 3, 2021 Updated from rc2, and after rebooting, I get the following on boot at the console, right before the login prompt main: line 96: ( / 1000 ): syntax error: operand expected (error token is "/ 1000 )") modprobe: FATAL: Module nvidia not found in directory /lib/modules/5.10.19-Unraid My initial thought was that this pertained to the Nvidia Driver plugin, but that was on the latest version before the upgrade. Only thing that changed is from rc2 to 6.9 stable. Googling for that error returns no relevant results, so I'm at a loss here. As a result, Plex Docker won't start. GPU is visible in system devices, and not bound to VFIO, but the Nvidia Driver plugin doesn't see the card, presumably as a result of the above boot errors. Server boots fine, and everything barring the GPU works fine without halting boot, but I'm at a loss here. helium-diagnostics-20210303-0224.zip Quote Link to comment
SimonF Posted March 3, 2021 Share Posted March 3, 2021 The Nvidia package is also dependent on kernel, it sounds like you cannot download the newer version for the 6.9.0 kernel. Have you tried removing the plugin and re-installing? Quote Link to comment
Anym001 Posted March 3, 2021 Share Posted March 3, 2021 10 hours ago, italeffect said: I have all these IPV6 "Multicast" entries after the upgrade to 6.9. I have IPV6 turned off. Am I safe to delete them all? I also have these ipv6 multicast records after the update. Can I delete them? Otherwise I have been able to update from RC2 to 6.9 without any problems. Quote Link to comment
TechGeek01 Posted March 3, 2021 Share Posted March 3, 2021 1 hour ago, SimonF said: The Nvidia package is also dependent on kernel, it sounds like you cannot download the newer version for the 6.9.0 kernel. Have you tried removing the plugin and re-installing? I have not yet, but that will be my next project once it's not 4AM. I will definitely post back with results when I do though! Quote Link to comment
Squid Posted March 3, 2021 Share Posted March 3, 2021 4 hours ago, muwahhid said: And it now takes up twice as much space as the image of the BTRFS. Doesn't for me. The "du" of /var/lib/docker under both an image and as a folder are roughly the same Quote Link to comment
Capt.Insano Posted March 3, 2021 Share Posted March 3, 2021 10 hours ago, John_M said: Neither. Once you've run touch /boot/config/modprobe.d/i915.conf to override the blacklisting, the module will be loaded each time you boot so you don't need to modprobe it. If you type ls /dev the output should include the dri directory. If it does and your docker container still can't make use of it, then the permissions on the /dev/dri directory and its contents are probably incorrect, depending on how the container is configured. I imagine this may be an issue for others so posting my experience here: After upgrade from 6.8.3 (all smooth), I removed the following from my go file: modprobe i915 chmod -R 777 /dev/dri I then created the blacklist override as per release notes and rebooted: touch /boot/config/modprobe.d/i915.conf This correctly loads the i915 module: [email protected]:~# ls /dev/dri by-path/ card0 renderD128 However the permissions seem to be an issue: [email protected]:~# ls -la /dev/dri total 0 drwxr-xr-x 3 root root 100 Mar 3 11:57 ./ drwxr-xr-x 16 root root 4320 Mar 3 12:02 ../ drwxr-xr-x 2 root root 80 Mar 3 11:57 by-path/ crw-rw---- 1 root video 226, 0 Mar 3 11:57 card0 crw-rw---- 1 root video 226, 128 Mar 3 11:57 renderD128 Emby will not use hardware transcoding unless I also issue the following command and then restart the container: chmod -R 777 /dev/dri As such I have added that command back into my go file. Is this the correct action to take or is there something else that sould be done regarding the permissions of /dev/dri for container usage? Congrats @limetech & team for another great release. 3 2 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.