[OS] nvOC easy-to-use Linux Nvidia Mining

[martyroz]

Will there be another ISO version after 2.0? I'm not confident in the process to convert to beta 2.1

[Brainfruit_Me]

One of my rigs keeps getting an error thought It seems to have been set up identically to the rigs that are already running
here's the error:

/home/m1/2unix: line 44:  2100 Terminated             bash '/home/m1/3main'
nvoc v0019-2.0 - Community Release


Then it just tries to keep cycling the miner to the same error..
Maybe I sshould just re-image the drive?

Also what is the password for Teamviewer? I tried root. No luck

That's not an error,
It's 3main getting restarted check your coin and miner
setting and variabless see if miner start is successful or not

I fixed that issue, I forgot to capitalize dmSL.
SO now the miner will start running for about 2 minutes, connect to the pool begin mining and then unexpectedly freeze and relaunch the miner.
It's been doing that for the last couple hours relaunching miner then rebooting rig.

Finally now it seems to be running stable for about 10 minutes while I was typing this reply. I made no changes so not sure the problem. Z-Enemy miner unstable?

**EDIT: been running stable for a few hours now**

[papampi]

Will there be another ISO version after 2.0? I'm not confident in the process to convert to beta 2.1

Sure when beta testing is done and after stable release

[papampi]

How can I mine eth and smart? I have claymore 11.7 on my ovoc but i'm not sure what else I need to do for this to work. Thanks

Have a look at 0miner for dual modes and add one with the changes needed,
Some thing like this:

Code:

if [ $COIN == "DUAL_ETH_SMART" ]
then
  HCD=/home/m1/eth/claymore/$CLAYMORE_VERSION/ethdcrminer64
  ETHADDR="$ETH_ADDRESS/$ETH_WORKER"
  if [ $DOT_POOL_FORMAT_or_FORWARD_SLASH_POOL_FORMAT == "DOT" ]
  then
    ETHADDR="$ETH_ADDRESS.$ETH_WORKER"
  fi
  DADDR="$SMART_ADDRESS.$SMART_WORKER"
  screen -dmSL miner $HCD -epool $ETH_POOL:$ETH_PORT -ewal $ETHADDR -epsw $MINER_PWD -dpool stratum+tcp://$SMART_POOL:$SMART_PORT -dwal $DADDR -dpsw $MINER_PWD -dcoin keccak -allcoins 1 -allpools 1 -dbg -1 $ETH_EXTENSION_ARGUMENTS
fi

Set your coin in 1bash
COIN="DUAL_ETH_SMART"

Dont forget to set the address for both in their sections

You can also use 19-2.1 beta for a much easier way, or wait for 19-2.1 stable.

[StigHelmer]

All my rigs are having the same problem -

Mining starts fine, cards get kind of hot pretty fast and then one by one they stop and I get an error saying "GPU0 appears to have stopped, attempting restart"

All fans are working, and occasionally one fan will seem to be working super hard.

I do not have any max temp settings enabled.

Any ideas? Thanks!

[papampi]

All my rigs are having the same problem -

Mining starts fine, cards get kind of hot pretty fast and then one by one they stop and I get an error saying "GPU0 appears to have stopped, attempting restart"

All fans are working, and occasionally one fan will seem to be working super hard.

I do not have any max temp settings enabled.

Any ideas? Thanks!

Set the TARGET_TEMP, so that temp control can lower power limit if it can not achieve that temp by fan speed and start lowering power limit.
Check which GPU fan goes too high, if its the GPU0 that gives the error too, try changing it.

[fk1]

Dear nvOC mates,

I'd like to encourage you to have a look at this topic if you don't know already: https://bitcointalk.org/index.php?topic=3921500.0

People are reporting BTM hashrates for 1060s at around 300H/s. I tried but couldn't achieve. If you guys can, this could be your new top profitable coin right now. WTM calculator: https://whattomine.com/coins/242-btm-tensority?utf8=✓&hr=1600&p=630&fee=1&cost=0.2&hcost=0.0&commit=Calculate

btm-miner-v2: linux软件下载地址: 链接: https://pan.baidu.com/s/18RX2-zSiWVA72ZHIRaQwCQ password: 33xs

chmod btm-miner/miner properly
you can download BTM wallet here for an own adress which you need to edit in the adress.txt: https://bytom.io/wallet/

add option "-url" for another pool in run.sh. I suggest antpool: https://antpool.com

If you have any questions you can PM me or write in the other thread for discussion.

Regards

[abdeldev]

Hello guys.

First of all, big thanks to all the team for the great job on this project.

Been using your Distro for 3 month now and it rocks guys. lately I've got an issue with one of my rigs, a faulty riser cause the rig to freeze without being able to complete it's reboot routing.
As Doftorul pointed out more often than not having a GPU dropping off the bus triggers a kernel panic.
So I'm sharing my workaround for those who got the same issue and have only a remote access to the rig:
Create a magic reboot script that contain (magicreboot.sh) :
#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger


Edit 5watchdog :
Change all the sudo reboot occurrence to sudo magicreboot.sh
Do the same in 6tempcontrol

for more reading about Sysrq: https://en.wikipedia.org/wiki/Magic_SysRq_key
Hope this could help
Big thanks to Doftorul, sizzlephizzle and all the nvOC team  

[papampi]

Hello guys.

First of all, big thanks to all the team for the great job on this project.

Been using your Distro for 3 month now and it rocks guys. lately I've got an issue with one of my rigs, a faulty riser cause the rig to freeze without being able to complete it's reboot routing.
As Doftorul pointed out more often than not having a GPU dropping off the bus triggers a kernel panic.
So I'm sharing my workaround for those who got the same issue and have only a remote access to the rig:
Create a magic reboot script that contain (magicreboot.sh) :
#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger


Edit 5watchdog :
Change all the sudo reboot occurrence to sudo magicreboot.sh
Do the same in 6tempcontrol

for more reading about Sysrq: https://en.wikipedia.org/wiki/Magic_SysRq_key
Hope this could help
Big thanks to Doftorul, sizzlephizzle and all the nvOC team  

Nice idea
Have you tested it?
I tried to implement R.E.I.S.U.B once but was not successful with a different approach.
Does it need to sync twice?
(u) remount the filesystem as read-only, dont think it can sync data to disk after u


Isnt it better to do the full REISUB sequence?


Edit;
If you have a faulty GPU that causes system freeze can you please test this full REISUB sequence:

Code:

#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq

# (un*R*aw) Takes back control of keyboard from X
echo r > /proc/sysrq-trigger

# (t*E*rminate) Send SIGTERM to all processes. 
echo e > /proc/sysrq-trigger

# (k*I*ll) Send SIGKILL to all processes.
echo i > /proc/sysrq-trigger

# (*S*nc) Sync all cached disk operations to disk
echo s > /proc/sysrq-trigger

# (*U*mount) Umounts all mounted partitions
echo u > /proc/sysrq-trigger

# (re*B*oot) Reboots the system
echo b > /proc/sysrq-trigger

[LuKePicci]

Hello guys.

First of all, big thanks to all the team for the great job on this project.

Been using your Distro for 3 month now and it rocks guys. lately I've got an issue with one of my rigs, a faulty riser cause the rig to freeze without being able to complete it's reboot routing.
As Doftorul pointed out more often than not having a GPU dropping off the bus triggers a kernel panic.
So I'm sharing my workaround for those who got the same issue and have only a remote access to the rig:
Create a magic reboot script that contain (magicreboot.sh) :
#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger


Edit 5watchdog :
Change all the sudo reboot occurrence to sudo magicreboot.sh
Do the same in 6tempcontrol

for more reading about Sysrq: https://en.wikipedia.org/wiki/Magic_SysRq_key
Hope this could help
Big thanks to Doftorul, sizzlephizzle and all the nvOC team  

As explained in the wikipedia page you linked, those magic sysrq keys cannot work if kernel panics occurred. I had months ago a faulty riser as well and experienced the "GPUx fallen off the bus error" but it never caused kernel panics, the watchdog detected the miner error state and restarted it (with one gpu less) without rebooting. What this script is intended to do?

Note I also have Intel WDT Driver in use, may be it didn't allow me to experience those reboot hangs you mentioned.

[abdeldev]

Hello guys.

First of all, big thanks to all the team for the great job on this project.

Been using your Distro for 3 month now and it rocks guys. lately I've got an issue with one of my rigs, a faulty riser cause the rig to freeze without being able to complete it's reboot routing.
As Doftorul pointed out more often than not having a GPU dropping off the bus triggers a kernel panic.
So I'm sharing my workaround for those who got the same issue and have only a remote access to the rig:
Create a magic reboot script that contain (magicreboot.sh) :
#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger


Edit 5watchdog :
Change all the sudo reboot occurrence to sudo magicreboot.sh
Do the same in 6tempcontrol

for more reading about Sysrq: https://en.wikipedia.org/wiki/Magic_SysRq_key
Hope this could help
Big thanks to Doftorul, sizzlephizzle and all the nvOC team  

Nice idea
Have you tested it?
I tried to implement R.E.I.S.U.B once but was not successful with a different approach.
Does it need to sync twice?
(u) remount the filesystem as read-only, dont think it can sync data to disk after u


Isnt it better to do the full REISUB sequence?


Edit;
If you have a faulty GPU that causes system freeze can you please test this full REISUB sequence:

Code:

#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq

# (un*R*aw) Takes back control of keyboard from X
echo r > /proc/sysrq-trigger

# (t*E*rminate) Send SIGTERM to all processes. 
echo e > /proc/sysrq-trigger

# (k*I*ll) Send SIGKILL to all processes.
echo i > /proc/sysrq-trigger

# (*S*nc) Sync all cached disk operations to disk
echo s > /proc/sysrq-trigger

# (*U*mount) Umounts all mounted partitions
echo u > /proc/sysrq-trigger

# (re*B*oot) Reboots the system
echo b > /proc/sysrq-trigger

Yeah I've Tested it for 2 days now and the rig reboot as soon as there's a GPU lost, preventing it from freezing.
At first I was issuing only :
echo 1 > /proc/sys/kernel/sysrq
and
echo b > /proc/sysrq-trigger
and it do work
then Doftorul  suggested that I go with the SUSB sequence

[LuKePicci]

Will there be another ISO version after 2.0? I'm not confident in the process to convert to beta 2.1

The 2.1 tree has been patched (after a lot of work) to be 100% compatible side-by-side with other nvOC versions. It's also very easy to switch back to 2.0 if you find some issues or bugs while testing, and is easy as well getting latest patches with fixes in a matter of seconds by just performing giving (in most cases) a single command. You can even do it remotely without having to detach your ssd/hdd/usb drive. And it takes only some minutes. It's not a conversion, nvOC 2.0 will remain untouched, ready to fall back in case. Future (at least minor) updates will be likely released in the same way, so I would strongly encourage you all in getting familiar with that easy workflow.

EDIT: you can always find updated, valid install/testing guide in the GitHub nvOC wiki: https://github.com/papampi/nvOC_by_fullzero_Community_Release/wiki/nvOC-19-2.1-beta-testing

[papampi]

Hello guys.

First of all, big thanks to all the team for the great job on this project.

Been using your Distro for 3 month now and it rocks guys. lately I've got an issue with one of my rigs, a faulty riser cause the rig to freeze without being able to complete it's reboot routing.
As Doftorul pointed out more often than not having a GPU dropping off the bus triggers a kernel panic.
So I'm sharing my workaround for those who got the same issue and have only a remote access to the rig:
Create a magic reboot script that contain (magicreboot.sh) :
#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger


Edit 5watchdog :
Change all the sudo reboot occurrence to sudo magicreboot.sh
Do the same in 6tempcontrol

for more reading about Sysrq: https://en.wikipedia.org/wiki/Magic_SysRq_key
Hope this could help
Big thanks to Doftorul, sizzlephizzle and all the nvOC team  

Nice idea
Have you tested it?
I tried to implement R.E.I.S.U.B once but was not successful with a different approach.
Does it need to sync twice?
(u) remount the filesystem as read-only, dont think it can sync data to disk after u


Isnt it better to do the full REISUB sequence?


Edit;
If you have a faulty GPU that causes system freeze can you please test this full REISUB sequence:

Code:

#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq

# (un*R*aw) Takes back control of keyboard from X
echo r > /proc/sysrq-trigger

# (t*E*rminate) Send SIGTERM to all processes. 
echo e > /proc/sysrq-trigger

# (k*I*ll) Send SIGKILL to all processes.
echo i > /proc/sysrq-trigger

# (*S*nc) Sync all cached disk operations to disk
echo s > /proc/sysrq-trigger

# (*U*mount) Umounts all mounted partitions
echo u > /proc/sysrq-trigger

# (re*B*oot) Reboots the system
echo b > /proc/sysrq-trigger

Yeah I've Tested it for 2 days now and the rig reboot as soon as there's a GPU lost, preventing it from freezing.
At first I was issuing only :
echo 1 > /proc/sys/kernel/sysrq
and
echo b > /proc/sysrq-trigger
and it do work
then Doftorul  suggested that I go with the SUSB sequence

I think the 2nd (S)ync wont do any thing as system is mounted as read-only in previous (U)mount step.
Can you please check the full REISUB and see how it works ..

[Oleg_filin]

Can I run ohGodanETHlargementPill on NvOc 19.1.4?

[WaveFront]

Hello guys.

First of all, big thanks to all the team for the great job on this project.

Been using your Distro for 3 month now and it rocks guys. lately I've got an issue with one of my rigs, a faulty riser cause the rig to freeze without being able to complete it's reboot routing.
As Doftorul pointed out more often than not having a GPU dropping off the bus triggers a kernel panic.
So I'm sharing my workaround for those who got the same issue and have only a remote access to the rig:
Create a magic reboot script that contain (magicreboot.sh) :
#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger


Edit 5watchdog :
Change all the sudo reboot occurrence to sudo magicreboot.sh
Do the same in 6tempcontrol

for more reading about Sysrq: https://en.wikipedia.org/wiki/Magic_SysRq_key
Hope this could help
Big thanks to Doftorul, sizzlephizzle and all the nvOC team  

Nice idea
Have you tested it?
I tried to implement R.E.I.S.U.B once but was not successful with a different approach.
Does it need to sync twice?
(u) remount the filesystem as read-only, dont think it can sync data to disk after u


Isnt it better to do the full REISUB sequence?


Edit;
If you have a faulty GPU that causes system freeze can you please test this full REISUB sequence:

Code:

#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq

# (un*R*aw) Takes back control of keyboard from X
echo r > /proc/sysrq-trigger

# (t*E*rminate) Send SIGTERM to all processes. 
echo e > /proc/sysrq-trigger

# (k*I*ll) Send SIGKILL to all processes.
echo i > /proc/sysrq-trigger

# (*S*nc) Sync all cached disk operations to disk
echo s > /proc/sysrq-trigger

# (*U*mount) Umounts all mounted partitions
echo u > /proc/sysrq-trigger

# (re*B*oot) Reboots the system
echo b > /proc/sysrq-trigger

Yeah I've Tested it for 2 days now and the rig reboot as soon as there's a GPU lost, preventing it from freezing.
At first I was issuing only :
echo 1 > /proc/sys/kernel/sysrq
and
echo b > /proc/sysrq-trigger
and it do work
then Doftorul  suggested that I go with the SUSB sequence

I think the 2nd (S)ync wont do any thing as system is mounted as read-only in previous (U)mount step.
Can you please check the full REISUB and see how it works ..

Hey, very interesting subject. After several tries, I approached the kernel panics problem with a hardware solution.
I have a RaspberryPI, with one of the GPIOs, interfaced to the reset pins of the motherboard. The RPI checks every 30 seconds the status of the SSH port of the rig (I find it more reliable than just pinging the mobo).
If the mobo is unresponsive for more than 10 minutes the RPI resets the rig.
I will publish the RPI scripts and schematics as soon as I have 10 minutes :-D

[WaveFront]

Hey :-)
What do you think is the ideal RAM size for a motherboard running nvOC?

[Stubo]

Hey :-)
What do you think is the ideal RAM size for a motherboard running nvOC?

Here is a look at how much it uses one one of my rigs with 7 1070's:

Code:

m1@Miner1:~$ free
              total        used        free      shared  buff/cache   available
Mem:        8107204     1632364     5565128       42012      909712     6055112

As you can see, I have 8 Gb but it uses less than 2 in REMOTE (no local display). I tend to buy HW that I can re-purpose in the event that mining goes south, so I recommend running a single 8 Gb stick per mining host. I typically purchase them as a 16 Gb "kit" with 2 8 GB DIMMs. Clearly, you could go as low as 4 with no issues but I have no use for DIMMs that small outside of mining.

[abdeldev]

Hello guys.

First of all, big thanks to all the team for the great job on this project.

Been using your Distro for 3 month now and it rocks guys. lately I've got an issue with one of my rigs, a faulty riser cause the rig to freeze without being able to complete it's reboot routing.
As Doftorul pointed out more often than not having a GPU dropping off the bus triggers a kernel panic.
So I'm sharing my workaround for those who got the same issue and have only a remote access to the rig:
Create a magic reboot script that contain (magicreboot.sh) :
#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger


Edit 5watchdog :
Change all the sudo reboot occurrence to sudo magicreboot.sh
Do the same in 6tempcontrol

for more reading about Sysrq: https://en.wikipedia.org/wiki/Magic_SysRq_key
Hope this could help
Big thanks to Doftorul, sizzlephizzle and all the nvOC team  

Nice idea
Have you tested it?
I tried to implement R.E.I.S.U.B once but was not successful with a different approach.
Does it need to sync twice?
(u) remount the filesystem as read-only, dont think it can sync data to disk after u


Isnt it better to do the full REISUB sequence?


Edit;
If you have a faulty GPU that causes system freeze can you please test this full REISUB sequence:

Code:

#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq

# (un*R*aw) Takes back control of keyboard from X
echo r > /proc/sysrq-trigger

# (t*E*rminate) Send SIGTERM to all processes. 
echo e > /proc/sysrq-trigger

# (k*I*ll) Send SIGKILL to all processes.
echo i > /proc/sysrq-trigger

# (*S*nc) Sync all cached disk operations to disk
echo s > /proc/sysrq-trigger

# (*U*mount) Umounts all mounted partitions
echo u > /proc/sysrq-trigger

# (re*B*oot) Reboots the system
echo b > /proc/sysrq-trigger

Yeah I've Tested it for 2 days now and the rig reboot as soon as there's a GPU lost, preventing it from freezing.
At first I was issuing only :
echo 1 > /proc/sys/kernel/sysrq
and
echo b > /proc/sysrq-trigger
and it do work
then Doftorul  suggested that I go with the SUSB sequence

I think the 2nd (S)ync wont do any thing as system is mounted as read-only in previous (U)mount step.
Can you please check the full REISUB and see how it works ..

Hey, very interesting subject. After several tries, I approached the kernel panics problem with a hardware solution.
I have a RaspberryPI, with one of the GPIOs, interfaced to the reset pins of the motherboard. The RPI checks every 30 seconds the status of the SSH port of the rig (I find it more reliable than just pinging the mobo).
If the mobo is unresponsive for more than 10 minutes the RPI resets the rig.
I will publish the RPI scripts and schematics as soon as I have 10 minutes :-D

Yeah I'm trying a hardware solution too using RaspberryPI, and now I'm happy with the sysrq workaround as it prevent any freeze caused by faulty riser.
I'm testing the full REISUB sequence as papampi suggested, we'll give u a feed back tomorrow.

[abdeldev]

the full sequence didn't work, I'm back to :

#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger

[papampi]

the full sequence didn't work, I'm back to :

#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger

Thanks for confirmation
Wanted to know if it doesnt work on my test rig only or else ...

Added your suggestion for next release (your name included)
sysrq_reboot pull request