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

[Bibi187]

Any one had this sort of issue while using SALFTER_NICEHASH_PROFIT_SWITCHING ??

Code:

__lbry_CORE_OVERCLOCK: 100
lbry_MEMORY_OVERCLOCK: 1100

Traceback (most recent call last):
  File "/home/m1/switch", line 210, in <module>
    exchrate=float(json.loads(urllib.urlopen("https://api.coinbase.com/v2/exchange-rates?currency=BTC").read())["data"]["rates"][currency])
  File "/usr/lib/python2.7/urllib.py", line 87, in urlopen
    return opener.open(url)
  File "/usr/lib/python2.7/urllib.py", line 213, in open
    return getattr(self, name)(url)
  File "/usr/lib/python2.7/urllib.py", line 443, in open_https
    h.endheaders(data)
  File "/usr/lib/python2.7/httplib.py", line 1053, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 897, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 859, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1278, in connect
    server_hostname=server_hostname)
  File "/usr/lib/python2.7/ssl.py", line 353, in wrap_socket
    _context=self)
  File "/usr/lib/python2.7/ssl.py", line 601, in __init__
    self.do_handshake()
  File "/usr/lib/python2.7/ssl.py", line 830, in do_handshake
    self._sslobj.do_handshake()
IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

Can u check date and hours on your linux / network ?
Failed certificate verify error came from this habitually

I've changed the time zone long back to my local time (GMT London), the profit switching was working even after the time zone change! Haven't touched/changed anything related to profit switching!!

UPDATE :

Now I'm not getting the above error but get different issue; main terminal says mining starts in guake terminal; but on guake 'There is no screen to be resumed matching miner' error appears.

Will compare it with latest 1bash and see if there are any differences.

EDIT :

Sorry, I've overlooked, I'm still getting the above error and on guake getting this 'There is no screen to be resumed matching miner'

Any idea guys??

I am actually really busy with my work ( that happen lol ) so far i see, i speak about date / hour and that not resolve your problem.
I can say is related to the fact SALFTER dont get correct return on API from coinbase, if i have time i will check script but not for moment

[1714201485]

1714201485

[fullzero]

Feature Request:
1-
Add IP address to hostname at first boot to setup individual names for each rig.
So rigs names will become : m1-desktop-101 , m1-desktop-102 ....
I know we can edit our hostnames in /etc/hosts and /etc/hostanme.
It just make nvOC looks better at first start  

2-
Remind user to change the m1 password at first boot.
Its not safe.

for 2, adding some reminder texts is fine, but don't force user to change password.

1 - Appending the host address to the end of the hostname is ok; I will add this at least as a selectable option; to the list.

2 - You shouldn't have anything of value on a mining rig in the first place.  I agree with car1999 that most users don't care, or want to; deal with changing a password.  Personally I think changing the password (both for m1 and root) as well as the SSH keys in seahorse; is a good idea, I will add auto changing of password with expect to v0019 or a later version depending on how things go.

[fullzero]

Any one had this sort of issue while using SALFTER_NICEHASH_PROFIT_SWITCHING ??

Code:

__lbry_CORE_OVERCLOCK: 100
lbry_MEMORY_OVERCLOCK: 1100

Traceback (most recent call last):
  File "/home/m1/switch", line 210, in <module>
    exchrate=float(json.loads(urllib.urlopen("https://api.coinbase.com/v2/exchange-rates?currency=BTC").read())["data"]["rates"][currency])
  File "/usr/lib/python2.7/urllib.py", line 87, in urlopen
    return opener.open(url)
  File "/usr/lib/python2.7/urllib.py", line 213, in open
    return getattr(self, name)(url)
  File "/usr/lib/python2.7/urllib.py", line 443, in open_https
    h.endheaders(data)
  File "/usr/lib/python2.7/httplib.py", line 1053, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 897, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 859, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1278, in connect
    server_hostname=server_hostname)
  File "/usr/lib/python2.7/ssl.py", line 353, in wrap_socket
    _context=self)
  File "/usr/lib/python2.7/ssl.py", line 601, in __init__
    self.do_handshake()
  File "/usr/lib/python2.7/ssl.py", line 830, in do_handshake
    self._sslobj.do_handshake()
IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

Can u check date and hours on your linux / network ?
Failed certificate verify error came from this habitually

I've changed the time zone long back to my local time (GMT London), the profit switching was working even after the time zone change! Haven't touched/changed anything related to profit switching!!

UPDATE :

Now I'm not getting the above error but get different issue; main terminal says mining starts in guake terminal; but on guake 'There is no screen to be resumed matching miner' error appears.

Will compare it with latest 1bash and see if there are any differences.

EDIT :

Sorry, I've overlooked, I'm still getting the above error and on guake getting this 'There is no screen to be resumed matching miner'

Any idea guys??

What version of nvOC are you using?

Looking at this list of errors they are all essentially 1 error; which if I am correct is the equivalent of when you try to go to a webpage and are getting a certificate error from your browser.

When I directly use the url in a browser:  https://api.coinbase.com/v2/exchange-rates?currency=BTC the api is working; I would try doing this on your rig in a browser and see if it responds with a json.

Let me know if it does.

[fullzero]

Thank you so much for the quick respond. I'm getting GPU 0, GpuMiner cu_k1 failed 77, an illegal memory access was encountered in claymore and CUDA failure 77: an illegal memory access was encountered ; in Genoil, after a few seconds of mining.

Also in ZEC it says CUDA: Device: 3 Thread exited with code: 77
or CUDA: Device: 3 Thread exited with code: 64

Try a lower memory overclock offset: I get these errors when I overclock too much. To confirm, check the output of "dmesg" in the terminal; if you get messages like these:

[139035.343237] NVRM: Xid (PCI:0000:02:00): 31, Ch 0000001b, engmask 00000101, intr 10000000

Most probably that's the issue. If you get these messages but with a different Xid (in this example it's 31), report here, as each code has a different meaning.

I agree with dbolivar; the mc is most likely too high or too high for the powerlimit.  I used the values that were working in the sort term on lards rig; which are apparently too aggressive and unstable over time.  I will edit the p106-100 1bash to have a lower default mc OC offset and a slightly higher powerlimit.

I am thinking a slightly higher cc (-100) might also give slightly better performance with a higher powerlimit.

[fullzero]

Hey everyone.

As fullzero has already posted the instruction on OC of P106-100 rigs, I can confirm that this works and i am now using cc -200 and mc 1300(was stable for over 10 hours )  , I think it can go to 1400-1500 but I am in the process of testing the 12th card since it caused me issues everytime i connected before.

Also I have another question to ask fullzero : When I start the rig it sometimes doesn't swap the xorg files and giving me errors which lead to the OC being off(Sometimes even after autoreboot it doesn't autostart 1bash). This solves after a couple of reboots but I can't figure out how to reboot it so the OC will work and the miner also would start automatically since sometimes when I turn it on the miner doesn't autostart and this leads to further errors and no OC available. So far I haven't found any other problems so thank you again for solving OC issue.

Can you advise on what should I do in that case?

When remoting in; it is important to realize that you can SSH in before all system init has occurred.  Think of when you are watching nvOC load on a monitor.  When Ubuntu is loading; there is a period where you cannot use the keyboard or mouse / guake has not started / 2unix (via gnome-terminal) hasn't launched.  You can SSH in before this interval in system init.  If you do, this act alone may change the init sequence, or it might only be launching bash earlier which may do this.

It could also be something else entirely; such as x intermittently launching or not launching which is causing the problem.  This is the type of thing It will be much easier to isolate with my own p106-100 test rig.

For now I would try waiting longer after reboot before SSHing into the rig and seeing if that resolves the problem.  Let me know how it goes.

[damNmad]

Any one had this sort of issue while using SALFTER_NICEHASH_PROFIT_SWITCHING ??

Code:

__lbry_CORE_OVERCLOCK: 100
lbry_MEMORY_OVERCLOCK: 1100

Traceback (most recent call last):
  File "/home/m1/switch", line 210, in <module>
    exchrate=float(json.loads(urllib.urlopen("https://api.coinbase.com/v2/exchange-rates?currency=BTC").read())["data"]["rates"][currency])
  File "/usr/lib/python2.7/urllib.py", line 87, in urlopen
    return opener.open(url)
  File "/usr/lib/python2.7/urllib.py", line 213, in open
    return getattr(self, name)(url)
  File "/usr/lib/python2.7/urllib.py", line 443, in open_https
    h.endheaders(data)
  File "/usr/lib/python2.7/httplib.py", line 1053, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 897, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 859, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1278, in connect
    server_hostname=server_hostname)
  File "/usr/lib/python2.7/ssl.py", line 353, in wrap_socket
    _context=self)
  File "/usr/lib/python2.7/ssl.py", line 601, in __init__
    self.do_handshake()
  File "/usr/lib/python2.7/ssl.py", line 830, in do_handshake
    self._sslobj.do_handshake()
IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

Can u check date and hours on your linux / network ?
Failed certificate verify error came from this habitually

I've changed the time zone long back to my local time (GMT London), the profit switching was working even after the time zone change! Haven't touched/changed anything related to profit switching!!

UPDATE :

Now I'm not getting the above error but get different issue; main terminal says mining starts in guake terminal; but on guake 'There is no screen to be resumed matching miner' error appears.

Will compare it with latest 1bash and see if there are any differences.

EDIT :

Sorry, I've overlooked, I'm still getting the above error and on guake getting this 'There is no screen to be resumed matching miner'

Any idea guys??

What version of nvOC are you using?

Looking at this list of errors they are all essentially 1 error; which if I am correct is the equivalent of when you try to go to a webpage and are getting a certificate error from your browser.

When I directly use the url in a browser:  https://api.coinbase.com/v2/exchange-rates?currency=BTC the api is working; I would try doing this on your rig in a browser and see if it responds with a json.

Let me know if it does.

I'm using nvOC v18 with all the updated files provided on main post.

I've compared my 1bash file with the latest 1bash on 1st page, seems no difference apart from the changes I've made (coins added by myself).

Opened the switch python file; checked the url's on RIG's browser, seems ok; nothing stands out, not sure what is going on with my RIG, everything else works fine except the profit switching!!

It starts fine; prints the per day calculation after displaying the above error list; says mining starts on guake terminal; tab opens in guake terminal and 'screen -r miner' then 'There is no screen to be resumed matching miner' and again 'screen -r miner' then 'There is no screen to be resumed matching miner'.

My guess it is failing to find the miner but also the switch file failing to make connection with those API's!!

[fullzero]

I'm uploading a copy I'd originally downloaded from Google Drive (or was it Mega?) to my VPS.  I'll post a link once it's up.  SHA256 hash on the file is d11929368d186acf73651be1b9d90234cfe6ef8a097eff56668dee4cbbe69e8c, as announced here.

...and now it's up:

https://alfter.us/wp/wp-content/uploads/2017/07/nvOC_v0017.zip

I tested this direct link; it should work.  If it doesn't, follow the link from here:

https://alfter.us/wp/nvoc_v0017/

Thanks for proving an ad free link; I will change the link on the OP to yours. 

I strongly dislike ref links / advertising.

[lards]

Hey everyone.

As fullzero has already posted the instruction on OC of P106-100 rigs, I can confirm that this works and i am now using cc -200 and mc 1300(was stable for over 10 hours )  , I think it can go to 1400-1500 but I am in the process of testing the 12th card since it caused me issues everytime i connected before.

Also I have another question to ask fullzero : When I start the rig it sometimes doesn't swap the xorg files and giving me errors which lead to the OC being off(Sometimes even after autoreboot it doesn't autostart 1bash). This solves after a couple of reboots but I can't figure out how to reboot it so the OC will work and the miner also would start automatically since sometimes when I turn it on the miner doesn't autostart and this leads to further errors and no OC available. So far I haven't found any other problems so thank you again for solving OC issue.

Can you advise on what should I do in that case?

When remoting in; it is important to realize that you can SSH in before all system init has occurred.  Think of when you are watching nvOC load on a monitor.  When Ubuntu is loading; there is a period where you cannot use the keyboard or mouse / guake has not started / 2unix (via gnome-terminal) hasn't launched.  You can SSH in before this interval in system init.  If you do, this act alone may change the init sequence, or it might only be launching bash earlier which may do this.

It could also be something else entirely; such as x intermittently launching or not launching which is causing the problem.  This is the type of thing It will be much easier to isolate with my own p106-100 test rig.

For now I would try waiting longer after reboot before SSHing into the rig and seeing if that resolves the problem.  Let me know how it goes.

I was trying to reboot away from the rig by turning on/off the power plug so I wasn't even connecting via SSH at all. Waited for over 15 minutes, no reported rate on pool made me think that it hasn't started so to turn it on I had to come to the home network of the rig but after another reboot it started fine with no errors after starting 1bash.

When 1bash is started automatically no errors appear at all and OC works fine but mostly it doesn't autostart and I have to use console to start it , it reports problems with replacing xorg + some other errors and OC doesn't work.

Maybe that info would help you to work out why does it do such thing.

Thanks for your reply.

[fullzero]

Is there anything special I need to do in order to get a pci 1x 1slot to 3 slot adaptor to work?

http://1stminingrig.com/pci-express-1-to-3-pci-e-1x-slots-riser-card-is-it-worth-it/

A MOTHERBOARD THAT IS COMPATIBLE--

Do your research.  Some boards will not recognize any GPUs attached through the  PCIe multiplier.  Some will max-out at 7 total GPUs, and fail to boot if an 8th GPU is attached.  Reportedly, H81 Boards fall in that category.  Z170 and Z270 boards have been reported compatible, and may allow several PCIe multiplier boards attached to the motherboard.

I have tried a PCIe multipler (1 to 4) with little success.  I bought a new version recently for about $30 and will try again.  In 2014, I was able to mine script with a GT 9800+ and a GT 520 on the multiplier, and a GTX 550ti on the motherboard.  All 3 cards barely made 135kh/s script total.  They are all considered obsolete today.  I was not able to get the PCIe multiplier to work with a GTX 750ti, even using the same motherboard.

Do Google searches and check.  Actually, an ASRock H110 is probably a better bet.  Good luck!       --scryptr

I agree with scryptr.  I have a bunch of these 1-to-3 adapters + m2 adapters + mobos I no longer use.  I recommend using all H110s (this is what I am doing now, slowing converting all my rigs over). 

If anyone wants to buy a lot of mobos / 1-to-3 adapters + m2 adapters let me know and I'll let them go at a significant discount.  It is important to note as scryptr said that the 1-to-3 adapters are very mobo dependent and usually only allow 1 slot to be split into 2, and are always limited to the max capacity of the mobo being used; for this reason I would only want to sell 1-to-3 adapters to a senior member who is already familiar with using them. 

[fullzero]

I got weird problem on both of my rigs
Any idea how to solve this :

Code:

m1-desktop-102:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  linux-image-extra-4.4.0-65-generic
The following packages will be upgraded:
  libxfont1 ubuntu-drivers-common
2 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 95.1 kB/145 kB of archives.
After this operation, 153 MB disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 libxfont1 amd64 1:1.5.1-1ubuntu0.16.04.2 [95.1 kB]
Fetched 95.1 kB in 0s (220 kB/s)
Preconfiguring packages ...
(Reading database ... 219845 files and directories currently installed.)
Removing linux-image-extra-4.4.0-65-generic (4.4.0-65.86) ...
dpkg: error processing package linux-image-extra-4.4.0-65-generic (--remove):
 unable to securely remove '/lib/modules/4.4.0-65-generic/kernel/drivers/media/usb/hdpvr/hdpvr.ko': Not a directory
Errors were encountered while processing:
 linux-image-extra-4.4.0-65-generic
E: Sub-process /usr/bin/dpkg returned an error code (1)

apt autoremove cant solve it either ...

Edit.
Thanks to _parallex_ post here removing these files solve the problem:

Code:

linux-image-4.4.0-65-generic.list
linux-image-4.4.0-65-generic.postrm
linux-image-extra-4.4.0-65-generic.list
linux-image-extra-4.4.0-65-generic.md5sums
linux-image-extra-4.4.0-65-generic.postinst
linux-image-extra-4.4.0-65-generic.postrm

This is why I recommended turning off updates other than security; some updates manifest conflicts due to these packages.  I fixed this issue for v0019; _Parallax_  deserves credit for noticing this first.

[fullzero]

I have got multiple biostar tb250 btc pro mobos.

I am going to run this with 12 gtx 1070 hours.
Is this possible with nvos?
 Driver wise?

So 12 gtx 1070 one motherboard?

Hi Moordact, yeap u can work on 12 1070 GPU on linux,8 GPU per driver is a windows limitation.
Slot primary card alone on pcie 16 at first boot, after boot shutdown plug all your card & enjoy

Beyond the 8 gpu limitation; Windows also has a LOT of unnecessary and arguably malicious processes running in the background.

Mining with Windows is like being a single parent with 12 children; mining with linux is like being single with a lot of friends who frequently come by to give you presents and do things for you.

[fullzero]

Hello.

Please help me solve the problem:
GPU UTILIZATION: Unable to determine the device for GPU 0000: 09: 00.0: GPU is lost. Reboot the system to recover this GPU.

 I'm new in Linux, tell me how to fix this?

Hi Oleg_filin,

this log come from "WATCHDOG" it seems watchdog detect some issue on you GPU and restart mining process, that dont resolve the issue after 3 soft reboot so WATCHDOG reboot your PC. If your OC setting is stable and you dont get crash about GPU, just disable WATCHDOG in 1bash config. Or be sure to be up to date with last WATCHDOG script A lot of new miner push your GPU volatility to max and your GPU sometime show 0% and back to 100% that why WATCHDOG feel something is happening.

I agree with Bibi187; this is most likely due to too much OC.  However it can also happen due to a bad riser, insufficient power from the PSU, a bad GPU, a bad mobo; or for many other reasons.

[fullzero]

P106-100 BOUNTY

The person who will be able to unlock the overclock of my 13x P106 Rig (on the ASRock H110 BTC) with nvOC will get

1 ETH

I only got pure P106-rigs and no non-mining cards mixtures.

PM me and I will give you access to one of my Rigs.

Thanks!

I'm ready to make a donation too, if the issue with P106 cards is finally solved, but it's been so long already ...

Download the pure P106-100 1bash for headless SSH operation from the link on the OP; replace the 1 bash on your rig with it.  

Add your pool / addresses / workername to the 1bash.

Note: for this version don't use:

Maxximus007_AUTO_TEMPERATURE_CONTROL

or

IAmNotAJeep_and_Maxximus007_WATCHDOG

ensure they are both set to "NO"

Run the mining process; it should not OC at this time.  This is expected; it will alter the xorg.conf as needed.  

Note the Rig IP; write it down.

If you are not already running fully headless; ensure that you reboot: disconnecting any monitor from integrated graphics on the mobo before the rig reboots.

With your rig IP ssh into the rig after it boots ( see guide on the OP for more information on how to do this.  If from a linux system use the cmd from terminal:

Code:

ssh m1@your_rig_ip_here

you will be prompted

enter:

Code:

yes

the password is:

Code:

miner1

once you are logged in via SSH; enter:

Code:

screen -ls

if there is already a screen named miner use the cmd:

Code:

screen -r miner

to reconnect to the mining process and ignore the rest of this guide


if there is not; enter the cmd:

Code:

bash 1bash

to launch the mining process

once you see the message:

process in screen miner; attach with: screen -r miner

hit

Code:

ctrl + c

then enter:

Code:

screen -r miner

If you have problems with this; let me know.  I can't test this directly as I don't have these GPUs; but this should work unless I made a typo in the 1bash.


Also; you can edit the 1bash via SSH with the cmd:

Code:

nano 1bash

note this is a visual editor; again see the SSH guide for more info on nano.

http://prntscr.com/gc8g0n / http://prntscr.com/gc8agx ((

In the second picture:

My guess is that you are hitting ctrl + c too quickly after seeing the mining process is launched message (the process is actually launched immediately after this is displayed, so it is possible to close it too soon)

At the bottom: you have already opened 1bash in nano without closing the process which is why you are getting that message.  Having 1bash open in nano while trying to launch 1bash might also be causing problems (although it shouldn't).

To manually launch 1bash use the command:

Code:

bash 1bash

nano is for editing 1bash

You also might need to use the cmd:

Code:

sudo reboot

to reboot the rig after changing the xorg for the first time.  It is probably best to only conditionally change the xorg; but making / testing a configuration that works more smoothly will be much easier with my own p106-100 rig. 

For now it is probably easier to use 1 normal 1060 as the primary GPU and avoid all of this. 

I would like to make my own p106-100 rig to test and better resolve all issues.  I find it very strange that these GPUs are not for sale in the US. 

[fullzero]

Any one had this sort of issue while using SALFTER_NICEHASH_PROFIT_SWITCHING ??

Code:

__lbry_CORE_OVERCLOCK: 100
lbry_MEMORY_OVERCLOCK: 1100

Traceback (most recent call last):
  File "/home/m1/switch", line 210, in <module>
    exchrate=float(json.loads(urllib.urlopen("https://api.coinbase.com/v2/exchange-rates?currency=BTC").read())["data"]["rates"][currency])
  File "/usr/lib/python2.7/urllib.py", line 87, in urlopen
    return opener.open(url)
  File "/usr/lib/python2.7/urllib.py", line 213, in open
    return getattr(self, name)(url)
  File "/usr/lib/python2.7/urllib.py", line 443, in open_https
    h.endheaders(data)
  File "/usr/lib/python2.7/httplib.py", line 1053, in endheaders
    self._send_output(message_body)
  File "/usr/lib/python2.7/httplib.py", line 897, in _send_output
    self.send(msg)
  File "/usr/lib/python2.7/httplib.py", line 859, in send
    self.connect()
  File "/usr/lib/python2.7/httplib.py", line 1278, in connect
    server_hostname=server_hostname)
  File "/usr/lib/python2.7/ssl.py", line 353, in wrap_socket
    _context=self)
  File "/usr/lib/python2.7/ssl.py", line 601, in __init__
    self.do_handshake()
  File "/usr/lib/python2.7/ssl.py", line 830, in do_handshake
    self._sslobj.do_handshake()
IOError: [Errno socket error] [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

Can u check date and hours on your linux / network ?
Failed certificate verify error came from this habitually

I've changed the time zone long back to my local time (GMT London), the profit switching was working even after the time zone change! Haven't touched/changed anything related to profit switching!!

UPDATE :

Now I'm not getting the above error but get different issue; main terminal says mining starts in guake terminal; but on guake 'There is no screen to be resumed matching miner' error appears.

Will compare it with latest 1bash and see if there are any differences.

EDIT :

Sorry, I've overlooked, I'm still getting the above error and on guake getting this 'There is no screen to be resumed matching miner'

Any idea guys??

What version of nvOC are you using?

Looking at this list of errors they are all essentially 1 error; which if I am correct is the equivalent of when you try to go to a webpage and are getting a certificate error from your browser.

When I directly use the url in a browser:  https://api.coinbase.com/v2/exchange-rates?currency=BTC the api is working; I would try doing this on your rig in a browser and see if it responds with a json.

Let me know if it does.

I'm using nvOC v18 with all the updated files provided on main post.

I've compared my 1bash file with the latest 1bash on 1st page, seems no difference apart from the changes I've made (coins added by myself).

Opened the switch python file; checked the url's on RIG's browser, seems ok; nothing stands out, not sure what is going on with my RIG, everything else works fine except the profit switching!!

It starts fine; prints the per day calculation after displaying the above error list; says mining starts on guake terminal; tab opens in guake terminal and 'screen -r miner' then 'There is no screen to be resumed matching miner' and again 'screen -r miner' then 'There is no screen to be resumed matching miner'.

My guess it is failing to find the miner but also the switch file failing to make connection with those API's!!

Yes

the switch file failing to make connection with those API

this is why I wanted you to:

When I directly use the url in a browser:  https://api.coinbase.com/v2/exchange-rates?currency=BTC the api is working; I would try doing this on your rig in a browser and see if it responds with a json.

Let me know if it does.

to help isolate if the problem is with your system or the script.

[fullzero]

Hey everyone.

As fullzero has already posted the instruction on OC of P106-100 rigs, I can confirm that this works and i am now using cc -200 and mc 1300(was stable for over 10 hours )  , I think it can go to 1400-1500 but I am in the process of testing the 12th card since it caused me issues everytime i connected before.

Also I have another question to ask fullzero : When I start the rig it sometimes doesn't swap the xorg files and giving me errors which lead to the OC being off(Sometimes even after autoreboot it doesn't autostart 1bash). This solves after a couple of reboots but I can't figure out how to reboot it so the OC will work and the miner also would start automatically since sometimes when I turn it on the miner doesn't autostart and this leads to further errors and no OC available. So far I haven't found any other problems so thank you again for solving OC issue.

Can you advise on what should I do in that case?

When remoting in; it is important to realize that you can SSH in before all system init has occurred.  Think of when you are watching nvOC load on a monitor.  When Ubuntu is loading; there is a period where you cannot use the keyboard or mouse / guake has not started / 2unix (via gnome-terminal) hasn't launched.  You can SSH in before this interval in system init.  If you do, this act alone may change the init sequence, or it might only be launching bash earlier which may do this.

It could also be something else entirely; such as x intermittently launching or not launching which is causing the problem.  This is the type of thing It will be much easier to isolate with my own p106-100 test rig.

For now I would try waiting longer after reboot before SSHing into the rig and seeing if that resolves the problem.  Let me know how it goes.

I was trying to reboot away from the rig by turning on/off the power plug so I wasn't even connecting via SSH at all. Waited for over 15 minutes, no reported rate on pool made me think that it hasn't started so to turn it on I had to come to the home network of the rig but after another reboot it started fine with no errors after starting 1bash.

When 1bash is started automatically no errors appear at all and OC works fine but mostly it doesn't autostart and I have to use console to start it , it reports problems with replacing xorg + some other errors and OC doesn't work.

Maybe that info would help you to work out why does it do such thing.

Thanks for your reply.

In that case, it is probably x intermittently launching or not launching most likely do to modification of the xorg.conf.  It is probably best to only conditionally change the xorg; but making / testing a configuration that works more smoothly will be much easier with my own p106-100 rig. I set the current p106-100 1bash to always modify the xorg.conf to avoid potential infinite boot loop problems vs only having a single boot that doesn't OC.

[lards]

Hey everyone.

As fullzero has already posted the instruction on OC of P106-100 rigs, I can confirm that this works and i am now using cc -200 and mc 1300(was stable for over 10 hours )  , I think it can go to 1400-1500 but I am in the process of testing the 12th card since it caused me issues everytime i connected before.

Also I have another question to ask fullzero : When I start the rig it sometimes doesn't swap the xorg files and giving me errors which lead to the OC being off(Sometimes even after autoreboot it doesn't autostart 1bash). This solves after a couple of reboots but I can't figure out how to reboot it so the OC will work and the miner also would start automatically since sometimes when I turn it on the miner doesn't autostart and this leads to further errors and no OC available. So far I haven't found any other problems so thank you again for solving OC issue.

Can you advise on what should I do in that case?

When remoting in; it is important to realize that you can SSH in before all system init has occurred.  Think of when you are watching nvOC load on a monitor.  When Ubuntu is loading; there is a period where you cannot use the keyboard or mouse / guake has not started / 2unix (via gnome-terminal) hasn't launched.  You can SSH in before this interval in system init.  If you do, this act alone may change the init sequence, or it might only be launching bash earlier which may do this.

It could also be something else entirely; such as x intermittently launching or not launching which is causing the problem.  This is the type of thing It will be much easier to isolate with my own p106-100 test rig.

For now I would try waiting longer after reboot before SSHing into the rig and seeing if that resolves the problem.  Let me know how it goes.

I was trying to reboot away from the rig by turning on/off the power plug so I wasn't even connecting via SSH at all. Waited for over 15 minutes, no reported rate on pool made me think that it hasn't started so to turn it on I had to come to the home network of the rig but after another reboot it started fine with no errors after starting 1bash.

When 1bash is started automatically no errors appear at all and OC works fine but mostly it doesn't autostart and I have to use console to start it , it reports problems with replacing xorg + some other errors and OC doesn't work.

Maybe that info would help you to work out why does it do such thing.

Thanks for your reply.

In that case, it is probably x intermittently launching or not launching most likely do to modification of the xorg.conf.  It is probably best to only conditionally change the xorg; but making / testing a configuration that works more smoothly will be much easier with my own p106-100 rig. I set the current p106-100 1bash to always modify the xorg.conf to avoid potential infinite boot loop problems vs only having a single boot that doesn't OC.

So what would you suggest to get rid of this problem? To reboot until the xorg and the miner start correctly or can I modify the 1bash somehow to make sure I don't have to reboot 5 times in a row to get it up and running?

[fullzero]

Hey everyone.

As fullzero has already posted the instruction on OC of P106-100 rigs, I can confirm that this works and i am now using cc -200 and mc 1300(was stable for over 10 hours )  , I think it can go to 1400-1500 but I am in the process of testing the 12th card since it caused me issues everytime i connected before.

Also I have another question to ask fullzero : When I start the rig it sometimes doesn't swap the xorg files and giving me errors which lead to the OC being off(Sometimes even after autoreboot it doesn't autostart 1bash). This solves after a couple of reboots but I can't figure out how to reboot it so the OC will work and the miner also would start automatically since sometimes when I turn it on the miner doesn't autostart and this leads to further errors and no OC available. So far I haven't found any other problems so thank you again for solving OC issue.

Can you advise on what should I do in that case?

When remoting in; it is important to realize that you can SSH in before all system init has occurred.  Think of when you are watching nvOC load on a monitor.  When Ubuntu is loading; there is a period where you cannot use the keyboard or mouse / guake has not started / 2unix (via gnome-terminal) hasn't launched.  You can SSH in before this interval in system init.  If you do, this act alone may change the init sequence, or it might only be launching bash earlier which may do this.

It could also be something else entirely; such as x intermittently launching or not launching which is causing the problem.  This is the type of thing It will be much easier to isolate with my own p106-100 test rig.

For now I would try waiting longer after reboot before SSHing into the rig and seeing if that resolves the problem.  Let me know how it goes.

I was trying to reboot away from the rig by turning on/off the power plug so I wasn't even connecting via SSH at all. Waited for over 15 minutes, no reported rate on pool made me think that it hasn't started so to turn it on I had to come to the home network of the rig but after another reboot it started fine with no errors after starting 1bash.

When 1bash is started automatically no errors appear at all and OC works fine but mostly it doesn't autostart and I have to use console to start it , it reports problems with replacing xorg + some other errors and OC doesn't work.

Maybe that info would help you to work out why does it do such thing.

Thanks for your reply.

In that case, it is probably x intermittently launching or not launching most likely do to modification of the xorg.conf.  It is probably best to only conditionally change the xorg; but making / testing a configuration that works more smoothly will be much easier with my own p106-100 rig. I set the current p106-100 1bash to always modify the xorg.conf to avoid potential infinite boot loop problems vs only having a single boot that doesn't OC.

So what would you suggest to get rid of this problem? To reboot until the xorg and the miner start correctly or can I modify the 1bash somehow to make sure I don't have to reboot 5 times in a row to get it up and running?

I made a conditionally updating 1bash (in addition to lowering the default OC on the original p106-100) for you to try.  There is a download link on the OP; let me know if it works better.

[lards]

I'll try the to use new 1bash if I get unstable results in the future since now I had the rig up for over 28 hours. Also does the autoreboot in the SSH only mode works as it supposed to?

[Bibi187]

I'll try the to use new 1bash if I get unstable results in the future since now I had the rig up for over 28 hours. Also does the autoreboot in the SSH only mode works as it supposed to?

Hi,

autoreboot work fine on SSH mode, my rig reboot every 24 hours, i commented /etc/fstab my rig reboot in less then 30sec.

Fullzero i noticed something, if u run 1bash at root user, after u have to apply validation on rm file. Not so much important that from a miss leading from me, on launching 1bash at root user. Just for let u to know.

Thanks for you amazing work to as usual ...

[EvgeniX]

Hi,

Can someone point me to tutorial or share 1bash file with setup for nicehash with SALFTER_NICEHASH_PROFIT_SWITCHING="YES"
How do you choose what currencies to mine?

Thanks