Mainfrezzer

Es sollte, je nachdem wie die Wetterlage ist und der Stand der Sterne, im Basissystem landen, halt das klassische "soon™". Also ein Kopf machen muss man sich da nicht.

Unraid doesn't even have it in the Kernel.

The container updates itself upon restart. Anybody got that email. If you need to rely on container being updated instead of it doing it upon getting started, cloudflare has its own image which is static.

Should be sorted already, since the 9th of october. Although, as i said in the other topic, i was a bit late with the release of the update as i didnt check 7.3.3 branch. I only checked 7.4 and the rc.1 version still had version 3.5.0 with the bs error and i didnt catch that until i manually updated to 3.5.1 and actually rebooted

Eli stole the header fade once again.

Yes, ich777 usually compiles them and his status is mentioned a few post above. Although it should have auto compiled just fine and pushed for 6.18.58, as I didnt see an issue with it. But who knows what happened, ich777 had an issue opened for 6.18.55 on the main repo about it. 🤷‍♂️

here you got the package for 6.18.58. I did compile it on 7.3.4, dont know if it plays fine with the 7.4 branch. It does play fine with 7.4 rc.2 plop the txz and md5 in the subfolder of the plugin (i.e. "/boot/config/plugins/i915-sriov/packages/6.18.58"), put the plg in the main plugin folder and reboot https://clips.magnon.ovh/vUwo7/fETiyaMu80.zip or the full folder here as the plugin obviously nukes itself upon failures https://clips.magnon.ovh/vUwo7/kUSOMUvI56.zip keep in mind, my config inside has "vfnumber=0" set. then just move your plg from the error folder back to plugins and reboot Edit: Apparently the clips page has some issues, welp heres an alternative server, so i hope to god you can connect to ovh https://magnon.ovh/share/-I8JOluR

Oct 22 17:57:38 NASSRV rc.docker: connecting MakeMKV to network bridge Well well well. It hosts some files, noteably some sdf.dat.gz file. which is supposedly some hashfile key. Its noted in some ancient posts and even in a newer one. Whois IP 185.84.108.20 - www.makemkv.com But would have taken only a bit of searching to find that out

Soooo, did we dabble with makemkv?

Did you update the plugin post array start? It only runs the script on array starts. Edit: Checked your diags, yeah you had your array running before you downloaded the newest version. It doesnt change any code in the rc.docker until the array is stopped and then started again, which at that point would have messed up anyway since the wrong / old rsync command was executed. But given that you loaded up this time with the correct --insecure-links version, it is good

The Pelican Panel rc.1 got rebuild. I dont know if they will publish a rc.2 version later or just rebuild as well. if they publish a new version, depending when they do, it might come later today or tomorrow morning CEST. The other container i build with php will be rebuild when the packages are available in the alpine repo, as i dont fancy building my own packages again (like openresolv)

Sorry, that one is on me. Only got around to power cycle for the release to check today. didnt have it on the radar that it might be an issue as its owned by root but the /mnt/ folders are nobody :/

Want to note something for the new version, as it will probably pop up at some point, in regards for the new force sync feature. It appears that with some rather "recent" docker version, some of the exessive writing of certain files has stopped. I have not checked with what docker version exactly but if youre on something old (i.e. like maybe unraid 6.12.x), turning on the force sync might probably still increase writing to the disks. I did check my other servers, which are all on docker engine 29 series and they do seem to not write excessively anymore for anything with healthchecks, apart from the log itself which is, as stated, excluded. I think you will be delighted that its sorted

Just in case somebody else runs into the issue, as i just got informed about. I do publish the pelican images on dockerhub as well. So in case github is being classic github again and wont work for updates, pelican is also available under mainfrezzer/pelican-panel:latest and mainfrezzer/pelican-wing:latest respectively Edit: Alternatively you can install this PR fix, https://preview.dl.unraid.net/pr-plugins/pr-2725/webgui-pr-2725.plg , then unraid should behave as expected with all github repos again

No there isnt a need to change it. It might make sense if you care about write amplification and you have a lot of container that write tiny changes within their non-mapped paths but the chances are slim for that (i hope so at least).