cybrnook

I world recommend updating the default kernel path from /mnt/cache to /mnt/user, now that we have multiple pools. I run my appdata now on a drive other than cache.

Of course, that is expected. What I was thinking to see though, is assuming I left all default values, then only change to Nvidia (BETA now) and latest DVB, then the outcome would be the same (or close). I am sure it's not an issue, as it seems to work fine. I was just pondering why sizing was different if all else was same :-).

No worries, just wanted to make sure something wasn't going as expected. 🙂 Compiling now, will report back.

Yep, that may very well be it. I will try by modifying the Nvidia driver version to the specific version vs "latest" 🙂

@ich777 Is it expected that the sizes of the re-compiled files vary slightly in size? What I mean is I am using this to compile latest 6.9.0 beta 24 for Nvidia and DVB, using the defaults of latest and latest with beta enabled. The compilation seems to go smooth and without issue. But, if I download your pre-compiled beta 24 with nvidia and dvb and look at the file sizes compared to mine, they are slightly different. Does the fact that my architecture is an AMD system make a difference?

As suspected 🙂 Only thing that would throw me off a little, I am preloading the modified kernel before I am installing my Hauppauge card as well as my Nvidia GPU, that will come this afternoon. But the wording on the page makes me think that the driver isn't loading properly. I can only assume this message is appearing because I don't yet have the GPU installed. Perhaps it should say something like "Make sure that the latest NVIDIA driver is installed and running and your GPU is properly installed and detected"?

Absolutely great Plugin and Docker, truly thank you. Just wanted to report one small, superficial visual anomaly. I run a widescreen, high res monitor and I notice the separation bar on the plugin helper screen breaks in the middle. I use Chromium Edge:

@spants just wanted to call out a small typo in the CA Info notice for this template. "make sure that you fixe the unRaid servers dns to point to a real DNS Server." Should probably be something like: "make sure that you have fixed your unRaid servers dns to point to a real DNS Server other than your PiHole."

Hello community, This is more just a lessons learned (for myself) vs an ask for help, but I have been going back and forth over the past couple weeks on why CA Auto Update has just not been updating anything. I have unraid set to not check for plugin/docker updates, as I am using CA Auto Udpate to do a daily check, then auto update after 1 days time. Been working fine as far as I can remember. Recently I have been playing around with my network, went 10Gbe, bonded (Active/Passive) setup, I have dual wan at home over pfsense though it's also in an active/passive setup and not load balanced so I only ever have one default gateway and I do have it set to clear my state table on failover. I don't run any adblocking or anything. I use my firewall as my assigned DNS server through both static and dynamic IP hand out's (unless you are on a VLAN and then I assign you two addresses) and I handle all this at the router end (though I still set unraid to a static IP internally in unraid just as a fall back). So, long story short now that you know my setup, I was playing around with blocking UDP 53 on all clients except on local wan, and had that going for a few days. Then I went a few days and noticed that neither my plugins or dockers were showing any updates, which I though was weird. Especially since I run Binhex's jackett build and that thing can get 3 x updates in a day sometimes. So I started trying to manually check for updates, and since I have autocheck disabled in unraid I have the manual "check for updates" button on both plugins and dockers. I would click it, and could see the check randomly fail throughout the check. Sometimes after one plug in, sometimes after 4, 5 etc.. but kept failing. So I thought it was UDP 53 somehow interfering, so I disabled the rule and still saw the same behavior. UNTIL I remembered that I also changed from Cloud Flare DNS servers (1.1.1.2, 1.0.0.2) to Quad9's at the same time (9.9.9.9, 149.112.112.112). So, changing to anything other than Quad9, I am getting consistent update checks, no failures, and all works. I tested with Google DNS, Cloud Flare, and OpenDNS, all worked, Quad9 would fail. So I am not sure if Quad9 is detecting the rapid hits as malicious, or something about how unraid checks for updates maybe ended up on one of Quad9's black lists. But just wanted to share. I can only assume I am the only one being able to repeatedly see this, and most others will say non-issue, but wanted to share anyways. 🙂 EDIT: Oh yeah, I DO use DoT if that changes anything.

Community Applications Think of it as the app store for unraid. It'll help you install plugins and Dockers with minimal input from your side. It automates the manual parts for you.

Riddle me this...... I have been tracing a little Gremlin that I finally figured out this morning. I run about 15 or so plugins, and I use CA Auto Update plugin to do nightly checks for plugins and dockers. It's been working for a while now, until recently I noticed that update checks were hanging, not completing all the way. If I ran a manual check, I could see it make it to 3 or 4 plugins, then hang. Try again, and it makes it through 6 or so. Try it again it completes. Try it again, hangs after two. Has been driving me bonkers. I was thinking github was down or something. Things I tried: - Change Unraid DNS settings from gateway to 8.8.8.8 / 8.8.4.4 | no change - Disabled notifications -> check for update for plugins / dockers, let auto update do it's thing | no change - Assign manually 8.8.8.8 / 8.8.4.4 to unraid in pfsense | no change - Pull one of the two cables in my active/backup bond | no change - reboot pfsense | no change - reboot unifi switches | no change - reboot unraid | no change UNTIL!!! I had that ah-ha moment. I logged in via ssh, and cat'd out the hosts file and resolv.conf. Hosts file had your standard entries, local host for unraid and a hard coded ip for unraid keys server. Then resolv.conf had whatever I was pushing, when I set unraid to use google, it had google. When I pushed gateway as dns, then it was 192.168.1.1, again all good. So I tried pinging google.com from os, nothing...... tried pinging github.com (since CA FCP was bitching at me), again nothing....... I thought WTF.... So I went into pfSense and remembered that I recently blocked UDP port 53 for anything on my LAN network UNLESS it was from LAN to LAN (https://docs.netgate.com/pfsense/en/latest/dns/blocking-dns-queries-to-external-resolvers.html), meaning : unless you are something on my network trying to resolve UDP 53 against 192.168.1.1, then go pound sand. The moment I disabled the block rule on UDP 53 it all came back to life. So my question is, if I have unraid set to use 192.168.1.1 as it's DNS server, why is it facing issues when I block 53 to external queries? Is Unraid hardcoded in some places to bypass your defined DNS and try and resolve queries on it's own with it's own DNS servers?

Love to hear about the new stub system and integrated Nvidia drivers. Made my day hearing that.

Super cool, watched the first one and enjoyed it. Still have reconstruct write set in my system 🙂 Will tune in!

@limetech @trott This seems to be taken care of in the latest 6.9.0 beta1.

6.8.2 is on an older kernel. We are waiting for the new 5.4+ kernel.

Exactly. I use last pass for example, and it has a companion app called authenticator. With this, I use it for anything 2-FA that offers Google authenticator support, and it all syncs to my profile. So when I get a new phone, just install last pass and all my rolling codes come down. I think these are all pretty universal, it's just the QR codes they want.

@wesman it's in the readme in the op: https://github.com/jlesage/docker-makemkv#access-to-optical-drives

Yuuuup

Thanks for transparency!

I assume that was likely directed towards @itimpi , but, and this is just a straw man, but since today we already have to rename EFI- to EFI in order to set the thumb drive to UEFI boot mode, could the same also not be done in a way to select what menu is invoked during boot? So there is a legacy menu for EFI- and an UEFI menu for EFI?

I think that would be a nice addition, if the boot menu (even if only staying up for 5 seconds) stated whether "Legacy" or "UEFI" boot was called out. A nice belt and suspenders confirmation to users as well in case they were questioning whether it was in fact booting UEFI/Legacy, instead then booting all the way up into unraid and checking the flag there. Easier to CTRL+ALT+DEL in the grub menu and try again. (I see what you mean by the licensing on their page, site license etc...)

New Intel vulnerability found dubbed "Cache Out": https://www.pcworld.com/article/3516302/new-cacheout-attack-targets-intel-processors-with-a-fix-arriving-soon.html Intel Processors affected (Intel CPU Skylake/Cascade Lake onward. Broadwell and earlier are seemingly not affected). AMD seemingly not affected: https://software.intel.com/security-software-guidance/insights/processors-affected-l1d-eviction-sampling No mitigation created yet, so time will tell how it's addressed.

Opened a feature req:

Update the integrated memtest utility to run on UEFI boots. I downloaded the latest free standalone, and that boots fine as a standalone via UEFI: https://www.memtest86.com/download.htm Is there the possibility to roll in the free UEFI compatible version? (Or perhaps remove memtest from the menu if UEFI boot is detected to avoid confusion)

Sure, just wanted to field the community for ideas and input first before shooting right to a feature request.