xshell

Hi @Richy1989 I'll say thanks. First and foremost. For the effort and contribution to all. Not here to invoke alarm or offence. But are you able to help dispel some things on my mind? I saw your submission in the Unraid app store from my server. This brought my attention to MeshCentral, which is awesome and I'd like to start using it as a result. Thanks a lot for bringing my awareness to a great project. Having giving it a quick spin and enjoyed it. Then went for a look at who/what is behind this image. I'm not a common lurker here on forums, so I don't know you. I just note that you have several submitted apps, a 2021 account and a 10 post count. I couldn't find much info about your methodology or description, referencing inputs in creating this docker image. I went to DockerHub/Github to try find a Dockerfile or something. But unable to find anything. And your description just references the creators repo with the official image. Can you elaborate on what your Unraid 'tailored' image is about? I note there is already an official image: ghcr.io/ylianst/meshcentral:master - which I have tested post-install (simply changed container image). And it works great with your template. Pardon my ignorance if missing something glaring here. However. Literally any secrets/password/vault/ssh/connection/server management app instances must be pristine and untampered. One unsuspecting deployment can literally be catastrophic in an untold number of ways. For reasons what should be straight forward in understanding. So I decided to bring it up for benefit of all. Thanks for your prep. I have decided to reinstall using ghcr.io/ylianst/meshcentral:master currently.

Apologies, I know I've left this unreplied to for ages now. I'll put it on my list of things to get around to doing. Can't guarantee though. In the interim, shouldn't take much effort to follow my steps for a local version /@Wassabi

Yep. Exactly the same. Uh.

Have never had luck with the same on EPYC 7502P. The script applies successfully. But no matter if privileged run, or root or non-root image used, always get Failed to apply MSR. I believe the guidance in the thread was "don't worry about it". But I cannot verify if it's actually working correctly or not. Edit 1: According to the following, the params "--randomx-wrmsr=-1 --randomx-no-rdmsr" disable MSR, but these are hard coded in to the image. And can be seen in log view prior to your XMRig additional commands. Source for file: https://github.com/lnxd/docker-xmrig/blob/main/mine.sh Can you comment? @lnxd Edit 2: I fixed the problem after years of encountering. This pre-built image is pulling a very old version of xmrig and numerous enhancements have been made to xmrig's AMD related codebase since. I ended up cloning the git repo (https://github.com/lnxd/docker-xmrig.git), building xmrig on an equivalent environment to ubuntu:20.04 (because Dockerfile & packaged xmrig build based off it) and changing dev fee from 1 to 0 in src/donate.h, uploading somewhere, updating the Dockerfile links to that location so it pulls my .tar.gz instead. Replace command and echo lines in mine.sh to eliminate hard coded msr disabling parameter. I have: echo "--url=${POOL} --coin=${COIN} --user=${WALLET}.${WORKER} --randomx-no-rdmsr ${ADDITIONAL}" cd /home/docker/xmrig-${FEE} ./xmrig --url=${POOL} --coin=${COIN} --user=${WALLET}.${WORKER} --randomx-no-rdmsr --donate-level=${DONATE} ${ADDITIONAL} Additionally, the final piece in the puzzle was using User root instead of User docker near bottom of the Dockerfile, and running as privileged. Run docker build -t local-docker-xmrig-root . Remove container + image to avoid caching. Add container, select XMrig in your dropdown, change image to local-docker-xmrig-root:latest This has entirely finally fixed my hugepages and MSR issues. Happy days!

I'm actually shocked that it's nearly 2024 as I write this - and I just spent the better part of an hour figuring out what on earth was going on. And this was it. Sorry, but..... this is pretty unacceptable to remain unfixed in a commercial product for so long

Always try to familiarise yourself with project resources as much as possible when launching projects within your environment. Following the speedtest-tracker GitHub through to their Documentation page reveals the email environment variables needed. Which can be attributed via "Add another Path, Port, Variable, Label or Device" in your container configuration settings:

Feature idea: It would be cool if the "ignored" acknowledged errors & warnings were displayed in a condensed manner or collapsible list, instead of presenting the same as active warnings and errors do. It triggers me when the page loads thinking there might be stuff in there but it's just my list of already-reviewed things Thank you! Just the solution I came to look for.

Issue still exists. Remaining on old version for now.