pluginCop

I've reviewed this thread, and there's nothing per se that warrants any further moderation / comments on this plugin AT THIS TIME. The error message on the screen during boot is a minor display aberration and completely harmless Array Not able to Stop -> this is a big deal, but a single instance reported doesn't justify any action being taken. Server not turning off displaying "Turning Off Swap". While uninstalling the plugin may have fixed the issue for you, it is hard to properly diagnose this as I also have a server which doesn't run any VMs and also has this same issue.

Now deprecating this plugin if the user is running 6.7.0+

It still mostly works, hence why it's still available within CA. But, there are already notes on it within CA suggesting to instead use Disk Location which is actively maintained.

Because of the monster nature of this particular thread, it's rather hard to gather what exactly is happening. Is it fair to say that Dynamix S3 Sleep is for all intents and purposes non-functional (and has been since 2018)? In looking through the code change that was posted earlier, it would appear that the routine that is determining whether or not the drive(s) are idle is completely broken? Right / Wrong? Is there still a usage case for this plugin putting your server to sleep even if the drive(s) are still active?

This^^^ because the feedback from SMART would be an overlap from the built-in SMART monitoring unless the plugin is doing something else. The amount of writes varies quite wildly. If I set up the plugin with all my drives (24), if they are all spinning, then there is ~300 writes per hour (2.6M / year) according to the dashboard. If they're all spun down, that drops to ~20/hr (under my test it would have been ~64,000 over the 9 days)

Hey @olehj What exactly is being written to the SQLite db every hour? Considering that the db is being stored on the flash drive, is it really necessary to update it every hour if nothing changes in the setup of the server?

Thanks. Comment removed

Just going to add a moderator comment to this advising people to not upgrade any installed versions. I'll try and watch this thread for when this is resolved.

Just an FYI, CA's application feed is getting stricter on plugins. The template for CA for this plugin references one URL which does not match the URL referenced within the plugin itself. This is a security issue because if / when the plugin updates, effectively a different plugin winds up getting installed from the one CA has listed (even though in this case they are identical, but due to the differing URLs they effectively are different plugins). Because of this the application feed is automatically blacklisting Corsair PSU until either the template or the plugin are fixed to point to the same URL If the GitHub repository simply changed where the plugin is stored, then the solution is to change the template to that new repository Fma965's Repository https://raw.githubusercontent.com/Fma965/corsairpsu-unraid/master/corsairpsu.plg: Fatal: Plugin URL on xml template does not match PluginURL in .plg (https://raw.githubusercontent.com/Fma965/corsairpsu-unraid/master/corsairpsu.plg vs https://raw.githubusercontent.com/Cyanlabs/corsairpsu-unraid/master/corsairpsu.plg)

@dorgan, why not mirror the vnstat package in your own git repository, so you're not dependent upon whether it's present or not (or updated) in the slack repo.

Polite little bump - I'm sure you just forgot about this. # Generated file integrity check schedule: 10 0 * * * /boot/config/plugins/dynamix.file.integrity/integrity-check.sh &> /dev/null

Confirmed. Will however give @gfjardim time to fix this before any additional action is taken.

There is definitely no virus contained within either Unassigned Devices or Unassigned Devices Plus.

Would you like me to notify everyone with UD and FCP installed about this? Should *hopefully* lessen the massive influx of support posts that will happen

Not going to mark this as being incompatible with 6.8, but will put a comment on the app linking to the command. Hopefully someone will post if / when the plugin has been updated to work out of the box.

Then i misinterpreted when you said

AFAIK, there are no compatibility issues with the plugin and 6.7.x Rather it's that not all combinations of hardware (due to a variety of factors, most outside of @bonienl's control) will work properly. The apps tab does have a note on this plugin (and a few others) specifying this. If there is an actual compatibility issue with 6.7.x, then let me know

The issue isn't that the plugin doesn't work (it does). The issue is that newer chipsets don't have the drivers included the kernel (in which case you bug Intel / AMD to do that) or that the sensors / sensors-detect scripts themselves have been abandoned (years ago actually). There are a number of work-arounds if you google things. EG: On one of my older AMD boards I had to do this in the "go" file modprobe it87 force_id=0x8686 as the it87 module was included in the kernel, but it didn't recognize the chipset id that my board was giving it. While I do understand your frustration with this, these issues are outside of the author's control. But, I will add a note to the app stating that it does not work with all hardware combinations.

Reinstated back into CA

Marking this plugin as being incompatible with unRaid 6.7+ as @Mettbrot hasn't been online for awhile, and it hasn't been updated to actually be compatible with 6.6 (all those warnings are hidden on 6.6). Probably better off using the docker app instead.

This plugin has now been marked as being incompatible with unRaid 6.7.0+ until such time as it is updated to support the updated libaries.

Note: When unRaid is in RC stages, then I cut the plugin authors a lot of slack and don't worry excessively about compatibility of Plugins before I mark them as incompatible, unless there are extenuating circumstances.