lnxd

Very interesting, I'm going to see if I can find out more information on your card's compatibility with the built-in drivers and go from there. I'll get back to you in the next day or so. You have a very high end server 😅

Like that but take out the -amd 😅 I'll add that into the instructions in OP. EDIT: It looks like you were following the right instructions by the way, if you get stuck at all just let me know.

Yup, it calculates the amount of threads to run efficiently when it launches. It works out something like threads / 2, and my understanding is that it takes things into consideration such as your available cache as well, so that's expected. You can override it but you'll notice you only get a tiny increase in hash rate at a significantly higher power draw.

No worries! And in this one? Probably not for the foreseeable future, because it’s way more profitable and efficient to mine Eth with a GPU. Check out PhoenixMiner in my signature, that works with Nvidia.

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.

Hey @neow, I don't know if this is the best way, but here's one safe way that migrates everything including the nvram. I don't know how comfortable you are with terminal so I've minimised the need for that as much as possible: You need the array started on your old server, but make sure the VM isn't running Open the Unraid WebUI from your computer > click VMs > Check the VM's config to see where the vdisks are located, most likely it's in /mnt/user/domains/Windows 10 if you've called the VM Windows 10 on your server. While you're in here, Change from (Form View) to (XML View) and find the contents of the nvram tag, eg. <nvram>/etc/libvirt/qemu/nvram/91801fae-a4eb-a604-0b6f-906d2b7e90f8_VARS-pure-efi.fd</nvram> Copy the contents of the tag: /etc/libvirt/qemu/nvram/91801fae-a4eb-a604-0b6f-906d2b7e90f8_VARS-pure-efi.fd Go back to the Unraid WebUI from your computer > open Terminal > Run: cp /etc/libvirt/qemu/nvram/91801fae-a4eb-a604-0b6f-906d2b7e90f8_VARS-pure-efi.fd /mnt/users/domains/Windows 10/ Where 91801fae-a4eb-a604-0b6f-906d2b7e90f8_VARS-pure-efi.fd is the name of the file you got from step 3, and Windows 10 is the location of your vdisks from step 1 Go back to the Unraid WebUI from your computer > click Shares > click the little symbol next to the domains share under the View heading to browse the contents. Navigate to the folder where your vdisk is stored, probably Windows 10 Download the vdisk, probably vdisk1.img, and the .fd file we put there in step 4 to somewhere on your computer Transfer these files to the same location on your new server (/mnt/user/domains/Windows 10) however you want to, easiest via SMB or ssh/scp Go back to the old server's Unraid WebUI from your computer > click VMs > Edit your VM > Uncheck / remove any passed devices or USBs and change any primary GPUs to VNC and remove any secondary GPUs Change to XML View again and copy the entire contents to your clipboard Go to the new server's Unraid WebUI from your computer > click VMs > Add a VM Repeat the same as step 8, but this time paste the entire contents Double check there are no hostdev tags, if there are, delete them because your other server is very unlikely to be using the same device IDs / PCI addresses. Eg. Would become: Change back to Form View and make sure everything looks fine, then try saving it but uncheck the box to start the VM Open Terminal from the Unraid WebUI on your new server and run the reverse of the command in step 4, eg. cp /mnt/users/domains/Windows 10/91801fae-a4eb-a604-0b6f-906d2b7e90f8_VARS-pure-efi.fd /etc/libvirt/qemu/nvram/ Where Windows 10 is the name of your VM and 91801fae-a4eb-a604-0b6f-906d2b7e90f8_VARS-pure-efi.fd is the name of your NVRAM file from step 3. Start the VM, everything should be ready. If you get errors, you probably didn't remove all devices in XML view / step 13 Hope this helps. EDIT: ^^^^ I Keep removing this random XML view icon but it keeps coming back 😂

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.