So after I try:
1- The loading is still the same, nothing was changed.
2- The Xorg.conf file is still the same, BUSID: PCI: 1@0:0:0 although I changed the value. There was no error when I saved the file.
3- The 7th card usually crash after 5-15 minutes, it can be restarted, but it does not work after that. The others 6 card are working well.
Topic: [OS] nvOC easy-to-use Linux Nvidia Mining - page 407. (Read 418251 times)
Here is the terminal start up when I just boot the system. Now I will try to edit the xorg.conf to see if it will change or remain the same.
In addition, it seems my 7th card will stop working after 15-20 minutes, it just display 0W - 0sols. Not sure why it happen. I run well with 6 cards.
spawn sudo dos2unix /media/m1/1263-A96E/oneBash
[sudo] password for m1: spawn sudo ldconfig /usr/local/cuda/lib64
[sudo] password for m1: spawn sudo nvidia-smi -pl 185
[sudo] password for m1: spawn sudo nvidia-xconfig --cool-bits=24
[sudo] password for m1:
ERROR: Error assigning value 55 to attribute 'GPUTargetFanSpeed'
(m1-desktop:0[fan:0]) as specified in assignment
'[fan:0]/GPUTargetFanSpeed=55' (Unknown Error).
+-------------------------------------------------+
| EWBF's Zcash CUDA miner. 0.3.3b |
+-------------------------------------------------+
In addition, it seems my 7th card will stop working after 15-20 minutes, it just display 0W - 0sols. Not sure why it happen. I run well with 6 cards.
spawn sudo dos2unix /media/m1/1263-A96E/oneBash
[sudo] password for m1: spawn sudo ldconfig /usr/local/cuda/lib64
[sudo] password for m1: spawn sudo nvidia-smi -pl 185
[sudo] password for m1: spawn sudo nvidia-xconfig --cool-bits=24
[sudo] password for m1:
ERROR: Error assigning value 55 to attribute 'GPUTargetFanSpeed'
(m1-desktop:0[fan:0]) as specified in assignment
'[fan:0]/GPUTargetFanSpeed=55' (Unknown Error).
+-------------------------------------------------+
| EWBF's Zcash CUDA miner. 0.3.3b |
+-------------------------------------------------+
Ok when editing the xorg.conf, you will only need to logout after, then login; no need to reboot the rig.
Here is the terminal start up when I just boot the system. Now I will try to edit the xorg.conf to see if it will change or remain the same.
In addition, it seems my 7th card will stop working after 15-20 minutes, it just display 0W - 0sols. Not sure why it happen. I run well with 6 cards.
spawn sudo dos2unix /media/m1/1263-A96E/oneBash
[sudo] password for m1: spawn sudo ldconfig /usr/local/cuda/lib64
[sudo] password for m1: spawn sudo nvidia-smi -pl 185
[sudo] password for m1: spawn sudo nvidia-xconfig --cool-bits=24
[sudo] password for m1:
ERROR: Error assigning value 55 to attribute 'GPUTargetFanSpeed'
(m1-desktop:0[fan:0]) as specified in assignment
'[fan:0]/GPUTargetFanSpeed=55' (Unknown Error).
+-------------------------------------------------+
| EWBF's Zcash CUDA miner. 0.3.3b |
+-------------------------------------------------+
In addition, it seems my 7th card will stop working after 15-20 minutes, it just display 0W - 0sols. Not sure why it happen. I run well with 6 cards.
spawn sudo dos2unix /media/m1/1263-A96E/oneBash
[sudo] password for m1: spawn sudo ldconfig /usr/local/cuda/lib64
[sudo] password for m1: spawn sudo nvidia-smi -pl 185
[sudo] password for m1: spawn sudo nvidia-xconfig --cool-bits=24
[sudo] password for m1:
ERROR: Error assigning value 55 to attribute 'GPUTargetFanSpeed'
(m1-desktop:0[fan:0]) as specified in assignment
'[fan:0]/GPUTargetFanSpeed=55' (Unknown Error).
+-------------------------------------------------+
| EWBF's Zcash CUDA miner. 0.3.3b |
+-------------------------------------------------+
Thank you for your reply, I use 7 card 1080ti, CPU intel pentium 3.5ghz G4560, RAM 8GB, when the system boot up, all I see is the Fan Error (can not set Fan speed), and then it go straight up to EWBF cuba 0.3.3b.
I did edit the onebash file with OC information, not sure why it did not display when the system boot up.
I did edit the onebash file with OC information, not sure why it did not display when the system boot up.
Did the oneBash startup look the same before you modifed the xorg.conf file?
Edit:
when using 7 cards the last attempted fan setting should always produce an error as the part of the driver that interacts with OC and FAN speed commands only recognizes up to 6 cards. I remade oneBash on these 7 card mobos to support up to 7 cards (should a future nvidia driver properly support them.) So what you should be looking for is core / memory OC message for cards 0 thru 5 then fan mode / speed setting messages for cards 0 thru 5 then an error message about trying to set the fan for an unknown card index of 6.
Thank you for your reply, I use 7 card 1080ti, CPU intel pentium 3.5ghz G4560, RAM 8GB, when the system boot up, all I see is the Fan Error (can not set Fan speed), and then it go straight up to EWBF cuba 0.3.3b.
I did edit the onebash file with OC information, not sure why it did not display when the system boot up.
I did edit the onebash file with OC information, not sure why it did not display when the system boot up.
Thank you for the image, it works very well for my mobo ASUS z270A, I can access the OS now.
Quote
Everything is fine, but I get trouble with the xorg.conf. I did edit the file, but somehow after the reboot, it back to original one.
For example, my PCI BUSID when I use lspci is 01:00.0
The original xorg.conf is BusID "PCI:1@0:0:0"
I think it is almost the same, but to be sure, I edit it to: PCI:01:00.0
I also tried to edit it to PCI:01:0:0
But after the reboot, it always back to "PCI:1@0:0:0"
For example, my PCI BUSID when I use lspci is 01:00.0
The original xorg.conf is BusID "PCI:1@0:0:0"
I think it is almost the same, but to be sure, I edit it to: PCI:01:00.0
I also tried to edit it to PCI:01:0:0
But after the reboot, it always back to "PCI:1@0:0:0"
I think I know what is happening here, but first tell me how many cards you are using.
Quote
Is the point of editing xorg.conf is to match the lspci address with the BUSID, and then the OC value in onebash file can be appiled? I actually do not understand the concept here since I am a very newbie Linux.
Yes, that is the general idea.
When using an image I made for a specific motherboard; with that motherboard (like this one) you shouldn't need to edit the xorg.conf file at all. Thus the easy solution should be to make a copy of your configured oneBash, reimage the usb and then replace the default oneBash with your own. Reattach to rig ( when oneBash starts it should show an output for core and memory overclock for each card it OCs (up to six cards (note indexing starts at 0 so up to 5)) if you see this you know OC is working for that card).
Quote
Just for the record, I set my powerlimit to 185 and so my card can get around 620sol. I guess if I can apply the OC value, it can go up to 680, which is pretty good.
For a 1080ti I use a core overclock of 150 and a memory overclock of 900; most cards should be able to handle this and get more sol/s.
Thank you for the image, it works very well for my mobo ASUS z270A, I can access the OS now. Everything is fine, but I get trouble with the xorg.conf. I did edit the file, but somehow after the reboot, it back to original one.
For example, my PCI BUSID when I use lspci is 01:00.0
The original xorg.conf is BusID "PCI:1@0:0:0"
I think it is almost the same, but to be sure, I edit it to: PCI:01:00.0
I also tried to edit it to PCI:01:0:0
But after the reboot, it always back to "PCI:1@0:0:0"
Is the point of editing xorg.conf is to match the lspci address with the BUSID, and then the OC value in onebash file can be appiled? I actually do not understand the concept here since I am a very newbie Linux.
Just for the record, I set my powerlimit to 185 and so my card can get around 620sol. I guess if I can apply the OC value, it can go up to 680, which is pretty good.
For example, my PCI BUSID when I use lspci is 01:00.0
The original xorg.conf is BusID "PCI:1@0:0:0"
I think it is almost the same, but to be sure, I edit it to: PCI:01:00.0
I also tried to edit it to PCI:01:0:0
But after the reboot, it always back to "PCI:1@0:0:0"
Is the point of editing xorg.conf is to match the lspci address with the BUSID, and then the OC value in onebash file can be appiled? I actually do not understand the concept here since I am a very newbie Linux.
Just for the record, I set my powerlimit to 185 and so my card can get around 620sol. I guess if I can apply the OC value, it can go up to 680, which is pretty good.
I added a mostly compatible nvOC image for the ASUS PRIME Z270-A Motherboard
The SHA256 hash (for the zip) is:
ASUS PRIME Z270-A (in stock, 7x gpu (only 6x OC)) Link
nvOC is for fast 16gb or larger USB keys only: I highly recommend using this 16gb one: https://www.amazon.com/dp/B00S5V5PMY
This image includes plusCPU setting to enable cpuminer-opt to mine XMR while mining another COIN with the GPUs.
This image has the newest oneBash supporting these COIN selections:
ZEC ZCL FTC LBC MUSIC ETC EXP ETH DCR PASC
DUAL_ETC_DCR DUAL_ETC_PASC DUAL_ETC_LBC DUAL_ETC_SC
DUAL_EXP_DCR DUAL_EXP_PASC DUAL_EXP_LBC DUAL_EXP_SC
DUAL_ETH_DCR DUAL_ETH_PASC DUAL_ETH_LBC DUAL_ETH_SC
DUAL_MUSIC_DCR DUAL_MUSIC_PASC DUAL_MUSIC_LBC DUAL_MUSIC_SC
cpuminer-opt is compiled for several different CPUs in this image. I built this image with a G4560 CPU.
To recompile for a different cpu:
This motherboard requires the following bios changes before it will work correctly with nvOC:
ensure 'Above 4G Decoding' is enabled in the bios.
ensure PTP aware OS: is set to 'Not PTP Aware' in the bios.
ensure you 'Clear Secure Boot Keys' in the bios
Also please note that this image will only OC 6x GPUs, the 7th GPU will be recognized but it cannot be OCed or have its fan speed manually set; it will only use auto fans and run at stock clocks. I am hoping the next Nvidia driver will allow for more cards.
The SHA256 hash (for the zip) is:
Quote
67b57b2aca9bf181f7fb4c76333d5d85b3837193a936c3106e34e0736c7aa943
ASUS PRIME Z270-A (in stock, 7x gpu (only 6x OC)) Link
nvOC is for fast 16gb or larger USB keys only: I highly recommend using this 16gb one: https://www.amazon.com/dp/B00S5V5PMY
This image includes plusCPU setting to enable cpuminer-opt to mine XMR while mining another COIN with the GPUs.
This image has the newest oneBash supporting these COIN selections:
ZEC ZCL FTC LBC MUSIC ETC EXP ETH DCR PASC
DUAL_ETC_DCR DUAL_ETC_PASC DUAL_ETC_LBC DUAL_ETC_SC
DUAL_EXP_DCR DUAL_EXP_PASC DUAL_EXP_LBC DUAL_EXP_SC
DUAL_ETH_DCR DUAL_ETH_PASC DUAL_ETH_LBC DUAL_ETH_SC
DUAL_MUSIC_DCR DUAL_MUSIC_PASC DUAL_MUSIC_LBC DUAL_MUSIC_SC
cpuminer-opt is compiled for several different CPUs in this image. I built this image with a G4560 CPU.
To recompile for a different cpu:
Quote
press f12 to open the guake terminal
enter the command:
cd cpuOPT
and press enter
then type:
./build.sh
and press enter
this will recompile for your cpu; after it is done, if you change plusCPU to YES in oneBash and enter your XMR info you will mine a little XMR on the side.
enter the command:
cd cpuOPT
and press enter
then type:
./build.sh
and press enter
this will recompile for your cpu; after it is done, if you change plusCPU to YES in oneBash and enter your XMR info you will mine a little XMR on the side.
This motherboard requires the following bios changes before it will work correctly with nvOC:
ensure 'Above 4G Decoding' is enabled in the bios.
ensure PTP aware OS: is set to 'Not PTP Aware' in the bios.
ensure you 'Clear Secure Boot Keys' in the bios
Also please note that this image will only OC 6x GPUs, the 7th GPU will be recognized but it cannot be OCed or have its fan speed manually set; it will only use auto fans and run at stock clocks. I am hoping the next Nvidia driver will allow for more cards.
Hello, I use the MOBO ASUS Z270A Prime, so which image should I download? I downloaded the MSI z270A and I am not sure if it was a good idea since I can not boot to the Utunbu, it keep stuck on the loading screen, like this http://i303.photobucket.com/albums/nn129/Quinflax/IMAG0079.jpg
I waited for more than 30 minutes but nothing change.
My rig contains 7 gpu galax 1080ti, I tried to reduce the number to 3 but but the problem is still there. I can still load to Window or Utunbu installed on SSD.
Please help.
I waited for more than 30 minutes but nothing change.
My rig contains 7 gpu galax 1080ti, I tried to reduce the number to 3 but but the problem is still there. I can still load to Window or Utunbu installed on SSD.
Please help.
Ok I have a working image for 7x gpu (only 6x OC); uploading it now, should be up in about 2 hours.
You will have to make 3 changes to the bios.
ensure 'Above 4G Decoding' is enabled in the bios.
ensure PTP aware OS: is set to 'Not PTP Aware' in the bios.
ensure you 'Clear Secure Boot Keys' in the bios.
Hello, I use the MOBO ASUS Z270A Prime, so which image should I download? I downloaded the MSI z270A and I am not sure if it was a good idea since I can not boot to the Utunbu, it keep stuck on the loading screen, like this http://i303.photobucket.com/albums/nn129/Quinflax/IMAG0079.jpg
I waited for more than 30 minutes but nothing change.
My rig contains 7 gpu galax 1080ti, I tried to reduce the number to 3 but but the problem is still there. I can still load to Window or Utunbu installed on SSD.
Please help.
I waited for more than 30 minutes but nothing change.
My rig contains 7 gpu galax 1080ti, I tried to reduce the number to 3 but but the problem is still there. I can still load to Window or Utunbu installed on SSD.
Please help.
In the future never wait for more than 7 mins; nothing should ever take longer than that.
What CPU are you using? Sometimes this will make a difference.
I am going to test my Z270-A Prime now. I will let you know what I find, / upload a new image for this mobo after if I get it to work. I'll be optimistic and assume I will be able to.
If I do this; wouldn't it also prevent a user from being able to reattach the usb to a windows pc to modify or copy their oneBash? I intentionally made the partition with oneBash a windows partition, to ensure that windows users could interact with it.
I have no problem having an image that supports both usb and ssd; I thought it was best to direct users to use a USB key instead of an ssd in order to save users ~$30. I will ensure that I implement ssd support in the next version, as if you think it is important; others probably do as well.
Quote
You might also want to through this up on github. People can submit issues and track progress. Others, such as myself, can contribute. For instance, I'd be happy to build an ansible playbook so you can automate the build process.
I will get to this eventually. Thanks for offer to build a playbook, I may take you up on that later. I have some ideas I want to implement which may make this unnecessary. I am currently only doing this in my freetime; soon I will go crypto fulltime (for the second time) and really get to work on this and other projects.
It would prevent them from being able to mount the Windows partition and edit directly. I'd suggest you consider making the onebash file available by itself for download. People can edit on Windows/Mac/etc, and then use scp to copy it to the mining rig.
Setup would be - burn image to whatever. Once the machine starts - scp onebash, and go.
BTW - I only used SSD's because I have a bunch of 30G ones laying around, and I'm impatient and like faster boot times.
For my case, I am consolidating my smaller AMD ZEC rigs mostly R9 Nanos and R9-390s to 6-7 GPU format and bigger PSUs.
This will release several items like motherboards and SSDs (mostly Biostar Z170-GT7s and 120GB Kingston and 64GB Kingspec SSDs).
It will be good to recycle these fine mining hardware
If I do this; wouldn't it also prevent a user from being able to reattach the usb to a windows pc to modify or copy their oneBash? I intentionally made the partition with oneBash a windows partition, to ensure that windows users could interact with it.
I have no problem having an image that supports both usb and ssd; I thought it was best to direct users to use a USB key instead of an ssd in order to save users ~$30. I will ensure that I implement ssd support in the next version, as if you think it is important; others probably do as well.
Quote
You might also want to through this up on github. People can submit issues and track progress. Others, such as myself, can contribute. For instance, I'd be happy to build an ansible playbook so you can automate the build process.
I will get to this eventually. Thanks for offer to build a playbook, I may take you up on that later. I have some ideas I want to implement which may make this unnecessary. I am currently only doing this in my freetime; soon I will go crypto fulltime (for the second time) and really get to work on this and other projects.
It would prevent them from being able to mount the Windows partition and edit directly. I'd suggest you consider making the onebash file available by itself for download. People can edit on Windows/Mac/etc, and then use scp to copy it to the mining rig.
Setup would be - burn image to whatever. Once the machine starts - scp onebash, and go.
BTW - I only used SSD's because I have a bunch of 30G ones laying around, and I'm impatient and like faster boot times.
See the op you can download the newest oneBash in a zip, its link it near the top. Also on all nvOC firefox has a link to the OP should it should be easy to download on rig.
I plan on implementing push operations from an app which will run on the local network; for users who aren't used to interacting with other computers over a network.
hi fullzero - i am repurposing my older AMD ZEC boards for nvoc.
Which image should I use compatible for the folloiwng board:
BIOSTAR RACING Z170GT7 LGA 1151 Intel Z170 HDMI USB 3.1 USB 3.0 ATX Intel Motherboard
https://www.newegg.com/Product/Product.aspx?Item=N82E16813138421
It has a 4 x 16x PCI slot motherboard meant for riserless implementation for 4 GPUs.
I intend to replace existing 4 x R9 Nanos with 4 x 1080ti
Please advise.
Thanks
Which image should I use compatible for the folloiwng board:
BIOSTAR RACING Z170GT7 LGA 1151 Intel Z170 HDMI USB 3.1 USB 3.0 ATX Intel Motherboard
https://www.newegg.com/Product/Product.aspx?Item=N82E16813138421
It has a 4 x 16x PCI slot motherboard meant for riserless implementation for 4 GPUs.
I intend to replace existing 4 x R9 Nanos with 4 x 1080ti
Please advise.
Thanks
Try the MSI Z170-A GAMING M5 image
Is probably the closest. Of course I we won't know for sure until someone tries.
You may need to change the pcie addresses in the xorg.conf file before the cards will all OC:
Quote
so press f12 to open the guake terminal
If cpuminer-opt is running rightclick over the guake terminal and select new tab or press ctrl + c to stop it.
then enter:
lspci | grep VGA
this will list your gpus and their pcie addresses
then enter:
gksu gedit '/etc/X11/xorg.conf'
and enter the password:
miner1
when prompted
gedit should now be open with root access to the xorg.conf file
Find the Device section and alter the
BusID "PCI:1:0:0"
on each Device to match the addressing from lspci (only change the numbers)
save
close all mining processes if open
logout
login, and all cards (up to 6x) should now OC if you did this correctly.
If cpuminer-opt is running rightclick over the guake terminal and select new tab or press ctrl + c to stop it.
then enter:
lspci | grep VGA
this will list your gpus and their pcie addresses
then enter:
gksu gedit '/etc/X11/xorg.conf'
and enter the password:
miner1
when prompted
gedit should now be open with root access to the xorg.conf file
Find the Device section and alter the
BusID "PCI:1:0:0"
on each Device to match the addressing from lspci (only change the numbers)
save
close all mining processes if open
logout
login, and all cards (up to 6x) should now OC if you did this correctly.
Hello, I use the MOBO ASUS Z270A Prime, so which image should I download? I downloaded the MSI z270A and I am not sure if it was a good idea since I can not boot to the Utunbu, it keep stuck on the loading screen, like this http://i303.photobucket.com/albums/nn129/Quinflax/IMAG0079.jpg
I waited for more than 30 minutes but nothing change.
My rig contains 7 gpu galax 1080ti, I tried to reduce the number to 3 but but the problem is still there. I can still load to Window or Utunbu installed on SSD.
Please help.
I waited for more than 30 minutes but nothing change.
My rig contains 7 gpu galax 1080ti, I tried to reduce the number to 3 but but the problem is still there. I can still load to Window or Utunbu installed on SSD.
Please help.
If I do this; wouldn't it also prevent a user from being able to reattach the usb to a windows pc to modify or copy their oneBash? I intentionally made the partition with oneBash a windows partition, to ensure that windows users could interact with it.
I have no problem having an image that supports both usb and ssd; I thought it was best to direct users to use a USB key instead of an ssd in order to save users ~$30. I will ensure that I implement ssd support in the next version, as if you think it is important; others probably do as well.
Quote
You might also want to through this up on github. People can submit issues and track progress. Others, such as myself, can contribute. For instance, I'd be happy to build an ansible playbook so you can automate the build process.
I will get to this eventually. Thanks for offer to build a playbook, I may take you up on that later. I have some ideas I want to implement which may make this unnecessary. I am currently only doing this in my freetime; soon I will go crypto fulltime (for the second time) and really get to work on this and other projects.
It would prevent them from being able to mount the Windows partition and edit directly. I'd suggest you consider making the onebash file available by itself for download. People can edit on Windows/Mac/etc, and then use scp to copy it to the mining rig.
Setup would be - burn image to whatever. Once the machine starts - scp onebash, and go.
BTW - I only used SSD's because I have a bunch of 30G ones laying around, and I'm impatient and like faster boot times.
hi fullzero - i am repurposing my older AMD ZEC boards for nvoc.
Which image should I use compatible for the folloiwng board:
BIOSTAR RACING Z170GT7 LGA 1151 Intel Z170 HDMI USB 3.1 USB 3.0 ATX Intel Motherboard
https://www.newegg.com/Product/Product.aspx?Item=N82E16813138421
It has a 4 x 16x PCI slot motherboard meant for riserless implementation for 4 GPUs.
I intend to replace existing 4 x R9 Nanos with 4 x 1080ti
Please advise.
Thanks
Which image should I use compatible for the folloiwng board:
BIOSTAR RACING Z170GT7 LGA 1151 Intel Z170 HDMI USB 3.1 USB 3.0 ATX Intel Motherboard
https://www.newegg.com/Product/Product.aspx?Item=N82E16813138421
It has a 4 x 16x PCI slot motherboard meant for riserless implementation for 4 GPUs.
I intend to replace existing 4 x R9 Nanos with 4 x 1080ti
Please advise.
Thanks
That is what I thought; just wanted to make sure I understood what you where suggesting. I didn't know I had to change ownership with chown; I have never been a *nix system administrator. I have some linux and unix experience (about 9 years); but most of it was very specialized, and generally limited to networking.
I will add implementing your suggested changes and testing them out to the list of:
testing Asus - PRIME Z270-A mobo
improving amdOC beta
lan management monitor / push / update app
dynamically editing xorg.conf automatically
modify / test expectless version of oneBash
potentially if members want ( re-add ssd support )
There's no real reason SSD and USB support can't be the same image. The issue that makes the SSD special is the Windows partition. I'd recommend removing that and allow have the users edit the file once the mining machines starts. Then, the image supports both USB and small SSDs.
If I do this; wouldn't it also prevent a user from being able to reattach the usb to a windows pc to modify or copy their oneBash? I intentionally made the partition with oneBash a windows partition, to ensure that windows users could interact with it.
I have no problem having an image that supports both usb and ssd; I thought it was best to direct users to use a USB key instead of an ssd in order to save users ~$30. I will ensure that I implement ssd support in the next version, as if you think it is important; others probably do as well.
Quote
You might also want to through this up on github. People can submit issues and track progress. Others, such as myself, can contribute. For instance, I'd be happy to build an ansible playbook so you can automate the build process.
I will get to this eventually. Thanks for offer to build a playbook, I may take you up on that later. I have some ideas I want to implement which may make this unnecessary. I am currently only doing this in my freetime; soon I will go crypto fulltime (for the second time) and really get to work on this and other projects.
fullzero.... any "dashboard" feature ?
if I have say... 10 nvidia zec rigs powered by nvoc.... it will be nice to see a simple dashboard to ensure all nvoc rigs are up and running.
maybe this is a monitoring issue rather than nvoc.... comments?
I consider: lan management monitor / push / update app to include that.
To me; a dashboard is part of monitoring. So yes, it is planned.
That is what I thought; just wanted to make sure I understood what you where suggesting. I didn't know I had to change ownership with chown; I have never been a *nix system administrator. I have some linux and unix experience (about 9 years); but most of it was very specialized, and generally limited to networking.
I will add implementing your suggested changes and testing them out to the list of:
testing Asus - PRIME Z270-A mobo
improving amdOC beta
lan management monitor / push / update app
dynamically editing xorg.conf automatically
modify / test expectless version of oneBash
potentially if members want ( re-add ssd support )
There's no real reason SSD and USB support can't be the same image. The issue that makes the SSD special is the Windows partition. I'd recommend removing that and allow have the users edit the file once the mining machines starts. Then, the image supports both USB and small SSDs.
If I do this; wouldn't it also prevent a user from being able to reattach the usb to a windows pc to modify or copy their oneBash? I intentionally made the partition with oneBash a windows partition, to ensure that windows users could interact with it.
I have no problem having an image that supports both usb and ssd; I thought it was best to direct users to use a USB key instead of an ssd in order to save users ~$30. I will ensure that I implement ssd support in the next version, as if you think it is important; others probably do as well.
Quote
You might also want to through this up on github. People can submit issues and track progress. Others, such as myself, can contribute. For instance, I'd be happy to build an ansible playbook so you can automate the build process.
I will get to this eventually. Thanks for offer to build a playbook, I may take you up on that later. I have some ideas I want to implement which may make this unnecessary. I am currently only doing this in my freetime; soon I will go crypto fulltime (for the second time) and really get to work on this and other projects.
fullzero.... any "dashboard" feature ?
if I have say... 10 nvidia zec rigs powered by nvoc.... it will be nice to see a simple dashboard to ensure all nvoc rigs are up and running.
maybe this is a monitoring issue rather than nvoc.... comments?
That is what I thought; just wanted to make sure I understood what you where suggesting. I didn't know I had to change ownership with chown; I have never been a *nix system administrator. I have some linux and unix experience (about 9 years); but most of it was very specialized, and generally limited to networking.
I will add implementing your suggested changes and testing them out to the list of:
testing Asus - PRIME Z270-A mobo
improving amdOC beta
lan management monitor / push / update app
dynamically editing xorg.conf automatically
modify / test expectless version of oneBash
potentially if members want ( re-add ssd support )
There's no real reason SSD and USB support can't be the same image. The issue that makes the SSD special is the Windows partition. I'd recommend removing that and allow have the users edit the file once the mining machines starts. Then, the image supports both USB and small SSDs.
If I do this; wouldn't it also prevent a user from being able to reattach the usb to a windows pc to modify or copy their oneBash? I intentionally made the partition with oneBash a windows partition, to ensure that windows users could interact with it.
I have no problem having an image that supports both usb and ssd; I thought it was best to direct users to use a USB key instead of an ssd in order to save users ~$30. I will ensure that I implement ssd support in the next version, as if you think it is important; others probably do as well.
Quote
You might also want to through this up on github. People can submit issues and track progress. Others, such as myself, can contribute. For instance, I'd be happy to build an ansible playbook so you can automate the build process.
I will get to this eventually. Thanks for offer to build a playbook, I may take you up on that later. I have some ideas I want to implement which may make this unnecessary. I am currently only doing this in my freetime; soon I will go crypto fulltime (for the second time) and really get to work on this and other projects.
That is what I thought; just wanted to make sure I understood what you where suggesting. I didn't know I had to change ownership with chown; I have never been a *nix system administrator. I have some linux and unix experience (about 9 years); but most of it was very specialized, and generally limited to networking.
I will add implementing your suggested changes and testing them out to the list of:
testing Asus - PRIME Z270-A mobo
improving amdOC beta
lan management monitor / push / update app
dynamically editing xorg.conf automatically
modify / test expectless version of oneBash
potentially if members want ( re-add ssd support )
There's no real reason SSD and USB support can't be the same image. The issue that makes the SSD special is the Windows partition. I'd recommend removing that and allow have the users edit the file once the mining machines starts. Then, the image supports both USB and small SSDs.
You might also want to through this up on github. People can submit issues and track progress. Others, such as myself, can contribute. For instance, I'd be happy to build an ansible playbook so you can automate the build process.
Jump to: