pgbtech

Hi everyone. I have a weird problem with this plugin. I’ll receive notifications that many containers have been updated. Shortly thereafter I receive a notification from the Fix Common Problems plugin that those same containers need updated. Then if I bring up the dashboard none of the containers were actually updated. The plug-in is definitely running as I see that many of the containers were restarted. If I manually updated each one via the dashboard they update without a problem. Any idea what could be happening?

Yes, turn everything in the DevTools plugin on. Probably not all are needed, but doesn’t hurt anything to have them installed.

Glad it worked out for you!

I followed a bunch of different guides, but am terrible about documenting. I do have my bash history, so I'll put that below and try and explain. I installed all of the dev-tools plugin options and any other missing dependencies should be in the NerdTools plugin. The only one I manually installed below is bison. You may have to update the linux kernel version in the commands if you aren't on 6.8.3 (kernel 4.19.107) and then the bison package if you aren't on amd64 (note I did have to use the version of bison shown below, the newest version did not work). Worth noting that some of the make commands in there might be unnecessary (again, sorry for my shitty documentation). If you have the apex and gasket modules reporting in the 'lsmod' command, you should be go to go. To fully verify, just check and see if you have the /dev/apex_0 device showing up. First, grab the source from google: mkdir /root/apex/ wget https://coral.googlesource.com/linux-imx/+archive/refs/heads/dkms/drivers/staging/gasket.tar.gz tar zxvf gasket.tar.gz With the source extracted to /root/apex/, my bash_history mess is below: 302 uname -a 303 mkdir packages 304 cd packages/ 305 wget https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.19.107.tar.gz 306 ls 307 mv linux-4.19.107.tar.gz linux-4.19.107.tgz 310 cd /usr/src/ 311 mv linux-4.19.107-Unraid/ linux-4.19.107-Unraid_orig 313 tar zxvf ~/packages/linux-4.19.107.tgz 314 ln -s linux-4.19.107 linux 315 cp -rf linux-4.19.107-Unraid_orig/* linux 316 cp -f linux-4.19.107-Unraid_orig/.config linux 317 ln -sf /usr/src/linux/include/asm-generic /usr/include/asm-generic 319 ln -sf /usr/src/linux/arch/x86/include/asm /usr/include/asm 320 ln -sf /usr/src/linux/include/linux /usr/include/linux 331 cd /root/ 361 wget http://slackware.cs.utah.edu/pub/slackware/slackware64-14.2/slackware64/d/bison-3.0.4-x86_64-1.txz 362 installpkg bison-3.0.4-x86_64-1.txz 377 cd /usr/src/linux 380 make modules_prepare 381 make modules_prepare M=/root/apex/ 382 export CONFIG_STAGING_APEX_DRIVER=m 383 export CONFIG_STAGING_GASKET_FRAMEWORK=m 384 make M=/root/apex/ 394 insmod gasket.ko 397 insmod apex.ko 398 lsmod|grep apex 402 mkdir /boot/config/drivers 405 cp /root/apex/gasket.ko /boot/config/drivers/ 406 cp /root/apex/apex.ko /boot/config/drivers/ To get it loaded on boot, I just added the below to my /boot/config/go file: insmod /boot/config/drivers/gasket.ko insmod /boot/config/drivers/apex.ko I'm sure there are better, more proper ways to get these drivers loaded, but I didn't really want to compile my own entire kernel to do it. With 6.9, I know they're planning to make driver loading easier via an overlayfs, but I'm not running that OS yet to try it out. If you're running v6.8.3 on a 64-bit system, I can send you the drivers to make it super simple for you.

Not sure if anyone is still interested, but I have the Coral mini PCIE card working in the frigate docker. I had to compile the gasket and apex drivers. It’s far from elegant but I was able to run an insmod on boot in order to load the drivers. So far, so good.

@DZMM Thanks for the assist! I should have known the plugin could accommodate my thoughts. Once my initial copy upload job finishes, I’ll switch to move with a 30d MinimumAge.

I love the idea of this plugin and the simplicity to get it all setup and running smoothly. I greatly appreciate the work that has gone into it! One quick question: I have the upload script copying (vs moving) my libraries to a team share now. If I want to give the remote drive playback a trial, could I just delete a sample file from the /mnt/user/local/gcrypt folder? This should leave the file in the mergefs and then playback would occur via the team drive, right? I am thinking of writing a simple age-off script where files older than 30 days are removed locally (via /mnt/user/local), then living only in the team share. Thanks again!