lnxd

Wow is that a good hash rate 😅 Yup it's running correctly. I addressed the MSR mod error in OP. I might end up disabling it, Unraid requires quite a bit of adjustment to set up MSR support, and it didn't change my hash rate at all. But then your hash rate is 7.5x mine so.. I'm also not sure if it affects Ryzen processors more, but I'm still investigating. Yup, it might take a while before your first payout but you can check the stats here. The only two things that stand out are that you set your worker name to "Xeon CPUs" which has a space so you're getting a warning about it, you'll want to change that to "Xeon-CPUs". Also you're using the Australian node, if that's your closest node it's fine, otherwise best to pick a closer one: xmr-eu1.nanopool.org xmr-eu2.nanopool.org xmr-us-east1.nanopool.org xmr-us-west1.nanopool.org xmr-asia1.nanopool.org xmr-jp1.nanopool.org xmr-au1.nanopool.org

No worries, you did the right thing by posting here but I've just replied on the new support post so that PhoenixMiner users don't get confused.

@frodr I'm just replying to your question over here as the new post is up. I've attached your logs in case it's hard for anyone else to follow. How much free RAM do you have available to your Unraid host? Bear with me, I'll push a build to a custom tag that runs xmrig as the root user instead of the nobody user and see if that works for your Xeon. EDIT: If you change the Repository to lnxd/xmrig:latest-root it'll run xmrig as the root user instead. If that doesn't work, try enabling Privileged mode (temporarily if it doesn't work) for the container as well and see if you get different results. If it works let me know and I'll leave the tag up for you and anyone else who has trouble. Log.rtf

😂 it's available here. I like everything to be perfect before I post it but I'm starting work in 9 minutes so that'll have to do for now.

Overview: Support thread for lnxd/XMRig in CA. Application: XMRig - https://github.com/xmrig/xmrig Docker Hub: https://hub.docker.com/r/lnxd/xmrig GitHub: https://github.com/lnxd/docker-xmrig Please ensure that you know what you're doing before setting this up, as excessively high temperatures are BAD for computers and could damage your hardware / eventuate in data loss. Instructions: Install lnxd's XMRig via CA. Add in your XMR receive address to the wallet field. Update the pool address to your closest node or preferred pool. Don't forget to pay attention to the port if you change pools, as they tend to use arbitrary ports. Set the --donate-level you would like to enable. Eg. entering a 1 causes XMRig to mine for 99 minutes for you, and then 1 minute for the fee option chosen in the next step. Setting the --donate-level flag to 0 will not work unless you follow the steps below. There are 3 fee options enabled by a custom build from my fork of the latest release source. This allows for some options that aren't available in the base version: no-fee: Makes it possible to set the --donate-level flag to 0%. Unless you set it to 0%, the fee goes to the developer of XMRig. dev-fee: The fee goes to the developer of XMRig. lnxd-fee: The fee goes to me 🙃 Thank you in advance if you choose this option. Turn on advanced mode for the template and select CPU core / thread pairs that you would like to use in CPU pinning. I recommend leaving core 1 and its thread pair unselected, as it could possibly cause Unraid to unexpectedly slow down / the Docker engine to quit if things get too intense while mining. Run the container and check the temperature of your CPU and other hardware regularly for at least 20-30 minutes to ensure everything is safe and stable. If you get any errors that you can't decipher, feel free reach out and I'll take a look for you. (Optional) To increase your hash rate, you can add and run the following User Script. At the moment, in order to reset your MSR values to default you need to restart your Unraid host. For this reason, it needs to be re-run after every boot as the updated values do not survive reboots. The script installs msr-tools and then updates the registry values to optimise your CPU for XMRig. This may have performance implications for other functions on your server. The logs will also show that XMRig is being run with MSR MOD disabled, but if you run this script it serves the same purpose and you should get a higher hash rate. #!/bin/bash # Write XMRig Optimised MSR values # https://github.com/xmrig/xmrig/blob/master/scripts/randomx_boost.sh VERSION=1.3 echo "Installing msr-tools v${VERSION}" echo "" echo "(don't!) blame lnxd if something goes wrong" echo "" curl -fsSL https://packages.slackonly.com/pub/packages/14.2-x86_64/system/msr-tools/msr-tools-${VERSION}-x86_64-1_slonly.txz -o /tmp/msr-tools-${VERSION}-x86_64-1_slonly.txz upgradepkg --install-new /tmp/msr-tools-${VERSION}-x86_64-1_slonly.txz rm /tmp/msr-tools-${VERSION}-x86_64-1_slonly.txz echo "" echo "Optimising register values for XMRig" echo "" modprobe msr if cat /proc/cpuinfo | grep "AMD Ryzen" >/dev/null; then if cat /proc/cpuinfo | grep "cpu family[[:space:]]:[[:space:]]25" >/dev/null; then echo "Detected Ryzen (Zen3)" wrmsr -a 0xc0011020 0x4480000000000 wrmsr -a 0xc0011021 0x1c000200000040 wrmsr -a 0xc0011022 0xc000000401500000 wrmsr -a 0xc001102b 0x2000cc14 echo "MSR register values for Ryzen (Zen3) applied" else echo "Detected Ryzen (Zen1/Zen2)" wrmsr -a 0xc0011020 0 wrmsr -a 0xc0011021 0x40 wrmsr -a 0xc0011022 0x1510000 wrmsr -a 0xc001102b 0x2000cc16 echo "MSR register values for Ryzen (Zen1/Zen2) applied" fi elif cat /proc/cpuinfo | grep "Intel" >/dev/null; then echo "Detected Intel" wrmsr -a 0x1a4 0xf echo "MSR register values for Intel applied" else echo "No supported CPU detected" fi echo "" echo "Done!" echo "To reset values, please reboot your server." If you get stuck, please feel free to reply to this thread and I'll do my best to help out 🙂

Yes that's me, thank you! ☺️ On that setting (for the xmrig container) it mines for me for 1 minute every 100 minutes. I need to make the new support thread!

Thanks! If you mean to control it you’d need to start an interactive session using docker exec for now, I’m still investigating whether that’s possible. Otherwise the logs should be visible via the WebUI in the Docker page, click on the xmrig logo and press logs. Or of course run this in terminal: docker logs xmrig -f

It can be for now, or you can PM me. How can I help?

Haha no worries. Thanks for pointing that out. It's expected, I didn't think anything of it. It could cause problems for some people so I'll update that too, you can expect a fix within the next 12 hours or so and I'll tag you when it's ready. Thanks for the feedback! EDIT: With the latest update the data is now owned by the user nobody which is default for Unraid. Anyone who wants to change ownership on the data that's already there just run: sudo chown -R nobody /mnt/user/backups/github In your case @eds replace /mnt/user/backups/github in that command with /mnt/user/github as I believe that's where you store it.

Thanks, If anyone else gets the same error as @eds, my code doesn't handle whitespace in the Token field so you need to make sure there are no spaces before or after your token. I'll patch this in the next update.

😂 Derp is a good worker name. Ah, I forgot to make the new support post before I fell asleep. Thank you for reminding me! This is expected at the moment on Unraid unless you use a custom kernel build, I didn’t want to strip MSR from the builds. The impact on hash rate is negligible in my testing so don’t stress.

@eds can you please visit this page and delete the token. Then jump into a terminal via webUI or SSH and run: docker exec github-backup cat /home/docker/github-backup/config.json I'll get you to please copy and paste the output here in code tags or a text file. Also the output of: cat /boot/config/plugins/dockerMan/templates-user/my-github-backup.xml Both will have your token in it, but as long as you delete it from the GitHub website first it's useless (you can see a few of my former tokens in the repo). If you don't feel confident you can always PM me the output directly. Thanks!

Hey @eds, thanks! Can I please grab your GitHub username? If you have any symbols in there it might not be handled correctly.

😮 sorry for the delay, I missed your post. I'll PM you. Good call! I've gone ahead and updated it for everyone. I already mentioned the 4gb DAG limitation in OP a few times, but hopefully that makes it more clear for everyone that it's not model specific.

Thanks mate, is that a 4gb card? That won't work for mining Ethereum because the DAG size is larger than 4gb now ☹️ I mean, you could try setting -daglim to do it: -daglim <n> (AMD Polaris, Baffin, Tonga, or Fiji cards only) Limit the DAG size to <n> MB to allow mining on 4 GB cards a few weeks after epoch 373 on Windows (or 381 on Linux). The possible values except the exact DAG limit are also 0 (turn off the DAG limit), 1 (automatic DAG limit size, usually 4023 MB under Windows; this is the default). Note that the hashrate will drop significantly with each epoch after the DAG limit is in effect. If the hashrate drops too much (e.g. from 28 MH/s to just 2-3 MH/s, you need to use lower value, for example -daglim 3996 or even lower. But I doubt you will get too far because Ethereum is up to (I believe) epoch 404. You might still be able to find a profitable coin to mine with but you'd need to get your hash rate up above around 6MH/s to even break even (based on energy prices in Australia, I have no idea how much energy costs in the UK) You can calculate profitability on a site like this, that's based on US energy prices of course but if you enter your converted cost the formula is the same. @NixonInnes Damn, it was worth a shot. That's a good card, I'm sure you could get way more out of it than what you're getting, but it might make your system unstable if you start pushing it with OC options. My RX 580 is running custom bios, but that's a risk to damaging your GPU. I hope you're mining on both of them 😉

It's probably still on if you haven't turned it off or reset the card since. The -acm argument in additional should do it. If that doesn't increase your hash rate, what card do you have specifically?

😮 there's definitely something wrong. Would you mind posting your diagnostics.zip? EDIT: @mauriceatkinson@btconnect. also the output of your docker logs for the container, chuck them in a text file and attach them as well please. Won't be anything confidential in there, just details about your GPUs. That should work just fine, yup.

Yeah I have no idea what's going on there 😂 assuming it's real it should work with both 18.20 and 20.20. Since it doesn't, 🤷‍♂️ all we can do is prod it until it either starts working or gives us a real answer as to why it won't. Just make sure you blacklist the radeon module and restart before trying it otherwise you'll get the same error. I'm sure there's a way to tell which card to use which module but since you're only trying to use it with an amdgpu compatible card, blacklisting it is the easiest.

@NixonInnes You're welcome! Thanks for the feedback. Are you on the latest tag (20.20 drivers)? I'll update OP. EDIT: @NixonInnes do you have compute mode enabled for your GPU? All the estimates for that card are for it to hit 29-31MH/s which probably are using custom mining bios and OC. But if you don't have compute mode turned on for a Polaris GPU you'll get a low hash rate. That's not measly by the way, if there wasn't a shortage I'd be buying up used RX 570s and RX 580s to mine with. @pronto This is good news! It means that it should work. Just blacklist radeon and fingers crossed you'll be good to go. I believe that error means that PhoenixMiner is using the radeon drivers to communicate with the card. That error actually confirms for me that no radeon cards will work with it so thanks for the data, that explains why @Lobsi was having difficulty with what looked like a working build. I'll take the 15.12 build down. I updated the tags in OP btw, so you're better off using one of these than the custom builds. Specifically lnxd/phoenixminer:latest-18.20 should work for you.

Hey there, The error shows you left the address as the default (unraid.local), you'll need to edit the container and give it the right address. Visit Unraid WebUI > click Docker > Click on the logo next to PhoenixStats > click Edit > Change Miner Host from unraid.local to your Unraid server's local IP > click Apply Then visit the PhoenixStats UI again and it should be working.

Most likely yup, looks like you also have a bios upgrade available so probably a good time to see whether that's worth updating as well when you're solving that problem. I'm hoping it's real, it could really go either way. But definitely interested in seeing those pics / finding out whether this kind of output is normal for this series. No worries at all! I have two builds ready for you to try: lnxd/phoenixminer:v1.0.0-20.45 lnxd/phoenixminer:v1.0.0-18.20 If you punch those into the Repository field on the container's edit page and start it up one at a time, let me know if either of those work for you. The first one is ideal if it does but I'm pretty sure the drivers failed to install, it's way too large to be valid. If neither of them do, I'll spin up a VM and build the first one on an older kernel and then push it to Docker Hub for you to try out. Edit: I forgot to update the base title on the second one, it'll report Ubuntu 20.04 but it's actually Ubuntu 18.04. Just ignore it, it won't affect anything.

Permissions are correct and you don't have a rogue config file. lsmod on your system is only showing amdgpu has been loaded but not radeon, but the output of your lspci is strange. 0a:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Bonaire [FirePro W5100] [1002:6649] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] FirePro W4300 [1002:0b0c] Kernel modules: radeon, amdgpu 0a:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Tobago HDMI Audio [Radeon R7 360 / R9 360 OEM] [1002:aac0] Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Tobago HDMI Audio [Radeon R7 360 / R9 360 OEM] [1002:aac0] Do you have more details about this card? The subsystem device ID (0b0c) for the VGA controller matches a W4300 and the audio device (aac0) an R7/R9. Weirdly on AMD's website they list the W5100 as compatible with the amdgpu 20.20 pro drivers, but if you have a look at the card's driver support page it's supported by a different driver package (Radeon™ Pro Software for Enterprise on Ubuntu 20.04.1) I'll do a custom build for you with the enterprise drivers and see if that works, heads up to get it working you may need both the amdgpu and radeon modules loaded.

That should work, did you restart afterwards? Please post the output of ls -lh /boot/config/modprobe.d/ And if the first diagnostics file wasn’t after you blacklisted the Radeon drivers and then rebooted, post another diagnostics file soon after you reboot. I’ll take a look at the output when I get home

Hey @pronto, well found, you’ll need to use the amdgpu module for this container to work. How did you go once they were blacklisted?

Glad to see you had success with that and I'm (even more) glad you referenced that comment, just keep in mind there's a less extreme approach with much less risk if you just want to delete the dangling images: docker image prune Will just delete the dangling images, and docker image prune -a Will delete all dangling and currently unused images. vs. $ docker system prune --all --volumes WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all volumes not used by at least one container - all images without at least one container associated to them - all build cache You could even safely set docker image prune as a User Script to run daily/weekly if it's a really regular issue for you. #!/bin/bash # Clear all dangling images # https://docs.docker.com/engine/reference/commandline/image_prune/ echo "About to forcefully remove the following dangling images:" docker image ls dangling=true echo "" echo "(don't!) blame lnxd if something goes wrong" echo "" docker image prune -f # Uncomment to also delete unused images #docker image prune -f -a echo "Done!"