lnxd

Yup, that's your problem. Your wallet address should be 0xF46DAdD92001db24CCD681D0b73aF9ad3dDf2774 Basically it's trying to run: ./phoenixminer -pool us1.ethermine.org:4444 -wal 0xF4 6DAd D920 01db 24CCD 681D 0b73 aF9a d3dD f2774.x -tt 68 -tstop 75 -tstart 50 -cdm 1 -cdmport 5450 -amd So PhoenixMiner thinks your address is 0xF4 and that 6DAd is another instruction from you that it doesn't understand. I'd also set -tt (Target Temperature) to a fixed speed like -65, 68 is a good target temperature but it's unlikely your default fan curve will let that happen. When you get the hang of it you can start playing around with other arguments like pairing -tt with -fanmin, etc. but if your card is in a closed case it's better to be on the safe side. I decided to just take the side off my case and let the GPUs warm my office, luckily for me we're coming into winter. Once you're up and going you can check your stats by entering your address on ethermine.org. I also added another container last night called PhoenixStats so you can directly monitor your miner via http instead of having to scroll through the logs to see the per GPU hash rates and temperatures. Screenshot:

Morning @SPOautos, that pool address is valid and ethermine is a good option. This is correct for ethermine. Wallet addresses don't have spaces in them so I'm thinking that's the problem. It will probably just start and then quit because it will think each part of your address is a different argument. Feel free to share the logs from the container if you're not sure.

No worries. Depends a little bit on which country you’re in and your level of comfort with storing your cash. There’s hosted wallets (where someone else keeps the keys), local wallets (where you keep the keys) and hardware wallets (where the wallet is the key). Easiest to set up is a hosted wallet, I’m not sure where you’re located but an example of this in Australia would be CoinJar, and an example in the US would be Coinbase. Just make sure if you take this path you find a company you trust and turn on two factor authentication. Personally I mine to a local wallet, but if you’re a windows user you’ll probably get bombarded with AV detections. I use MyCrypto and CoinJar. Ethereum have an official list of wallets, any of those should be fine https://ethereum.org/en/wallets/find-wallet/

No need to enable the radeon module, that is for older cards. I’m pretty sure none of the cards that are supported by that will be worth it to mine with these days. Your RX580 will work with the amdgpu module just fine.

I'm just spying on you now @SPOautos because I was trying to see if you had a recent diagnostics file posted somewhere 😂. The RX 580 is a great card for eth mining by the way, I get 28-28.5 MH/s on mine. Just in case anyone is still having trouble: As I'm sure you both know the RX 580 is plagued by the vendor reset bug, so even if you manage to get it going, without the vendor reset patch applied it won't be pretty with most OS. I managed to get mine passed through to Windows 10 without a custom Unraid kernel with only occasional restarts, but once I started mining on it in a Windows VM it would cause the whole Unraid host to hang after a few minutes of heavy workload. I managed to get mine passed through with basically the same xml as what's in OP. Once I was on a kernel with the vendor reset patch applied I was only getting a black screen as well. I had to change to legacy boot mode and use SEABIOS to get it working. This usually involves creating a VM from scratch as it's not default, but you can use the existing vdisk if you have one.

I can see why that'd be confusing. 😂 You don't need Radeon Top specifically, but you need to let the Unraid host load the drivers, which is why this relies on 6.9.0 or later. As long as Unraid is up to date on your host, you should be able to see it in there. It looks like the only requirement for the plug-in set by ich777 is 6.9.0. If you're going top-down through the steps, I'm guessing you're already on 6.9.1. I would very strongly recommend installing this plug-in. It might be worth visiting settings from the sidebar in CA and temporarily setting "Hide Incompatible Applications" to No, and doing another search to see if that turns it up. Best to make sure you change it back afterwards. If you feel like you've exhausted everything, you can try one of the following: Option 1: Per the user guide, you can open up a terminal window via the Unraid WebUI and run this before restarting to unblacklist the host's amdgpu drivers: touch /boot/config/modprobe.d/amdgpu.conf And, sometime in the future, if you need to be able to use vfio passthrough with your GPU; you can run this before restarting to undo it: rm /boot/config/modprobe.d/amdgpu.conf Option 2: The concept for this is stolen from ich777's plug-in, and it's more of a temporary option that doesn't require a reboot but will need to be re-run after each boot. You could set it up as a User Script, but it is much cleaner to use the plug-in. Jump into a terminal window on the host and run: modprobe amdgpu && sleep 1 && chmod -R 777 /dev/dri Thanks for your question @SPOautos, I've updated the OP and readme to be more clear.

Hey @DGPugliese, not as far as I know but this error is to do with DAG generation. How much RAM does your GPU have? Thanks for the warning to the community. It triggered a lot of people on the NiceHash subreddit and YouTube when they published that. The general consensus as far as I know is that NiceHash took advantage of a bad situation for the developer (Mega removing all Mining related binaries) and advertised their own Excavator miner using fear tactics. This is the developer's response. A lot of people have similar concerns about using NiceHash as the FBI have a warrant out for the arrest of their founder due to his involvement in the creation of a botnet, and he was recently detained in Germany for 8 months. This post definitely crossed my mind when making this but this container pulls the binary from the PhoenixMiner's developer's official GitHub repo, and if the developer had taken advantage of some kind of baked in exit strategy why would they still be working on it? We can't know for sure, but if I got as good a hash rate from TeamRedMiner I would've containerised that instead 😅 No worries at all! 😁

Thanks for the feedback. I'm glad to see someone else is going to get some use out of it! Let me know if anything comes up that gets you stuck. I have the same concern; luckily, in my case, I still have the iGPU on my i5 10500. One day when I get some time, I might take a shot at passing that through.

^^^ This was exactly my reasoning when posting the poll. That said, it served its purpose and it's on CA now if anyone is interested. Support thread and instructions are here.

It's basically impossible here (in Australia) as well. AMD GPUs are completely sold out everywhere, the only thing you can get are entry level Nvidia cards. I managed to get the 5500 XT overpriced and it's now worth more used than what I paid for it. I got into it back in around 2012-2013, but ASICs killed that. I came back to it just in the past few months now that it is profitable again but it's too late to get GPUs now. You aren't proving your point 😉 EDIT: @ich777 I tried using your bullseye container as a base image last night, forcing an install of the latest mesa drivers and then pulling PhoenixMiner in. It looked promising but PhoenixMiner couldn't see any cards (that rely on amdgpu or radeon), even though I could see them from the container. It was expedited because @Lobsi has an R9 270x that they wanted to try mining with. I then built a container on Ubuntu 14.04 with the 15.12 Radeon drivers to no avail. I'm pretty sure PhoenixMiner can only see cards using certain drivers but I just wanted to say thanks for the tip! Would have been nice if it worked with the open source drivers, not only would they (theoretically) be faster but the image could be so much smaller and more efficient. I'm going to see if I have more luck with a different miner.

Perfect! Thank you, looks like my understanding was correct. I'll update the instructions to reflect as such. 😂 You are everywhere, and yep nice and simple 😉 amdgpu-pro-20.20. This isn't the first time I've heard this, but unlike yourself I'm not a genius so I need to do a lot of research first before I know what works. Now that I know it meets the requirements for CA, it's worth spending some time to thoroughly investigate. I'm curious to learn if there is any impact on using eg. open source in the container, vs. proprietary on the host, vs. different versions of the drivers, etc. I'll probably also need to add tags with different driver versions as different cards don't work with PhoenixMiner on specific amdgpu-pro versions. I also want to see if I get different results on different versions of the kernels available with PhoenixMiner, and I might benchmark against other mining software too.

Hey again @ich777! I just saw that you've released Radeon Top and it should save a lot of time for users trying to install a container I just had added to CA. Just a few things I was wondering about if that's cool with you? 1. I've noticed in the code it runs modprobe amdgpu, does this mean that a reboot isn't necessary after installing it before the GPU becomes available to the host? 2. Does it mean that it's not necessary to run touch /boot/config/modprobe.d/amdgpu.conf per the user guide to get Unraid to load the drivers as long as this is installed? 3. Does this override everything that could prevent Unraid from loading the drivers? eg. vfio passthrough being enabled for the GPU, or the GPU being stubbed Thanks mate!

Overview: Support thread for lnxd/PhoenixMiner in CA. Application: PhoenixMiner - https://github.com/PhoenixMinerDevTeam/PhoenixMiner/ Docker Hub: https://hub.docker.com/r/lnxd/phoenixminer GitHub: https://github.com/lnxd/docker-phoenixminer 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: Ensure you are on Unraid 6.9.0 or later; otherwise, amdgpu drivers are not included. Ensure your GPU is not bound to vfio at boot, on 6.9.0, and later you can do this by visiting Tools > System Devices and ensuring your card (and its audio device) is not checked. Also, ensure your GPU is not stubbed by checking its ID on the above page and cross-referencing with pci-stub.ids= (by visiting Main > Flash). If you made changes in this step, you need to safely shut down the array and reboot before proceeding. If you use AMD: Install ich777's Radeon TOP via CA (Easiest way to load AMD GPU drivers on Unraid host, which is still necessary even though the container contains AMD drivers). Install lnxd's PhoenixMiner via CA. Make sure you update the pool & wallet address; otherwise, your 'rig' will generate income for me instead. If you use NVIDIA: Remove -amd from Additional PhoenixMiner Arguments. If you want to enable PhoenixMiner to control the fans / undervolt / overclock: leave privileged mode enabled for the container. Run it, check the logs constantly for the first 20 mins or so to ensure it is working and your card doesn't overheat. If something looks incorrect, stop the container and double-check your config. I like to try and keep my 5500XT around 75c and my RX 580 around 55c (modded bios). (Optional) If you want to monitor your miner from a web app rather than a representation of the logs, check out PhoenixStats in CA. Warning: If you don't leave privileged mode enabled for the container, your GPU's default fan curve will be used, which is usually optimised for gaming. Make sure you have Bergware's Dynamix System Autofan installed to prevent overheating. I recommend enabling it and setting the high temperature to 25c at most. Low I set to 20c. I could not get the PWM min speed, but this didn't affect anything for me during testing. Tags: Nvidia cards should work on all tags. Different AMD GPUs require different driver versions, and those different driver versions often don't work very well on Operating Systems that they weren't built for. For this reason, I've gone ahead and changed to using multiple tags, each tag has it's own GPU compatibility table further down. If someone has success with an AMD GPU on a specific tag please reply to this thread and let me know so I can update the table. I only have access to an RX 580 and a 5500XT for testing. lnxd/phoenixminer:latest (Same as latest-20.20 as this is the most compatible with current cards) lnxd/phoenixminer:latest-20.45 (Only for RX6800 and RX6900) lnxd/phoenixminer:latest-20.20 lnxd/phoenixminer:latest-18.20 lnxd/phoenixminer:latest-15.12 (Cards that rely on the radeon kernel module will not work) Compatibility: These lists are very hopeful, they're sourced from the AMD website, and there's a real possibility your GPU might not work with a tag it's supposed to. Please do not make purchasing decisions based on these tables. Also keep in mind you are unlikely to be able to profit from mining with a card with less than or equal to 4GB VRAM available to it. If you try this container you will probably get a DAG generation error or an extremely low hash rate. GPUs possibly compatible with lnxd/phoenixminer:latest-20.20: (click to expand) GPUs possibly compatible with lnxd/phoenixminer:latest-18.20: (click to expand) GPUs possibly compatible with lnxd/phoenixminer:latest-15.12: (click to expand) GPUs possibly compatible with lnxd/phoenixminer:latest-20.45: (click to expand) FAQ: (not necessarily by real people 😂) Q: Where can I find more arguments to use in additional? A: The output of ./Phoenixminer -help for 5.6d is available here. Q: I have multiple GPUs, can I use this container? A: Yes! If you have multiple GPUs, and they are all listed in one table, go for that version. If you have multiple GPUs and they are on different tables, you can have multiple containers on different tags and use the -gpus flag in PhoenixMiner to set which container uses which GPU. Q: What are the mining fees? A: There are none from me. The developer of PhoenixMiner charges 0.65%. This means that every 90 minutes the miner will mine for them for 35 seconds. The default pool, Ethermine, has a 1% fee and shares the transaction fees from the block. You can change to mine on any pool. Q: Why is my card still heating up if I've set a target temperature (tt)? A: PhoenixMiner seems to still rely on the default fan curve, so unless you've optimised that for mining it's probably best to set a fixed fan speed by setting the tt value to a negative, such as -70 (fixed at 70% fan speed while PhoenixMiner is running). The lower you can safely set this, the slightly less power your rig will use and the less the affect mining will have on your GPU fan's lifespan. Q: Why am I getting such a low hash rate (eg. 2.5MH/s)? A: Could be a lot of things, from the card having a very low power limit set, to trying to use a fake card. But the most likely issue is that you're using a card without enough VRAM. 4gb cards are not really suitable for Ethereum mining, please see the Compatibility section above. Q: Is there an easier way to see the data from the Unraid WebUI Dashboard? A: Yes! Users who have ich777's Radeon TOP installed can also install b3rs3rk's GPU Statistics plugin from CA. This will allow you to see things like the GPU temperature, load, fan RPM of one GPU at a time. Please note that it is expected for memory usage to be only around 4gb, as this is the current DAG limit. Q: Does this also work with NVIDIA cards? A: Shh! Yes it does. I don't know enough about the NVIDIA drivers in Ubuntu yet to list a compatibility chart, but thanks to some testing by ich777 I have confirmation that lnxd/phoenixminer:latest-20.45, lnxd/phoenixminer:latest-20.20 and lnxd/phoenixminer:latest work with a GTX1060 6GB. The same limitations with regards to VRAM apply as AMD cards, 4gb cards won't work. Screenshots: Feel free to comment here if you need any assistance.

Looks like we're in the same boat. I did a search on here and there's a couple of posts with people asking for this functionality before they started including the AMD drivers which made it possible. I'm also pleased to see there wasn't any backlash from posting this so I might see if I can apply tonight. It would be possible, and luckily passing /dev/dri doesn't seem to lock the device, the host can still use it and you can even pass it to multiple docker containers. The good news is that most miners already have arguments/flags that let you limit the GPU, eg. for PhoenixMiner: -gpow <n> Lower the GPU usage to n% of maximum (default: 100). If you already use -mi 0 (or other low value) use -li instead. You may specify this option per-GPU. -li <n> Another way to lower the GPU usage. Bigger n values mean less GPU utilization; the default is 0. You may specify this option per-GPU. It would be risky to implement a hard limit though, as these mining applications are usually designed to be in charge of the GPU, including OC and GPU reset, etc. and it depends on the skillset of the mining application's developer as to how they implement these functions. Most of these mining apps are closed source which makes it much more time consuming and risky. I think it's best to leave it up to the built-in arguments. After running it for 6 days I haven't had any unexpected behaviour at all so I think it's just about ready 😄 Edit: This is now on CA for anyone who is interested, lnxd/PhoenixMiner-AMD

Great point. I recently changed to Wireguard from passwordless ssh and it’s super easy with that plugin.

What Squid said. Your logs are full of thousands of attempts to SSH (and sometimes Telnet) into your server. Looks like it was a successful bruteforce attempt via a botnet. Also you're right about the container, it's mining Monero. Not comprehensive and there's probably some better guides out there but just some suggestions based on your situation: Now that you know it's not isolated, make sure you isolate the server from the internet. Whether that takes putting it behind a router or (if it already is) disabling port forwarding to SSH this is the main reason you were compromised Change your root password, someone knows it Update to 6.9.1 unless you're holding off for a reason Enable HTTPS on your Unraid instance if you haven't already to prevent your root password being leaked to your network if you log in via a web browser. I'd still do this even if you trust the security of the devices on your local network, because you never really know. Be extremely cautious in both the short and long term and check your configuration and data for signs of manipulation. If someone has been able to ssh into your root account and add a docker container, they could have done just about anything. Restarting Unraid after the event could hide the signs of it. You can do this using something like ClamAV but I'd also recommend going through it by hand. Keep in mind that recent modified dates / created dates can be manipulated. Check /boot/config/go for anything you didn't put in there, it doesn't look like this was an Unraid server specific attack but this is the most obvious file someone would use to set up persistent key based (to get around password changes) ssh access. Once your server is no longer exposed to the internet, it shouldn't be an issue anyway, but just to be safe. If you haven't yet / don't want to restart your server, delete /boot/config/ssh/authorized_keys to reset authorised ssh keys (used for password-less SSH login) Really just a comfort thing: If you're on a dynamic IP and don't use a dynamic DNS service, get a new IP from your ISP to (at least temporarily) stop the constant attempts. If you are using a dynamic DNS service, keep in mind that you're currently a target and it might be best to change your address. If you're on a static IP, like I said it's really just for comfort anyway because, to reiterate, once the ssh service is no longer exposed no one should be able to remotely ssh into your server Never port forward to port 22. If you need external ssh access, change it to another port. A lot of malicious scripts just scan a list of IPs to see which have port 22 open and then try to bruteforce their way in, most likely this is what happened to you. Also, keep an eye out for unexpected traffic from your server. There's a real possibility it's part of the botnet now.

Hey guys, Before I do an application for my container to be added to CA, I just wanted to get the general community's opinions on the idea. I wasn't having any luck getting my 5500XT to pass through to a VM without causing a whole bunch of issues, so since LimeTech have kindly gone ahead and included amdgpu driver support in the newer versions of Unraid, I spent the afternoon containerising PhoenixMiner so that the card is at least used for something. Since PhoenixMiner is closed source and a little controversial at the moment, I'm just going to note that it is extremely easy to change it to most other linux supported miners (eg. teamredminer). On my Unraid server personally, there shouldn't be any ill effects of letting it mine. My hard drives are all stored in a cooled enclosure enclosure separate from my PC, I have an overkill RM850x PSU, good airflow, and my server runs off a 1500va PSU. I've also been letting NiceHash mine in an NHOS VM when my other GPU isn't in use now for a few weeks without any noticeable side effects. That said, I'm sure there is a lot of hate here just like everywhere for the mining community, and with the potential risks (eg. users overheating their storage devices in a storage oriented OS) I wanted to leave it up to you guys to decide whether this is something you want to see in CA or not. I've set the poll to a week just so that I have the opportunity to confirm it doesn't cause unexpected shutdowns, etc. but if anyone needs the code urgently it's on dockerhub. Also please don't judge, it's the first container I've ever made public 😅 EDIT: I should note, I know ptrfrll has trex-miner on there, but that only works with Nvidia cards as far as I could tell. This is for AMD cards.

Has anyone had any luck getting the vendor-reset patch to work with a 5500 XT? I have a brand new Asus ROG Strix Radeon RX 5500 XT 8GB card that is failing to reset on a patched kernel. I've hijacked someone's GitHub issue here but just wondering if anyone has managed to get it going. I'm on 6.9.1, kernel built using ich777's kernel builder that has the vendor-reset patch applied, works perfectly with my RX 580. Luckily it doesn't crash the whole system like it does on the stock kernel, but I do need to restart my entire server between troubleshooting attempts because while I can start VMs etc. the card is still getting stuck.

Thank you! This is just what I was looking for. Just one small bug that's easily worked around that affected both AMD cards I have: they are named Radeon RX 470/480/570/570X/580/580X/590 and Radeon RX 5500/5500M / Pro 5500M. This causes the script to try to save a file as eg. "/mnt/user/appdata/isos/vbios/Radeon RX 470/480/570/570X/580/580X/590" which of course on a linux based system doesn't work. The script then fails and causes a generic error, there's a few issues on the repo's GitHub page that look like they could be due to the same error as well. The affected line is #294. It's not like @SpaceInvaderOne didn't warn me via the Readme that it will try to make a name before I wasted about 20 mins on the wrong path 😅 Maybe next time I'll read the documentation more closely. Until @SpaceInvaderOne has a chance to review it, all anyone with an AMD card needs to do is set the "vbiosname" variable to a suitable name.

Hey guys, ich777's kernel builder solved it for me. He's made it very straight forward: 1. Add the container via community applications and select the options you want. Deselect anything you don't need but mark vendor-reset as true, it will compile a kernel for you 2. Back up your existing kernel just in case (download a dump of your flash drive via the GUI), copy the generated kernel files from the output folder to the root level of the flash drive, overwriting the existing ones. 3. Reboot You'll see the discussion I had with him in that post as well, I had to change to a legacy boot mode to get my Asus RX 580 OC working in VMs but that might depend on your other hardware. It's working fine for me on 6.9.0, I haven't upgraded to 6.9.1 just yet, but I'll be doing that shortly. My understanding is the vendor-reset patch is still technically in Beta, but I'm hoping Unraid devs can move to include it in the kernel soon as it's pretty much impossible to use anything other than brand new AMD GPUs with Unraid otherwise. EDIT: Just upgraded to 6.9.1, still works like a charm with my RX 580.

Booting in Legacy mode fixed that problem as well. Thank you so much! You saved me giving up on using GPUs in my Unraid server! I was ready to go out and buy a second PC. I wonder if there is something wrong with my GPU that makes it crash so often 🤔 but at least now I can start to investigate the underlying problem without putting my data at risk and bothering my family. Thank you so much!!!!!!!!! Edit: I can't believe it, I've started and stopped VMs 5-6 times while setting up an underclock, the GPU has even crashed a linux VM, and I haven't had to restart the whole server once. Wooh!

No worries, I feel you. Might be worth checking out DOSBox if you haven't already come across it, but there's no harm in spinning up a VM. Just keep in mind that Windows XP has a few security issues so I'd keep it nice and isolated 😉

No worries. I'm leaning towards it being possible, your CPU (i3-3245) supports VT-x. If you jump into your motherboard's bios you should be able to enable virtualisation. According to section 2.2.2 of your motherboard's user guide it's under Advanced, just make sure you set Intel Virtualization Technology to Enabled and you should be set. Let me know how you go 😄 Edit: Probably also wouldn't hurt to make sure Hardware Prefetcher is also enabled from the same screen, looks like it is by default.

You mean first ever VM install on this system right? This error could indicate that you have emulation disabled in your bios, or even worse, that your system does not support emulation. Please post your diagnostics file if possible otherwise I'll be asking you a million questions 😅

I was just about to give up on getting my RX 580 to not take down my whole server all the time when I saw this in my system log: root@server:~# dmesg | grep vfio [ 105.052090] vfio-pci 0000:01:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=none [ 107.282570] vfio-pci 0000:01:00.0: enabling device (0002 -> 0003) [ 107.282661] vfio-pci 0000:01:00.0: AMD_POLARIS10: version 1.1 [ 107.282662] vfio-pci 0000:01:00.0: AMD_POLARIS10: performing pre-reset [ 107.295589] vfio-pci 0000:01:00.0: AMD_POLARIS10: performing reset [ 107.295594] vfio-pci 0000:01:00.0: AMD_POLARIS10: CLOCK_CNTL: 0x0, PC: 0x2b4c [ 107.295595] vfio-pci 0000:01:00.0: AMD_POLARIS10: performing post-reset [ 107.321575] vfio-pci 0000:01:00.0: AMD_POLARIS10: reset result = 0 You are amazing ich777! The only problem I'm having now is that VMs seem to crash during launch with the GPU selected 😅 funny how that seems like a smaller problem. I can see it says that there are no available reset mechanisms. I've attached the logs from a fresh Windows 10 VM. Do you guys have any idea what's going on? doonserver-diagnostics-20210306-1948.zip Windows-10-logs.txt