hive_minded

LSIO Jellyfin docker stops working after ~20-25 seconds and just stops. Attached are logs. Worked fine for 2+ years before this. Not sure what I broke. JellfinLogs.txt

[ 22.933226] i915 0000:00:02.0: [drm] VT-d active for gfx access [ 22.933482] i915 0000:00:02.0: vgaarb: deactivate vga console [ 22.933521] i915 0000:00:02.0: [drm] Using Transparent Hugepages [ 22.934726] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 22.935295] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_component_ops [i915]) [ 22.937682] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/kbl_dmc_ver1_04.bin (v1.4) [ 22.938811] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0 [ 23.002401] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes [ 23.060813] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes [ 23.122299] i915 0000:00:02.0: [drm] Cannot find any crtc or sizes Thoughts? Having trouble with jellyfin I believe this could be why.

Mine looks similar to this, however I am still seeing this.

I get hang ups requiring a forced power down every week or two. 8600 on 6.9.2. Was hoping 6.10.0 would fix it, but waiting until a stable release comes. I suppose I could try and disable the iGPU, but that would mess with Jellyfin transcoding, which isn't ideal.

Did you find a solution to this? I get these same random freezes every few weeks too. My server was stable for the first 4-5 months I had it, but over the last 2-3 months I keep getting these random freezes and I can't figure out what is causing it. I've only ever been on 6.9.2. Considering upgrading to 6.10.0 RC2, but I'm trying to wait it out until a stable version comes out.

Fair enough - and the scrubbing unfortunately did not work. I've had 2 freezes since trying that. I guess I'll to reseat the m2 drives and PCIe card - as well as run a memory test. And then try upgrading to 6.10.0-rc1? Just odd that it worked flawlessly for the first 4-5 months, and the issues just started without any hardware change/distruption. All of the hardware was purchased new - so everything is pretty fresh.

36 hours later and running "btrfs dev stats /mnt/cache" shows 0 errors. I am going to tentatively consider this one solved. Though I will be keeping a close eye on errors in the future, and am willing to try 1 drive xfs cache if btrfs continues to have issues. Right now, everything appears stable though. Thanks again for your help @JorgeB

Ok gotcha, thanks for the responses. I'll keep a close eye on it now to make sure new errors don't pop up.

Running a scrub on my cache drives spits out this: Error summary: verify=54 csum=76277 Corrected: 0 Uncorrectable: 0 Unverified: 0 **edit** Running it again, clicking the 'Repair corrupted blocks' box gives a slightly different result, and it looks like some were corrected Error summary: verify=53 csum=76256 Corrected: 76309 Uncorrectable: 0 Unverified: 0 I tried to run an extended SMART self-test on both of them, but when I click 'START' nothing appears to happen. However both of them say 'PASSED' on the 'SMART overall-health' field at the bottom of the drive information. **edit #2** After forcing a reset of the stats by running "btrfs dev stats -z /mnt/cache", and scrubbing - this is my new output: [/dev/nvme0n1p1].write_io_errs 0 [/dev/nvme0n1p1].read_io_errs 0 [/dev/nvme0n1p1].flush_io_errs 0 [/dev/nvme0n1p1].corruption_errs 0 [/dev/nvme0n1p1].generation_errs 0 [/dev/nvme1n1p1].write_io_errs 0 [/dev/nvme1n1p1].read_io_errs 0 [/dev/nvme1n1p1].flush_io_errs 0 [/dev/nvme1n1p1].corruption_errs 152533 [/dev/nvme1n1p1].generation_errs 107 It appears that the scrub added 107 generation errors. The link you posted mentioned that it can often be related to cables. I actually am not running any cables though - both SSDs are in a QNAP 2x m2 PCIe card. So it looks like either the drive itself may be going bad (which is weird, because its a WD Blue which I think are usually pretty reliable, and its only 6 months old) - or maybe the QNAP PCIe card has something wrong with it?

I don't know that the first thread 100% applies to me - searching through my syslog I don't have any 'kernel panic' errors. Looking through the last few hours the few that caught my (very untrained eye) are Sep 30 04:08:21 alexandria kernel: WARNING: CPU: 7 PID: 0 at net/netfilter/nf_conntrack_core.c:1120 __nf_conntrack_confirm+0x9b/0x1e6 [nf_conntrack] Sep 30 04:08:21 alexandria kernel: cpuidle_enter_state+0x101/0x1c4 Sep 30 04:08:21 alexandria kernel: cpuidle_enter+0x25/0x31 Sep 30 04:08:21 alexandria kernel: do_idle+0x1a6/0x214 Sep 30 04:08:21 alexandria kernel: cpu_startup_entry+0x18/0x1a Sep 30 04:33:53 alexandria kernel: BTRFS error (device nvme0n1p1): bad tree block start, want 1823784960 have 0 I also see a lot of 'netfilter', which the OP in the first thread you linked mentioned. Two of my dockers - Netdata and Tailscale are both set to use 'host' network (the rest of my dockers are using 'bridge'). The link you posted also mentioned that host access could be causing the issues as well. So I will switch both of those to bridge. ------------------------------- Running the command in the second link to check btrfs pools for errors spits out this [/dev/nvme0n1p1].write_io_errs 0 [/dev/nvme0n1p1].read_io_errs 0 [/dev/nvme0n1p1].flush_io_errs 0 [/dev/nvme0n1p1].corruption_errs 0 [/dev/nvme0n1p1].generation_errs 0 [/dev/nvme1n1p1].write_io_errs 161864479 [/dev/nvme1n1p1].read_io_errs 129699470 [/dev/nvme1n1p1].flush_io_errs 2518939 [/dev/nvme1n1p1].corruption_errs 164095 [/dev/nvme1n1p1].generation_errs 0 So it definitely looks like there are a lot of errors. The link says that all values should be 0. I'll run a scrub and an extended SMART test on my cache SSDs.

So I have been running into some unfortunate issues lately. I built my server back in April or so - and up until around a month ago it ran flawlessly, no issues at all. Around a month ago I got my first 'freeze'. Where I am unable to access the server - WebGUI, and docker services running, can't ping, etc. Totally unreachable. But the server is still powered on. It requires a force shut off and on to 'fix'. Around 2 weeks later it happened again. A week after that it happened again. And it's happened twice in the last 5 days now. So it's definitely becoming more regular. After the last time it did this I set up syslog, so I will attach that. I'm really at a loss here (and the most recent freeze happened mid preclearing 2 new HDDs, so that is also a bummer. Any advice would be much appreciated. syslog-192.168.0.000.log

I need some help I completely broke Wireguard. I was having some issues getting it working, especially after switching from Google DDNS to Cloudflare + NPM. Couldn't get anything to work. So I decided to nuke everything and start fresh. I rm -rf'd /etc/wireguard/, deleted the plugin, redownloaded the plugin and then tried to start fresh. However, when I went into VPN settings after nothing would save. Hitting apply would reset everything. After looking around, it looks like re downloading the plugin did not create '/etc/wireguard'. So I mkdir '/etc/wireguard', as well as '/etc/wireguard/wg0.conf' Now I can get a couple things to save, but once I try to 'add peer' it just raises and lowers the tunnel wg0 part, as if Im clicking the down/expand arrow. At this point I decided to delete everything again, and restart the server. When I did that /etc/wireguard/ showed up (was not there when I restarted) and had the old files from the very beginning. Any pointers on how to just 100% reset the Wireguard state. Deleting/restarting is clearly not working, and nothing new I am doing is saving.

I used to have a Wireguard tunnel set up and running, but I was unable to get remote working by using my domain name (only my server IP would work remotely). I was able to use this to access the WebGUI remotely. I recently switched from using Google domain, to using Cloudflare for DNS management. I have been able to get everything set up to where I can now access docker containers like Jellyfin remotely (using Nginx Proxy Manager). I have read that you should not use NPM to access your WebGUI remotely. So I am trying to set up up a Wireguard tunnel again. I can not seem to get it to work properly. Right now I am able to connect to the Tunnel/Peer I set up on my phone. If I try to go to mydomain.com, it directs me to the NPM 'Congratulations' landing page. I want it to work where going to mydomain.com sends me to my Unraid WebGUI. If I try to access my WebGUI by going to 192.xxx.x.xxx it just times out and doesnt take me anywhere. Where am I messing up? I'm not sure if I'm missing something on my router (Unifi), Cloudflare, NPM, or unraid GUI. Any help would be much appreciated. **edit** All of the above was on my Phone, not connected to my LAN. When I connect to my LAN, I am able to access my WebGUI by going to 192.xxx.x.xxx, and if I go to mydomain.com I still get the NPM 'Congratulations' landing page. **edit #2** I was not able to get anything to work at all when selecting 'remote tunnel access'. When I switched to 'Remote access to LAN' that is when I started to be able to access the internet, and the NPM 'Congratulations' landing page.

I just wanted to piggyback off of what some of the other recent comments said. For some reason whenever Unraid.net updates, it bricks the current theme and is impossible to set back without uninstalling/reinstalling.

I had been trying to figure out a way to download specific files from my Seedbox (as opposed to a whole automated system like some of the videos have guides for). I landed on using Firefox to log in to my Seedbox, and download the files from there. The files end up in /mnt/cache/appdata/firefox/Downloads - and from there I can unzip and then move to the proper share. I've been running into an odd problem though. Once every 3-4 downloads, one of them will download 99.9% of the file, but never actually finish. When you initial the download you get 2 files - a .zip and a .zip.part - when the download is completely finished the files merge into one .zip file. But the files that freeze up will finish downloaded essentially, but never merge together so I am able to unzip them. It's not a specific file thing, because sometimes a download won't work, but after removing it and starting the download again it will work the second time. It seems to be more consistent if there is less total downloading. Outside of that I can't really place a pattern though. Any idea why this might be happening? Or some settings I can tweak to increase the likelihood of the downloads finishing?