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.

Upgrade to 6.9.0 from 6.8.3 without issues so far.  Keep up the great work!

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!!

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, 20215 yr by AgentXXL
Updated info on persisting capacity threshold error

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, 20215 yr by 5STAR

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).

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!

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 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?

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.

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, 20215 yr by jpowell8672

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.

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.  

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.)

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.

 

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, 20215 yr by Ross Cannizzaro

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, 20215 yr by muwahhid

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.

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 👍👍👍

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

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?

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. 

 

 

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!

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

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:

root@Tower:~# ls /dev/dri
by-path/  card0  renderD128

 

However the permissions seem to be an issue: 

root@Tower:~# 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.