Xaero

Would it be possible to add Mame-Tools? Packages exist for Slack. Depends are LibSDL2 and GlibC 2.33 being available for a current version. Mostly desired for CHDMAN. There is a docker for CHDMAN but it has a static script that isn't very flexible for my needs. I'm trying to bulk convert ~10TB+ of archived Bin/Cue & ISO images to CHD since they are directly playable and this would be best suited doing directly on the server (especially since CHDMAN is multithread and I have 48 threads to work with on my unraid box.) I was able to manually install Mame-Tools and SDL2 with upgradepkg --install-new; however the GLIBC available through NerdPack/DevPack and Unraid is too old. I'll try manually installing a new GLIBC and hoping that doesn't break the runtime. If it does a reboot should recover me. Thanks for the consideration EDIT: For now I am rebuilding that container by editing the DockerFile to execute a script that I am binding via -v as a file. This lets me edit the script easily to suit my needs and lets me execute CHDMAN without needing to worry about dependency hell and such.

Linux Systems Administration. Sysadmins spend a lot of time being intimately familiar with configuration files, packages and their dependencies and resolving conflicts between them. They would be expected to have some familiarity with programming languages (C/C++ generally) as well as being comfortable with a terminal and scripting languages. Modern sysadmins also work with automated deployment systems a lot, things like CHEF/Docker/Kubernetes are going to be premium skills to acquire. This is the field I would like to get into, but never feel confident enough with my skill level to dive right into.

It would also be nice to address the color blind accessibility concerns by implementing terminal color profile support. I had a topic on this previously, but it seems heavily related to this since we're talking about readability. I basically am forced to use putty/kitty/ssh in another terminal emulator just so I can have colors that I can see (specifically the folders being light blue on bright green is awful)

This would be a question better directed at Plex, rather than unraid. They would be able to confirm what those IPs are for, or if they are foreign. Most likely, however, they are the IPs for the Plex server as the Plex application allows both direct and indirect connections thru their own "proxy" service on their side.

Does anyone have any input on this? Not super familiar with iptables and such; but this seems like the only way to approach it?

Reposting my response here so we don't keep bumping that other thread; From diag.zip -> system/ps.txt: nobody 31750 0.3 0.0 0 0 ? Zl May17 4:31 \_ [transmission-da] <defunct> The transmission-da process has become a zombie. Interestingly, the container is using dumb-init which should be handling the zombie process cleanup with a wait() syscall; but doesn't seem to be. Typically this would indicate that the offending zombie process is waiting on IO of some kind. I also note in your syslog that the BTRFS docker image was corrupted (twice) and recreated. I'm assuming a write operation in the docker.img is hanging and when forcibly rebooting the server that's corrupting it. Double check that none of the paths you have mapped to this container are on the docker image. If they are, this could be the culprit as that docker image could be filling up and then write operations just repeatedly failing.

Easiest way would be to just bridge all the cards together. A network bridge *is* software level switching. Don't expect good performance with this. Even if your CPU has hardware acceleration for network loads (some xeons) it's going to be substantially slower at the task than the FPGAs used in standard switching applications. It's why routers make poor switches and switches make poor routers. Servers can be pretty good firewalls and routers but they are generally awful switches.

So I'm trying to set up something slightly more "advanced" in terms of firewalling for the VPN. I have two tunnels configured, one which is only me, and I don't actively use this tunnel intentionally. It's my backup way in. My second tunnel is where all of my actual endpoint users connect. Ideally, I want them to have access to: 10.253.0.1 (Unraid on the Wireguard side), 192.168.252.72 (Unraid on the local LAN side), 192.168.252.254 (Local DNS) and no other local IP addresses. How can I set this up with a blacklist or whitelist? Currently I'm whitelisting the above addresses, but with 0.0.0.0/0 and ::0 in their peer configs, and DNS pointing to 192.168.252.254 the result is they have access to my server, and my DNS - but nothing else on the internet. If I switch to blacklist, I'd have to blacklist each individual IP address (from what I can gather) from 192.168.252.1 - 192.168.252.72 and then from .73 to .253. And then I'd have to repeat that for the wireguard subnet. Is there a simpler way to implement this type of access restriction that I'm overlooking?

I'm pretty sure plugins just "don't work" with this container. At least, I haven't been able to get any that aren't pre-bundled with deluge to work.

Any chance of adding support for Deluge-RBB plugin for this docker - it would make it infinitely more usable (it adds a browse button to WebUI and remote desktop clients) Currently, if you make no changes it errors out trying to import from common.py. I've tried adding the PYTHONPATH env variable which gets me further, but I stillg et "Cannot import name get_resource" on "from common import get_resource" but I don't see an actual python COMMON.PY anywhere (I see the deluge ones, but none for the actual python package)

Is it possible to stop the Unraid WebUI from listening on Wireguard interfaces? For one, since I use SSL - clients that don't have access to the LAN can't see the dashboard anyways; for two I'd like to be able to bind a dashboard docker to the HTTP port for clients that are connected via wireguard. Right now I believe the nginx server is bound to 0.0.0.0 - I'd like to change that to the fixed IP, if possible.

Since all of the errors are with AER and they are all Corrected - it would be safe to disable AER - however, I would not recommend doing so. Instead, since this issue is being triggered when attempting to access the memory mapped PCI Configuration; I would use the kernel option to switch back to legacy PCI Configuration you can do so by adding the following kernel parameter: pci=nommconf This will force the machine to ask the device itself for it's configuration parameters rather than mapping the device's configuration to a memory address. There's a completely negligible performance difference, and this will keep AER enabled, which can improve stability (for example, if an actual error occurs AER might be able to correct it on the fly and not result in a crash)

Convert offending videos to a format your transcoding hardware supports. Keep in mind not all codecs have hardware transcoding support, and not all cards support all formats that do. Any time the card is not capable of decoding the source format - the decoding will fall back on the CPU. Similarly, if the target format is not supported by the GPU, the encoding will fall back on the CPU. We (the forum members) don't have enough information on the situation to identify why you are having this problem currently.

Correct. Everyone using nvidia transcoding with Plex on Linux has this problem with Plex. There isn't really a simple workaround. I tried injecting a wrapper script to monitor the transcode process and then manually kill the offending process once the transcode has ended, but it isn't reliable, and can interfere when multiple users are streaming transcoded content simultaneously. I think I have some new logic that will work properly - but ultimately Plex or Nvidia needs to figure out why this is happening. According to a recent post on the thread regarding this issue - nvidia was able to replicate the issue in their lab environment, and they were able to use some internal testing drivers that no longer exhibit the issue. That driver release "should" fix the problem permanently for everyone. It's odd that this behavior only seems to happen with Plex, and not Emby - but they are different applications so there could be a different interaction in software there. Here's the thread on the Plex forums: https://forums.plex.tv/t/stuck-in-p-state-p0-after-transcode-finished-on-nvidia/387685 fuser -kv /dev/nvidia* will kill the offending process (and any other other processes using the GPU) by the way.

Would it be possible to implement the fix depicted here: https://github.com/rakshasa/rtorrent/issues/861 Currently, the bug presented in that thread is present in this container. I've been having to screen -r my docker and manually stop and start torrents because I still cannot seem to stop getting the errors in regard to the getplugins.php (my previously implemented resolution stopped working, after a couple of months and incidental docker updates... This seems to be a constant struggle with rtorrent on unraid. Regardless of the number of active torrents.) EDIT: I'm at a loss. I'm back to square one basically. I'm going to backup my rutorrent config folder; and try starting over but I'm back to the abysmal 20-30kb/s and unresponsive (or not even loading) webui. Nothing in the logs seems of relevance. I've read through logs and even enabled advanced logging. There's no "errors" so to speak, just the rtorrent application sitting at 99.99% IOWAIT. I'm wondering if it doesn't like the merged filesystem that unraid uses? I'm downloading to an NVME SSD and the only application with this issue is rtorrent. I'll post back with what I figure out.

That is what I had, and the fix in my case was to swap to the BFQ Scheduler. I also don't know exactly why that change fixed the problem, so it may very well not be applicable in every case 😞 I think rutorrent might not like the layered FS that unraid uses. I've tried saving directly to cache and letting mover handle moving the the array (using /mnt/cache/sharename in the rutorrent configuration) but that hasn't alleviated the other problems (The request to rutorrent has timed out) I have seen. I do no longer get the 504 gateway errors though.

If your issue was (500, [error,getsettings]) And not (50x, [error,getplugins]) It probably doesn't match the symptom I was depicting. I outlined very specifically when the scheduler change would be applicable.

Android running on Emulated ARM hardware would probably run worse, FWIW. This would be a use case for it then. You could however, set up a PXE boot SD card and store your development/testing images on a PXE server for the PI. This way you aren't constantly writing an SD card and your changes to the image can happen quickly.

Make sure that EuP is disabled in the bios. I Note that you are using an Asus board - and EUP would be present on their boards.

Oh, rip

Try: #!/bin/bash DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )" $DIR will then contain the folder the script was ran from.

Use AndroidX86: https://www.android-x86.org/releases.html In a normal x86 vm. Arm is not required for this. @OP - are there any specific limitations that prevent you from running the native x86 versions of those packages or configurations in say, an ArchLinux or Debian VM? I mean, testing rpi images is a fine use case for it. But crosscompiling for ARM is faster on native x86 if you are planning on using it for any sort of dev purposes.

It's in the disk settings.

How do you mean? You can use command substitution if you want the warning to display the output of a command: WarningText="$(somecommand -someoption somefile.someextension)" then use "$WarningText" where you would like the output of that command.