Jclendineng
Members
-
Joined
-
Last visited
Everything posted by Jclendineng
-
just found out about this, competitors need to hammer on this as a downside of a container system that takes months to fix what seems to be a pretty major issue.
-
Any updates? Ive tried a few things to get QSV working in handbrake (linuxserver docker) but it's not working. Latest unraid. I hear Unraid 7.3 is coming shortly with kernel 6.18 (about time...) which may help Intel compatibility. Edit after banging my head on this handbrake issue for a bit: Set up handbrake per linuxserver doc and start. Go to the console and install the proper packages, by default this for some reason does not have qsv enabled. Install: pacman -S vpl-gpu-rt libvpl --overwrite "/usr/lib/libgcc_s.so*" --overwrite "/usr/lib/libstdc++" --overwrite "/usr/share/licenses/gcc-libs/" Restart the handbrake container and profit.
-
Just so I’m clear, this isn’t intended for GPU stats, mostly iGpu. My a380 worked fine with it but my b50 pro stats aren’t showing up so I should be good to uninstall this?
-
I’m wondering how this calculates sizes, free space, raw and used don’t make any sense. The numbers are wildly off from actually used free and raw. Anyone else notice this? I’m about to stop using the plugin but unraid doesn’t natively give you that info does it?
-
I am on 7.2 but this has been happening the past few releases. All the hang logs when ps -ef 'ed show the one I append a message to below. It doesn't seem to do anything except spam my logs with these messages but figured Id see if anyone else has seen this. I have an Arc A380 LFF GPU that I use for Immich encoding, scrypted decoding and object detection, Plex encoding and that's essentially it. Aug 22 13:18:01 Unraid kernel: i915 0000:03:00.0: [drm] python3[354709] context reset due to GPU hang Aug 22 13:18:01 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [354709] Aug 22 13:17:17 Unraid kernel: i915 0000:03:00.0: [drm] python3[352587] context reset due to GPU hang Aug 22 13:17:17 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [352587] Aug 22 13:15:21 Unraid kernel: i915 0000:03:00.0: [drm] python3[349936] context reset due to GPU hang Aug 22 13:15:21 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [349936] Aug 22 13:10:36 Unraid kernel: i915 0000:03:00.0: [drm] python3[338640] context reset due to GPU hang Aug 22 13:10:36 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [338640] Aug 22 13:06:35 Unraid kernel: i915 0000:03:00.0: [drm] python3[335984] context reset due to GPU hang Aug 22 13:06:35 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [335984] Aug 22 13:00:50 Unraid kernel: i915 0000:03:00.0: [drm] python3[98984] context reset due to GPU hang Aug 22 13:00:50 Unraid kernel: i915 0000:03:00.0: [drm] GPU HANG: ecode 12:10:f1de2ffd, in python3 [98984] Here is a list of running Python processes: oot 374893 374856 0 Sep08 ? 00:01:14 /usr/bin/python3 /usr/bin/supervisord -n -c /etc/supervisord.conf nobody 1105262 1104575 0 07:55 ? 00:00:00 python3 -m immich_ml nobody 1105306 1105262 0 07:55 ? 00:00:02 python -m gunicorn immich_ml.main:app -k immich_ml.config.CustomUvicornWorker -c /app/immich/machine-learning/immich_ml/gunicorn_conf.py -b 0.0.0.0:3003 -w 1 -t 120 --log-config-json /app/immich/machine-learning/immich_ml/log_conf.json --keep-alive 2 --graceful-timeout 10 nobody 1105315 1105306 0 07:55 ? 00:00:31 python -m gunicorn immich_ml.main:app -k immich_ml.config.CustomUvicornWorker -c /app/immich/machine-learning/immich_ml/gunicorn_conf.py -b 0.0.0.0:3003 -w 1 -t 120 --log-config-json /app/immich/machine-learning/immich_ml/log_conf.json --keep-alive 2 --graceful-timeout 10 root 1521684 1520200 0 Sep15 ? 00:02:48 /usr/bin/python3 /usr/bin/fail2ban-client -x -f start root 1559896 1558292 0 Sep15 ? 00:02:45 /usr/bin/python3 /usr/bin/fail2ban-client -x -f start root 1561447 1560160 0 Sep15 ? 00:02:44 /usr/bin/python3 /usr/bin/fail2ban-client -x -f start root 1563652 1562319 0 Sep15 ? 00:02:44 /usr/bin/python3 /usr/bin/fail2ban-client -x -f start root 1707389 45605 0 15:35 ? 00:00:12 /usr/bin/python3.9 -u /server/node_modules/@scrypted/server/python/plugin_remote.py @scrypted/tensorflow-lite root 1707512 45605 0 15:35 ? 00:00:24 /usr/bin/python3 -u /server/node_modules/@scrypted/server/python/plugin_remote.py @scrypted/ncnn root 1712923 45605 9 15:39 ? 00:20:07 /usr/bin/python3 -u /server/node_modules/@scrypted/server/python/plugin_remote.py @scrypted/openvino root 1712964 1712923 0 15:39 ? 00:00:00 /usr/bin/python3 -c from multiprocessing.resource_tracker import main;main(11) - THIS IS THE PROCESS LAST LISTED IN THE LOG unraid-diagnostics-20250917-1919.zip
-
FYI Just on a whim I downloaded Windows 11 Dev Build 26120 using UUPDump and created an autounattend.xml for it and it works, so the issue appears to have been Microsoft being Microsoft and breaking stuff in stable again, so kinda like every patch Tuesday.
-
FYI Windows 11 VM creation still 100% broken by default in latest version.
-
Unfortunately this makes the VM dog slow. Looking for a better solution, but it takes 10x longer to install than previous versions.
-
FYI I took what you posted and ran some tests, I don't know about pass thru (I dint use that) but for the UNSUPPORTED_PROCESSOR BSOD on initial install, you only need to add 1 feature under topoext: <feature policy='require' name='topoext'/> <feature policy='disable' name='arch-capabilities'/>
-
Dang I have been dealing with this for AGES. Thanks! I'll need to bake the hypervisor settings into my AutoInstall windows 11 ISO. Edit: If you use an autounattend.xml you need to add this to the system context, before first login: $ConfirmPreference = 'None' Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All -NoRestart $ConfirmPreference = 'High' It should do an automatic restart anyways for the other autounattend.
-
Small request, would it be possible for the pool size to match the actual "useable" size vs the entire size + zfs overhead? If I have a 200TB pool, zfs master reports around 200TB vs the 120 or so with the parity + overhead. I don't know if this is possible but it would make it really handy for setting quotas, so we can see exactly how much we have without pulling out a calculator every time. :) The dataset size seems decently accurate, so I usually just add up all used space from each dataset then subtract that from the useable space from zfs pool info then calculate out how big to make my quotas.
-
Ok, crashed again. I’m starting by removing my intel arc GPU and will try and crash it again, then I’ll remove a ram stick. Edit. Crashed without the Arc card, I then removed a ram stick and crash, replaced the other one and still crashed. I’m disabling PBO and all core boost in BIOS to see if the CPU is going bad. Edit. After disabling all CPU boosts in BIOS I transferred about 1TB of data from multiple sources to the disks, along side running a couple VMs. No crash as of this morning, I’ll hammer it today and try and get it to lock up, if that “fixes” it, it means I have a bad 7950x which isn’t unheard of.
-
I’ll try that next time it hangs. I moved 500gb between drives to try and trigger it, and started a drive replacement to see what the process was and no lockups in about a day. It’s so strange it happened maybe 10 times yesterday. I replaced my PSU with a higher wattage one in case that was the culprit, no dice. I just can’t get it to be consistent. Checked slack logs as well and everything is hunky dory, just will randomly lock up and require a hard reset. Edit. After the drive finishes importing and silvering I’ll hop into the gui and fiddle with it to try and trigger.
-
Another thing, I was thinking my HBA may be overheating but I have great airflow so that’s unlikely. I can go a while without a lock up or I can go 5 minutes. If I’m working in the UI for a bit and copying a file between disks for example it will lock up in about a minute, but if I’m just leaving the server alone and am not using it, it seems to be fine.
-
I know this must be hardware but polling the crowd. I have been getting hard lockups since 7.0, where the monitor presents the login/terminal, but it's locked so can't type anything and I lose access to the GUI. I have to reset the server to get it to come back. BIOS is fully up to date, Ive tested with C-States disabled I wiped my USB and did a clean install with no plugins, same behavior I did a full round of MEMTESTS with no errors found CPU is not overheating, its hovering around 60 degrees on the high end which is fine for Ryzen No logs, it locks up without any logging, nothing out of the ordinary Any ideas? I feel like Ive exhausted all my options besides replacing RAM just in case, or potentially a CPU issue, but Id expect logs if that were the case. Also, I don't think the USB would go bad without errors, would it be possible for this to happen if the USB was going bad? I have a Ryzen 7950X with 2x32GB DDR5 RAM. Edit: This was resolved by going into BIOS and disabling PBO and all Core Boost options, indicating a CPU hardware issue. I have emailed AMD to see if they will RMA it. unraid-diagnostics-20250609-2139.zip
-
came because I started having hangs as of 7 as well, 7950x, did some memtests and all seems fine but I know its most likely hardware since it just hangs, leaving no logs. I enable copy to usb but the logs show nothing out of the ordinary, just stops responding. Weird that it started after 7 though. It will just hang up, no logs, requiring a reset.
-
Giving this a try - looks interesting, it gives basic control (it's in the name?!) Would be nice to have per VM/Docker container logs. I also can't see total disk usage and it doesn't show pools, though that may be coming with unraid V7? This looks like a great start though!
-
Maybe I am missing something but I can only add an ISO drive and a VIRTIO drive, I need to be able to use more boot drives for an autounattend ISO. Im trying to edit the XML to add another bus with a drive, anyone else know how I would go about adding more boot devices?
-
Just a post for anyone investigating poor network performance, I didn't see this in the VM FAQ. It is imperative to isolate the cores for the VM along side pinning. Make sure you have enough cores for the speed you are looking for, pin and isolate. I had cores pinned but could not figure out why the performance was so bad, I was getting around 1.3gbps to Unraid, and to another VM on the same network. After isolating the cores I pinned, I am now getting full line speed (40gbps) to Unraid, and other VMs on the same VLAN. This is just an FYI since I did a lot of searching and didn't see anyone talking about the need for isolating as well as pinning.
-
same issue here, windows sucks bigly so might just be driver issues. Id test with a unix system and see if you see improvements, im like 99% sure the slowness in VM is all windows being stupid. Edit: Yes I set up iPerf on Unraid host, test from Windows 11 VM, 1.5gbps. I set up another iPerf instance on the same network the VM is on and tested between them, Im bonding so I get 40gbps 1 way and 35gbps the other so its not a network issue, its a VM issue. Edit2: I fixed it by isolating CPU cores for the VM. Getting full 40gbps to any host via iPerf. Interesting that isolating cores was the solution.
-
Same issue but with Firefox running for some reason. I have a ProArt B650-CREATOR and certain apps will crash the VM and Unraid will restart. No logs in unpaid prior to restart and no logs in Windows event viewer prior to restart. Couple be bad RAM? Im going to update my BIOS and see if that helps anything.
-
I just started getting random reboots and I THINK it's tied to Windows 11 VM but can't prove it. I was running fine up to about a week ago when I got a reboot. It rebooted yesterday and again last night. I can't see anything in the log prior to the reboot though. I have syslog mirroring to flash. unraid-diagnostics-20240820-0856.zip
-
That's super low for that chip. Mine idles at 70 degrees (I do have a low profile noctua on it which isn't optimal but 70 is still in line with AMD spec). AMD intended this to stay at 90 degrees for most tasks, no cooler will solve that. You will get better performance out of a better cooler but it's still designed to run at 90, so the only thing a cooler does is keep it from throttling as hard. Like it or not that's what a new consumer high end CPU runs at.
-
Yes I second this, if I used SMB more or used Time Machine I would just put in the work for truenas, it just seems to work, and way faster at that. Unraid is more flexible though if you don't care about SMB.
-
Any time I try backing up files from my phone to a SMB share in Unraid it crashes SMB with the bellow error. I have a stock SMB config, no changes. I create a public share, I mount it on my phone, and start backing up, it will crash very soon after. May 16 22:59:05 Unraid smbd[30964]: [2024/05/16 22:59:05.448308, 0] ../../source3/smbd/fd_handle.c:39(fd_handle_destructor) May 16 22:59:05 Unraid smbd[30964]: PANIC: assert failed at ../../source3/smbd/fd_handle.c(39): (fh->fd == -1) || (fh->fd == AT_FDCWD) May 16 22:59:05 Unraid smbd[30964]: [2024/05/16 22:59:05.448327, 0] ../../lib/util/fault.c:173(smb_panic_log) May 16 22:59:05 Unraid smbd[30964]: =============================================================== May 16 22:59:05 Unraid smbd[30964]: [2024/05/16 22:59:05.448336, 0] ../../lib/util/fault.c:174(smb_panic_log) May 16 22:59:05 Unraid smbd[30964]: INTERNAL ERROR: assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in pid 30964 (4.17.12) May 16 22:59:05 Unraid smbd[30964]: [2024/05/16 22:59:05.448340, 0] ../../lib/util/fault.c:178(smb_panic_log) May 16 22:59:05 Unraid smbd[30964]: If you are running a recent Samba version, and if you think this problem is not yet fixed in the latest versions, please consider reporting this bug, see https://wiki.samba.org/index.php/Bug_Reporting May 16 22:59:05 Unraid smbd[30964]: [2024/05/16 22:59:05.448344, 0] ../../lib/util/fault.c:183(smb_panic_log) May 16 22:59:05 Unraid smbd[30964]: =============================================================== May 16 22:59:05 Unraid smbd[30964]: [2024/05/16 22:59:05.448348, 0] ../../lib/util/fault.c:184(smb_panic_log) May 16 22:59:05 Unraid smbd[30964]: PANIC (pid 30964): assert failed: (fh->fd == -1) || (fh->fd == AT_FDCWD) in 4.17.12 May 16 22:59:05 Unraid smbd[30964]: [2024/05/16 22:59:05.448463, 0] ../../lib/util/fault.c:292(log_stack_trace) May 16 22:59:05 Unraid smbd[30964]: BACKTRACE: 27 stack frames: May 16 22:59:05 Unraid smbd[30964]: #0 /usr/lib64/libgenrand-samba4.so(log_stack_trace+0x2e) [0x1554b665d64e] May 16 22:59:05 Unraid smbd[30964]: #1 /usr/lib64/libgenrand-samba4.so(smb_panic+0x9) [0x1554b665d8a9] May 16 22:59:05 Unraid smbd[30964]: #2 /usr/lib64/libsmbd-base-samba4.so(+0x4d0fb) [0x1554b6a3f0fb] May 16 22:59:05 Unraid smbd[30964]: #3 /usr/lib64/libtalloc.so.2(+0x44df) [0x1554b660c4df] May 16 22:59:05 Unraid smbd[30964]: #4 /usr/lib64/libsmbd-base-samba4.so(file_free+0xd6) [0x1554b6a4c266] May 16 22:59:05 Unraid smbd[30964]: #5 /usr/lib64/libsmbd-base-samba4.so(+0xc0781) [0x1554b6ab2781] May 16 22:59:05 Unraid smbd[30964]: #6 /usr/lib64/libsmbd-base-samba4.so(smbd_smb2_request_process_close+0x211) [0x1554b6ab2f01] May 16 22:59:05 Unraid smbd[30964]: #7 /usr/lib64/libsmbd-base-samba4.so(smbd_smb2_request_dispatch+0xdfa) [0x1554b6aa6bfa] May 16 22:59:05 Unraid smbd[30964]: #8 /usr/lib64/libsmbd-base-samba4.so(+0xb5bc1) [0x1554b6aa7bc1] May 16 22:59:05 Unraid smbd[30964]: #9 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x1554b661f8c1] May 16 22:59:05 Unraid smbd[30964]: #10 /usr/lib64/libtevent.so.0(+0xee07) [0x1554b6625e07] May 16 22:59:05 Unraid smbd[30964]: #11 /usr/lib64/libtevent.so.0(+0xcef7) [0x1554b6623ef7] May 16 22:59:05 Unraid smbd[30964]: #12 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x1554b661eba1] May 16 22:59:05 Unraid smbd[30964]: #13 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x1554b661ee7b] May 16 22:59:05 Unraid smbd[30964]: #14 /usr/lib64/libtevent.so.0(+0xce97) [0x1554b6623e97] May 16 22:59:05 Unraid smbd[30964]: #15 /usr/lib64/libsmbd-base-samba4.so(smbd_process+0x817) [0x1554b6a95be7] May 16 22:59:05 Unraid smbd[30964]: #16 /usr/sbin/smbd(+0xb090) [0x556c16c06090] May 16 22:59:05 Unraid smbd[30964]: #17 /usr/lib64/libtevent.so.0(tevent_common_invoke_fd_handler+0x91) [0x1554b661f8c1] May 16 22:59:05 Unraid smbd[30964]: #18 /usr/lib64/libtevent.so.0(+0xee07) [0x1554b6625e07] May 16 22:59:05 Unraid smbd[30964]: #19 /usr/lib64/libtevent.so.0(+0xcef7) [0x1554b6623ef7] May 16 22:59:05 Unraid smbd[30964]: #20 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x91) [0x1554b661eba1] May 16 22:59:05 Unraid smbd[30964]: #21 /usr/lib64/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x1554b661ee7b] May 16 22:59:05 Unraid smbd[30964]: #22 /usr/lib64/libtevent.so.0(+0xce97) [0x1554b6623e97] May 16 22:59:05 Unraid smbd[30964]: #23 /usr/sbin/smbd(main+0x1489) [0x556c16c03259] May 16 22:59:05 Unraid smbd[30964]: #24 /lib64/libc.so.6(+0x236b7) [0x1554b64276b7] May 16 22:59:05 Unraid smbd[30964]: #25 /lib64/libc.so.6(__libc_start_main+0x85) [0x1554b6427775] May 16 22:59:05 Unraid smbd[30964]: #26 /usr/sbin/smbd(_start+0x21) [0x556c16c03b31] May 16 22:59:05 Unraid smbd[30964]: [2024/05/16 22:59:05.448514, 0] ../../source3/lib/dumpcore.c:315(dump_core) May 16 22:59:05 Unraid smbd[30964]: dumping core in /var/log/samba/cores/smbd
