Just added Preliminary support for “Cryptonight Heavy” (Sumokoin v1)

While getting my morning coffee earlier today (long night yesterday – very long night …) I got an email by one of my users, asking about whether I’d ever planned to add support for mining Sumokoin, and in my ignorance replied right away with “sure, I support that for a long while” … hm. In retrospect, that answer probably didn’t sound all too intelligent, for the simple fact that I had completely missed the news that Sumokoin (or “Sumo” for short) had recently also done an algorithm fork similar to Monero, with yet another algorithm (called “cryptonight heavy”)…. and until he told me about it I hadn’t even known about it. Well, guess I didn’t earn the biggest mark of excellence on this one…

Anyway – after I finally did realize that I had simply been a rather ignorant fool in my first reply I had a look at this new “cryptonight heavy” thing, and have to say, it’s actually quite an interesting modification: Unlike the rather cosmettic “v7” modifications that monero did this really did some major changes. In particular, “heavy” changes the scratchpad size from 2MB to 4MB per thread, which means that it’s now “heavy” indeed in its cache impact. Still, the effort to code this up didn’t look all too awful, so I looked up the profit estimator on whattomine to see if it would even be worth it … and looks like it actuallly did: with so few miners out there, and with such a heavy cost on regular cpus, the profitability of this “new sumo” is now way higher than other coins (long may it last…). So with that, I finally did sit down and implemented the changes – which after all the recent re-orgs to support turned out to be relatively little work.

Long story short: I just uploaded a new version (v0.10.2) to the usual place (http://www.lukminer.net/releases) that has preliminary/experimental support for this “xnheavy” coin type. “Preliminary” in that case means that there’s still some loose ends – in particular, I currently support this coin time only for the cpu, phi, and mpss-knl miners; and knc-native, mpss-knc, and ocl will, for now, simply refuse to run if you tell them to mine heavy (of course they’ll still run the other algorithms, though). For cpu, phi, and mpss-knl variants I’ve now tested for several hours on pool.sumokoin, and it seems to be working out of the box. Performance on CPUs is way lower than old cryptonight, because with the larger scratchpad you can only use half as many threads. On the KNLs (7210, 7220 etc) performance is way better – still about 20% slower than old cryptonight, but that’s still quite tolerable. In fact, with just three (admittedly rather hefty) machines I currently seem to be making about 5% of the pool hash rate on pool.sumokoin.com, so it can’t be all that bad ;-). To give you an idea: I currently get about 2500H/s on a 7210, and about 18kH/s on the 8×7220 “monster” machine I described in that past article

To run: download the latest 0.10.2 release from http://www.lukminer.net/releases, unpack, and run with the “-a xnheavy” or “-a sumo” flags, for example like that:

./luk-phi -a sumo --host pool.sumokoin.com --port 4444 --user Sumoo6SgKXMD8NcBFzqB1QBzmRPiLeJxFPUmcy7tfM88br8y76G6EGTi8ireo3dy1VcSiK5sVKB4wbpcHtCu32RLBGMbZ1Nbfx3

(you should of course change the –user field, though I won’t complain if you don’t 🙂 ).

I think there’s also some other coins that have adopted this algorithm (somebody asked earlier today), and if they do say that they use “cryptonight heavy” then it should actaully work – but I haven’t tested anything other than Sumo, so no guarantees. If you do find one and happen to try it out, feel free to share!

With that: Happy mining!

PS: Yes, of course I’ll add opencl and knc support ASAP…

 

 

New lukSticks (v0.10.1)

How-dee everybody. As some may already have seen I “recently” (well – already several days ago by now) pushed some new “lukStick” images to the releases page. For those that read this for the first time: this is at http://www.lukminer.net/releases .

I actually wanted to write about this new release right after I uploaded (and apologize to those I confused by not doing so, because they actually change a few things :-/), but then goto side-tracked… apologies, too much to do :-/. Either way, in this blog I’ll try to summarize the latest changes, all of which were driven by feedback from users.

Re-Cap: The lukStick

For those that haven’t read the previous article and/or discussions on the lukStick, here a very brief re-cap of what it’s supposed to be about (for those that already do, feel free to jump to the next section!).

The core idea of the “lukStick” is to provide a single ISO image that is a fully installed linux with the miner pre-installed, ready-to-go, and auto-started upon boot time. This was initially driven by my own “experience” (say: annoyance?) at having to re-install machine after machine after machine, doing the same things all over again, etc, and losing tons of time because I always forgot one little detail, etc. Also, I realized that many of my readers might simply not have the experience of dealing with linux at all; let alone with auto-starting the network, miner, etc; let alone dealing with installing and starting MPSS stacks for KNC and KNL PCI cards; etcpp.

As such, I eventually decided to try to build (and it worked like a charm!) a single bootable USB stick that had all of that installation work done, and simply clone it every time I got a new machine. And in addition to making life easier in setting up a new machine this had the added benefit of allowing to use any “barebone” server (e.g., the Asrock Machines) without ever having to get or install a disk for them…

Be that as it may;  that thing turned out to worked pretty well at least for myself, so eventually I eventually decided to generate ISO images of those sticks, and share them as well. Sharing for others required a few additional changes (users, passwords, ability to change pool/user setttings, etc), and not unexpectedly, a few rough edges have been reported since. This release is supposed to fix at least the most egregious ones of those.

The new lukSticks (v0.10.1)

The most obvious change to the new lukSticks is – who’d have guessed – that they update the miner to v0.10.1, which is the one with support for XMR v7. As such, this update to the sticks was way overdue even without the additional changes, becuase starting 6 days from now (ie, after the v7 fork) you’ll actually need this new version to mine XMR.

However, the new stick isn’t just the old one with an updated miner, but actually contains several additional changes as well that were triggered by feedback from you, the users. In particular, on a high level:

  • There are now three version of the lukStick, for “cpu and/or phi”, “knc with mpss” and “knl with mpss”, respectively (see below).
  • All three sticks are now “homogenized” in the sense that they all use the same user, password, ssh key, directory structure, startup method, location of config and output/log files, etc.
  • User/password: All three lukSticks now only have a single user (root), and the same password (luk) for that root user. Ie, no more confusion on which users/password to user for which stick, how to sudo, etcpp.
  • Remote login: All luksticks now allow remote ssh login, using either password or ssh key (I’ll upload the public/private ssh key soon). In particular that should allow for more easily “remote control”ing many different servers via remote ssh calls.
  • Homogenized file naming and directory structure: In all three lukSticks the relevant ssh keys are not in /root/.ssh, the config file in /mnt/fat/mine.cfg, etc. This again should make it easier to, for example, “bulk” change the miner config on a large number of machines.
  • At least the “cpu-phi” and “mpss-knl” method will automatically print miner output to console tty1; so no more need to first login before you can see the miner status. (note this feature is intentionally disabled on the mpss-knc version, since the MPSS “mic” kernel module throws a kernel panic when enables (ugh!).
  • The partitions have been slightly shrunk, so even with USB sticks that have a few  broken sectors (ie, which in the past were slightly too small for the ISO image) you’ll no longer get broken partitions.

Now with these high-level changes, a few more details below:

Which lukStick to Use?

There’s now three flavors of lukSticks, for the three different configs that exist:

  • lukStick-phi-cpu : This one works for both regular CPUs and bootable Phis (it’ll auto-detect if it’s a phi, and fallback to CPU if not). Ie, that’s the one you want to use if you have one of the Asrock Rack, Exxact, Colfax, etc 2U4N servers; but you can also use it on any old CPU/Xeon server you may have lying around. Internally this stick builds on top of Ubuntu, which generally gets highest performance.
  • lukStick-mpss-knc : This version is designed for systems with the x100 “KNC/Knights Corner” Xeon Phi PCI cards; those require an install of the MPSS 3.x stack, which in turn requires the right version of CentOS, which in turn … you get the point. This stick has all of that pre-installed, using CentOS 6.9, MPSS 3.8(I think), and with everything auto-started and auto-configured (even the number of cards is automatically detected).
  • lukStick-mpss-knl : This version is for the select lucky ones that got some of the 7220 or 7240 PCI versions of the x200 “KNL/Knights Landing” PCI cards. Ie, it’s not for the Asrock Rack “bootable” KNLs (use phi-cpu instead!), but if you happen to have one of the 7240s that version should do the trick. As with the mpss-knl version this has the right flavor of Linux (CentOS 7.3), the right driver stack (MPSS 4.x), automatic card detection and configuration, etcpp.

Note I do not install NVidia, ATI, or whatever GPU drivers, so the luk-ocl miner will not work on thost sticks.

“Making” a lukStick

To make a new lukStick all you have to do is download the right image (see previous section), unpack the ISO image, and burn it on a 16GB (or larger) USB stick (in fact, a harddisk should work, too, though I haven’t tried yet). For those that use linux and are comfortable with the command line, this would work, for example, via

dd if=lukStick-<type>-<version>.iso of=/dev/sd<deviceName>

Note: Usually, you can find the “deviceName” to write to inserting a new, blank USB stick into a USB port, and then doing “dmesg” – which should show something like “new USB device X-Y-Z …. /dev/sdXYZ.

Warning: If you’re not familiar with linux, command line, dd, etc, you might want to use some graphical tools, or you might simply overwrite your main harddisk. Be careful! I’m also sure there’s some windows tools for that, but sorry, can’t help with that – I’m not exactly an expert in windows….

Configuring the LukStick to your pool/user/… settings

Once you “burned” the ISO image to a USB stick or harddisk, you should be able to mount this stick in either a linux or a windows machine. Under linux you should see two partitions (a ‘linux’ one with the linux, and a ‘fat’ one with the config files); under Windows you’ll only see a ca 100MB FAT partition.

The “FAT” partition is what contains the config files. Unlike previous versions this version of the stick no longer hosts the scripts themselves in this location (too easy to accidentally break, apparently), but instead contains a file “miner.cfg”. You can edit the respective host, port, user, etc values, and next time you boot they should automatically apply.  Make sure to properly unmount (“eject” under windows) to make sure your edits are saved!

Running the lukStick

Once burned you should be able to put the lukStick into any machine, turn it on, and automatically run upon boot (of course, this assumes that your BIOS is configured to actually boot from USB 🙂 ). I’ve seen some issues with UEFI vs non-UEFI systems (the sticks are “legacy” stick, and some UEFI systems apparently want to boot only UEFI devices!@#!@), but “usually” it should work. (In particular, all the Asrock Rack etc machines should work.

Of course, to actually run the miner the machine needs an internet connection – and while the miner will automatically start the network devices you’ll still have to make sure that there’s a proper physical network caple plugged into the right network port (on the Asrock Rack machines, for example, I usually use the right one of the two side-by-side ethernet ports – do not use the individual one next to those two, that one is only for board’s IMPI; the OS won’t even see it).

Monitoring Hash Rate / Miner Output

Upon startup it may take a while for all the services to start (in particular for the MPSS version that can take three or four minutes); but at least ont he cpu-phi and mpss-knl versions you should at some point see some miner outputs on the text console (assuming you do have a monitor connected, of course). Note this doesn’t work on the mpss-knc version (mic module throws a kernel panic when writing to /dev/tty1!?!), but does on the others.

In addition, all miner output is also written to /tmp/luk.out, so you can always login (remotely, if required, see next sec), and check that file as well. Also, to help debug any potential issues (ie, if the miner doesn’t start up), the startup scripts will write some debugging information (dmesg, cpu info, memory info, startup log, etc) to the FAT filesystem, from which you can inspect them (and/or send them to me if you need to).

Loggin in

At least for casual users you usually shouldn’t have to log in – as described above you can configure the miner with the “miner.cfg” file on the FAT partition – but just in case you do want/need to: All three lukSticks now have a unified user (root) and password (luk). Of course, three ascii letters for a password isn’t exactly NSA standard, so if you do plan on putting a machine with this stick onto an externally accessible IP: make sure to change that root password!!!!  (If you’re on a trusted network or behind a DHCP server and firewall, it shouldn’t matter).

If you do want to log in, there’s two three ways: Console, ssh via password, and ssh via ssh key. For console login, you’ll probably see rather quickly that the miner also prints its output to console 1, and that logging in / working on that console becomes a bit “confusing” with all those outputs. Simple fix: Press ctrl-alt-2 (or ctrl-alt-f2?) to swtich to another console (may take 4 or 5 seconds to open), then you can login/use this one.

For ssh login, you can either use the user/password I provided, or use some public/private ECDSA key. (I’ll upload that later today; until then you can pull it from /root/.ssh). All three versions have the same ssh key installed, so you can use the same ssh key to login (without password), and thus easily do things like remotely overwrite each machine’s mine.cfg with a new version, etc.

Summary

Oh-kay – that post was way longer than I had hoped it’d be, but hope it helps – there were a lot of people that tried the earlier lukSticks, and those most eventually got them to work some questions came up again and again – I hope this post will answer the most important ones up front.

All that said, I’m reasonably sure there’ll be some remaining teething issues even in this major iteration of the lukStick, so if you run into any, don’t hesitate to drop me a note. It may take a few days (weeks?) to fix it, but eventually I will …. (or so I hope).

As such: Happy mining!

Luk

 

lukMiner v0.10.1 with Monero v7 Support

Oh-kay, that turned out to be more work than expected… with cpu, knc, knl, and opencl versions all using different codes this “simple” thing of adding v7 support eventually turned out to be more work than expected. But hey, isn’t it always like that?

Either way – as of a few minutes ago I finally finished baking a new release (v0.10.1) that “seems” to run stably on the Monero v7 Testnet pool, for every one of the supported platforms: cpu, x100 phi, x200 phi, and OpenCL all seem to work just fine. As with all recent releases, you can download this relaese under http://www.lukminer.net/releases . And also as usual: please let me know if you run into any issues!

To use: When using “classic” cryptonight (sumo, etn, and monero before the fork): use the “-a xn” (or “-a xnclassic”) command line flag; for cryptonight light (aeon) use “-a xnlight”; and for Monero v7 use “-a xmr-v7”. For more details on usage – including some examples – also see the README.md at http://www.lukminer.net/releases.

Caveats/Remaining Issues

Though I’ve tested the above version quite a bit, a few issues are known to remain:

  1. This version can not (yet?) auto-detect whether we’re in pre-fork or post-fork times, so you have to specify the right “-a <xn|xmr-v7>” command line flag to produce the right hashes. If you don’t, you’ll produce invalid hashes, and at some point the pool you use will get angry. As such: make sure to switch your miner over to the new protocol as soon as – but not before – the hard fork hits (unless I manage to build an auto-detecting version before that, of course 🙂 ).
  2. Even if you use the right flags for the right pool, I do not yet know whether dwarfpool – where my dev shares go – will actually switch over to the v7 protocol automatically; nor do I know when they’ll do that, nor whether they’ll do that on the same URL/port, etc. Now if they do not simply switch the existing dwarfpool over at the right time (as one would expect they should!?), then the version you’d be using would try to submit invalid v7 dev shares to a not-yet v7 dwarfpool. If you do run into any such issues – or if you want to test the miner yourself on the testnet before dwarfpool switches over – then you can also use the “–dev-shared-on-test-net” command line flag: With this flag, all xmr-v7 dev shares will get sent to the (already existant) testnet pool on moneroworld, which should certainly accept them as v7 shares. (Needless to say, though, those shares get wasted, so better not use that flag after the hard fork is over :-/)
  3. Though I did update all the miner variants I have not yet updated the lukSticks. I’ll try to do this later this week…

As such: some issues remain; but at least the miner itself will already support v7 … and with another 9 days or so to go ’til the hard fork I’m reasonably optimistic I’ll get the remaining kinks ironed out ’til then, too!

With that:

Happy Mining!

PS: I’d like to hereby give a big shout-out to whoever set up the monero v7 testnet pool at http://killallasics.moneroworld.com/ … whoever that was: THANK YOU!

 

Monero v7, first light …

Just a quick heads-up, because so many of you are curious on support for the v7 hard-fork: it’s now Sunday morning, 12:37 am, and I finally finished getting a first implementation of this Monero v7 variant working…. and at least according to killallasics.moneroworld.com the generated hashes are actually correct.

I’ll still have a ways to go in cleaning up the code, fixing the opencl code, doing some more burn-in testing, and in particular allowing command-line switching between old and new protocol (currently it’s compile-time)…. but at least the lion’s share is done. So bottom line: Everything looking good for the hard fork in at the end of March ;-).

With that – happy mining!

 

 

MPSS Version for x200 machines

Hey,

Though this will affect only a small portion of my readers (after all, the 7220 cards are pretty thin on the ground….) I still wanted to share this, because it’ll probably make at least some peoples’ days: Finally found a night earlier this week where I sat down and tried to build an MPSS offload version for the 7220 cards as well…. and who’d have guessed, when starting out with an MPSS version for the x100s it actually worked out pretty well.

Now the main reason I did that is that previously I had to jump through all kind of hoops to run the phi binary “natively” on those machies, with automated ssh scripts to start mpss, copy the miner to the devices, forward ports, kill/restart if required, etcpp…. pain in the ….. well. And of course, with the MPSS version all of that is gone, because the miner itself just runs on the host, and all the offloading is done by MPSS.

Anyway – the second reason I did that – and the thing that at least some here will enjoy – is that it’s always been bugging me that when running in native mode the 8 cards actually appear on pools as eight separate machines …. and I so wanted to at least once see an output of “24kH/s” in that miner’s output… And now, with the MPSS mode all the cards now indeed do work together in a single miner, so here it is:

24kh-output

And even more fun than that, here’s the corresponding screenshot from NiceHash… in particular, have a look at the difficulty column *G*.

nicehash-high-difficulty

Since that mpss offload version has pretty steep dependencies on OS version, MPSS version, etc I’m not going to put that into the public release; however, I already created a lukStick version of it, so if anybody does have some machines with x200 cards: let me know; I’d be happy to share that stick.

With that,

Happy Mining!

 

Upcoming Changes: Monero Hard Fork, Different Crytponight flavors, and Renamings …

Good morning, everybody!

As some of you may have heard there’s currently a certain “buzz” of excitement around the monero community, all relating to the upcoming “hard fork” – and though it’s actually surprising to must just how little is yet known about this upcoming change, I wanted to at least assure everybody that yes, of course I will update lukMiner to work with this hard fork.

Why is this “hard fork” such a big deal?

Now before saying anything else, let me go a bit into why this hard fork is such a big deal. Hard forks are nothing new to altcoins, and in fact, most coins are just  forks of a very small family of core algorithms (e.g., Monero, ETN, Sumo, etc are all just variants of the same cryptonight algorithm). Even for a given coin, hard forks are not necessarily a big deal: Yes, sometimes these hard forks lead to “splitting” of coins if only some of the community adopt these changes – e.g., ZEC (ZCash) and ZCL (ZCash Classic), or ETH (Ether) and ETC (Ether Classic) are both the effect of a given coin (e.g., ETH) having hard forked, and some continuing to mine the old, “classic” coin on the old blockchain with the old algorithm; while others use the new code on the new, “forked” blockchain. It’ll be interesting to see if this’ll happen to monero, too; though at least right now it looks like at least in this instance it probably won’t (we’ll see).

Even if it does not lead to a real “fork” into different coins, hard forks in a given coin’s codebase are nothing new – Monero alone had 6 or so in the past, and usually they’re not too big a deal: usually it’s some sort of bugfix or vulnerability fix that can’t be done in a backwards-compatible way; it usually gets adopted by everybody that runs a node, and that’s it. No big deal.

Now this time, unfortunately, the changes that are being discussed relate not only to the code affecting the nodes themselves, but to the actual hashing algorithm behind monero itself. In particular, this has two really big implications: First, it means that it will affect everybody that mines monero: If only the node code changes (as in the past) then it’s only those that run their own nodes that have to update; and in times where you pretty much have to use a pool, anyway, that means the burden on updating in the past was almost entirely limited to pool owners. This time, it’s the miners themselves that have to change; and it’s not only the all the miner developers (such as I) that have to change their codes, but also all the actual miners (i.e., you) that have to update to those new versions. So if you’re reading this, be prepared that you will have to update to the respective version of lukMiner as soon as this hard fork takes effect (and no, I do not know when that will be, yet).

The second big change – and maybe even more of a pain in the … ah, backside … that most people seem to not even have realized yet is that this means that this probably you will no longer be able to interchangeably miner different cryptonight coins with the same hashing algorithm: In the pre-fork world, the same miner could mine both XMR, ETN, SUMO, NiceHash, BXN, and a ton of other codes. The upcoming change however is a change to Monero, not to the cryptonight algorithm itself, and as such, it’s totally unclear which other coins (if any) will adopt this change. That sounds benign, but probably isn’t, as it creates all kinds of “collateral damage” questions: For example, will Nicehash switch its “cryptonight” over to the new Monero algorithm? Or will they (have to) add an additional algorithm just for Monero? (And if they do, what about all those NiceHash users that bought cryptonight hashes to mine monero?). Or in fact, does Nicehash even still make sense if you can no longer trade the same hashes for the most profitable coins?. It’ll have similar questions for sites like WhatToMine (can no longer compare different cryptonight algorithms), etcpp. Lots of questions, and so far, few answers.

Even for us devs, there’s a lot of potential “collateral damage”: For example, right now I can steer all my dev shares to dwarfpool, because it doesn’t matter which coin the users mines; the hashes are the same. After the hard fork, I (as well as every other miner dev) will have to track different accounts, and send the dev shares accordingly. Not a big deal, you say … BUT: what if somebody keeps on mining with older version of a miner that hasn’t been updated yet? As long as he mines only coins that haven’t changed he’s fine – but suddenly, lots of “wrong” shares will be routed to the (old) dev share accounts, which I’m sure DwarfPool won’t be all too happy about….

Anyway; the fork is going to happen, and despite all my whining above it’s probably a good thing: ASICs do take a long time to develop, test, tape in, test again, produce, test again, and ship; while software can be changed in a few minutes. As such, changing the mining algorithms – albeit but slightly – will be a very good deterrence against ASICs, and that in itself is a (very) good thing. I’d wish for a bit more transparency and information about very basic questions like “what actually will change … and when?” – but overall, it’s still a good thing. (And please note, it’s also a good thing for you, the users: The biggest threat to your investment in CPUs, GPUs, and Phis for mining is ASICs!).

Upcoming Changes to LukMiner

So, enough of that whining – what does it mean for you, the users? First of all, yes, I most certainly will produce a version of lukMiner that will adapt to the hard fork. And yes, I’ll do that as soon as anybody can tell me what the changes will actually be (so far the Monero devs don’t answer, and there’s no changes in the public codebase visible, yet, even in branches). But it likely won’t be much that’ll change – if all you want is thwarting an ASIC the changes could be trivially small – so I fully expect to have a fixed version the same day I get info of what those changes are. After all, I have a fair amount of machines running on both Nicehash and specific “classic” cryptonight coins (ETN, SUMO), and (currently) all my dev shares on Monero… so even if it wasn’t for my own commitment to you, the users – I’d better have something quick.

Second, I will likely change the miner to no longer have different binaries for aeon vs xmr vs new-xmr, vs xyz; and instead have a single miner that can select the algorithm on the command line (there’s already way too many different binaries; I don’t want have yet another). Most likely, this will take the form of “-coin <name>”, where “name” will be name of the coin to miner (eg, xmr for monero, aeon for aeon, etn for Electroneum, etc). Eventually I’ll also try to merge in all the different opencl vs mpss vs cpu vs phi vs knl binaries into only two different binaries … but that can wait. Either way, you’ll have to update your mining scripts. (I’ll post detailed info as soon as I release the updated miner).

So; enough for today. Bottom line: Big changes are coming; let’s see how they’ll play out – but overall they’re probably for the long-term good; and I’ll certainly support them from day one. With that:

Happy Mining!

 

(luk-)Mining made easy – The “lukStick”…

(Bottom line: here’s a ready-to-go iso-image that’ll turn a 16GB USB stick into a self bootable linux-‘disk’ that’ll automatically run lukMiner – so you can run your Phi nodes without the need for buying disks or installing linux’es…)

With all the interest in the Asrock machines, one question that came up again and again is “if I do get one of those machines, what else will I need to mine on it” … after all, this machine has been stripped of many things including disks and memory, and even by Asrock is sometimes called a “barebone” – so maybe this question isn’t all that surprising.

Now “in theory”, the one single thing this machine was missing is a pair of harddisks, and, of course, a software install on those disks that will actually contain and run the miner. And sure, you can get such disks for $10 a pop on Newegg – but the software install can be a little bit more of a pain, in particular for those among us that aren’t enough of a Linux experts to do things like auto-starting the miner, etc (and even for those among us that have done all of that before, it still takes a lot of time to do all this).

As such, from the very beginning I had promised I’d look into coming up with something that would be a bit easier; possibly using a bootable USB stick that would automatically run the miner…  Now when I first floated that idea I got lots of positive feedback (in fact, one user even offered to “buy” those sticks!); but it did take a while to make it work.

Anyway – today, without further ado, I present to you – ta-daa – the “lukStick” …. the best invention since sliced bread, a cure against all illnesses, and …. well, maybe not all that good, but hopefully still useful! In all seriousness: the “lukStick” is nothing but a ready-to-go Linux image for a 16GB USB stick; bootable, with the miner started automatically, and a separate dos/fat partition that contains the config file (for those users that are more comfortable with dos/windows machines 🙂 ). And no, you won’t have to pay for it – if you absolutely want to I will of course take donations, but you most certainly won’t have to ;-).

So, without further ado, here’s what you have to do

  • get a bunch of 16 GB USB sticks (you can get them for $5 a pop on NewEgg; I took the Cruzer 16GBs)
  • download the latest image from http://files.lukminer.com/lukStick-latest.iso.gz
  • unzip the downloaded image
  • take a USB stick and copy that .iso image onto it (I use ‘dd’ under linux, but there’s probably windows tools for that, too)
  • Once the iso image is burned, take the USB stick out, and plug it back in; this should mount the fat partition that contains the “mine.sh” script. Edit that script to use your own pool, port, address, etc.
  • Plug the stick into an Asrock KNL box, turn it on, done.

Of course, the same stick will also work in the Exxact boxes; however, you may have to take out the disks to make sure it actually boots from USB first (the Arock machines don’t have disks, so will boot from USB automatically).

The Stick has a complete Ubuntu 17 on it, so once it’s plugged in you won’t need any harddisk any more – meaning it’s all you’ll ever need to make the Asrock machines go. Also, the miner is preinstalled on that stick, and will get started automatically upon boot. Oh, and of course, there’s no reason whatsoever why this would/should be restricted to the Asrock machines, or even to only Phis … you can of course change the mine.sh script to also use the ‘cpu’ miner, and run that on any machine you want.

With that:

Happy Mining!