So you build your Kotlin app, you went through the trouble of creating a build.gradle script that you build with
this outputs a a “build/libs/kotlin.jar” .jar file, but you have no clue how to run your Kotlin code from the command line.
Doing it by hand with “java -cp
gradle -b /home/myuser/mykotlinapp/build.gradle run
in case you need to run your Kotlin script from a cronjob.
Make sure you have the following inside your build.gradle script in order to make the “run” task available
apply plugin: 'application'
// DO notice the "Kt" suffix on the class name below, if you don't use the Kt generated class you will get errors
mainClassName = 'com.myapp.MyKotlinAppKt'
// optional: add one string per argument you want as the default JVM args
applicationDefaultJvmArgs = ["-Xms512m", "-Xmx1g"]
What if I don’t want to use gradle, and just java
java -cp $KOTLIN_LIB/kotlin-runtime.jar:build/libs/kotlin.jar:
so you cloned the cgminer repo from github to build on your OSX machine and you get this bullshit error
readlink: illegal option -- f
usage: readlink [-n] [file ...]
usage: dirname path
touch: /ltmain.sh: Permission denied
Use of chdir('') or chdir(undef) as chdir() is deprecated at /usr/local/bin/autoreconf line 670.
./autogen.sh: line 10: /configure: No such file or directory
readlink works differently in OSX and the current version of the autogen.sh script seems like it wasn’t tested on OSX (wonder why didn’t they use a simple bs_dir=`pwd`, the answer is probably canonical paths and what not).
To keep moving along, open the autogen.sh script and just change the value of the bs_dir variable to the full real path of where you have cloned the cgminer source code.
then execute your autogen script, make sure to enable compilation flags for your ASIC hardware, in my case I remember seeing ‘icarus’ on a binary build of cgminer I tried before, so I did
you might want to enable all of them if you’re not sure what hardware you have or you will have in the future as you may not like the joys of building software (check out the the README for all the –enable-xxx options available)
If you’re getting errors on your configuration script due to missing dependencies, I strongly recommend you use Homebrew to install these packages (if you are using Macports or Fink, I strongly suggest you completely remove that crap from your computer and go 100% with brew, it works really well if you’re building a lot of code on a regular basis):
brew install autoconf automake autoreconf libtool openssl curses curl
brew, at the point of this writing didn’t have libcurl, so that one you will have to download, ./configure, make and sudo make install yourself from here http://curl.haxx.se/download.html (I used version 7.34 when I did it)
after that the autogen script should work, and then you should be just one ‘make’ away from your goal.
As great as EBS volumes are on Amazon Web Services, they can break and not ever mount again, even though your data could still be there intact, a simple corruption on the filesystem structure can cause a lot of damage. On this post I teach you how to move all that data onto a new EBS drive, so keep calm and read slowly.
So, you try to mount your drive after some updates and you get an error like this on dmesg | tail:
[56439860.329754] XFS (xvdf): Corruption detected. Unmount and run xfs_repair
so you unmount your drive, invoke xfs_repair and you get this…
$ sudo xfs_repair -n /dev/xvdf
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock...
and no good secondary superblock is found.
Don’t panic, this is what you have to do next to solve this issue:
- Go to your AWS dashboard, EC2 section.
- Click on “Volumes”
- Find the broken volume.
- Create a snapshot of the broken volume (this takes a while)
- Create a new volume the same size (or larger than) your old drive out of the snapshot you just created (this takes a while)
- Attach your new volume to the same EC2 instance (no need to reboot or anything), if the old drive was mapped to /dev/xvdf, the new one will be mapped to /dev/xvdg (see how the last letter increases alphabetically)
Now here’s a gotcha, Amazon will not create your new drive using the same file system type (xfs), for some reason it will create it using the ext2 filesystem.
$ sudo file -s /dev/xvdg
/dev/xvdg: Linux rev 1.0 ext2 filesystem data (mounted or unclean), UUID=2e35874f-1d21-4d2d-b42b-ae27966e0aab (large files)
Here you have two options:
1. Live with the new ext2 file system, make sure your /etc/fstab is updated to look something like this:
/dev/xvdg /path/to/mount/to auto defaults,nobootwait,noatime 0 0
or 2. copy the contents of your drive to a temporary location, usually inside /mnt which has plenty of space from that ephemeral drive the ec2 instances come to, and then mkfs.xfs the new volume, and then copy the contents back… (which what I did, as I chose to create a larger drive and the ext2 format that came on the new volume only recognized the size of the snapshot)
Hope this saved your ass, leave a note if I did.
Remember to never do any irreversible action until you have a disk snapshot, try your best to never lose data.