Quote from: S9k on July 09, 2017, 09:50:30 AM

Quote from: TenaciousJ on July 09, 2017, 08:59:29 AM

Quote from: S9k on July 09, 2017, 07:44:14 AM

Quote from: fullzero on July 09, 2017, 04:58:34 AM

Quote from: RMH on July 09, 2017, 04:18:11 AM

Quote from: fullzero on July 09, 2017, 03:56:18 AM

Quote from: RMH on July 09, 2017, 03:44:24 AM

First off thanks for all the work Fullzero!

I've been fighting with Win10 on my rig for a month. Can't get it to recognize any more than 3 of my 1070 cards, and one always is disabled with an error. So I've decided to dump Win10.

I've just got nvoc 0017 running with my old USB 2.0 stick on my ASUS Prime Z270-A with 6 Geforce GTX 1070s rig and I am not sure now how to get the mining started.

I guess I was under the impression that it would start automatically on boot but I must have missed something in the setup. It's just sitting there with the terminal screen open.

Also in the Nvidia X server settings it's also only recognizing 3 of the 1070 gpus. I'm hoping this is something that can be easily worked out as I'd hate to think that 3 of the 6 1070's I have only had for a month are bad.

Thanks in advance for any help.

If you had the same problem with windows only recognizing 3 out of 6 GPUs; this indicates there is most likely a hardware problem.

Have you tried swapping your risers?

How are you powering your risers?

What kind of risers are you using?

If you run with only 3x GPUs and it works:

swap out the 3 working GPUs with the 3 that aren't being recognized and see if they work.

Actually hardware wise I've already change motherboards thinking it was the MSI Z170A SLI Plus that I started out with. I sent it back to Amazon earlier this week and ordered the Asus.

The risers are directly powered by the SATA cable from the PSU. These are the risers... https://www.amazon.com/Extender-Powered-Extension-Adapter-Card-Currency/dp/B072MFBYCM/ref=sr_1_10?s=electronics&ie=UTF8&qid=1499386958&sr=1-10&keywords=PCIe%2BPowered%2BRiser%2BAdapter%2BCard%2B-%2BUSB%2B3.0%2BPCIe%2B1x%2Bto%2B16x%2BExtender%2BCard%2B-%2B6-Pin%2BPCI-E%2Bto%2BSATA%2BPower%2BCable&th=1

Yes I have swapped them around many time, but when I was on win10, haven't yet with nvoc as I just got it going tonight. All of them worked in that testing.

Just a side note here.... I shut down the rig after I posted the first post and just powered it back a few mins ago. Getting this scrolling on the terminal now...

bash: /media/m1/1263-A96E/oneBash: Permission denied
dos2unix: /media/m1/1263-A96E/oneBash: No such file or directory
dos2unix: Skipping /media/m1/1263-A96E/oneBash, not a regular file.

I have to laugh at myself cause I've obviously dorked something up I guess.

This usually means there is a problem with the image.

I would re image the USB key.

Let me know if that works.

hi, it is not problems of image.
these are problems of the FAT32 file system which falls after each incorrect reset. You can find such line in dmesg:

120.350515] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
I don't trust FAT32 and have transferred oneBash to other place.
At me it is impossible to stabilize my system in any way. I observe a large number of restarts which I can't analyse.
Syslog doesn't contain anything useful.

m1@m1-desktop:~$ last reboot
reboot system boot 4.4.0-83-generic Sun Jul 9 04:36 still running
reboot system boot 4.4.0-83-generic Sun Jul 9 00:00 still running
reboot system boot 4.4.0-83-generic Sat Jul 8 17:50 still running
reboot system boot 4.4.0-83-generic Sat Jul 8 15:31 still running
reboot system boot 4.4.0-83-generic Sat Jul 8 14:56 still running
reboot system boot 4.4.0-83-generic Sat Jul 8 14:48 still running
reboot system boot 4.4.0-83-generic Sat Jul 8 12:58 still running
reboot system boot 4.4.0-83-generic Sat Jul 8 10:10 still running
reboot system boot 4.4.0-83-generic Sat Jul 8 09:54 still running
reboot system boot 4.4.0-83-generic Sat Jul 8 08:27 still running
reboot system boot 4.4.0-83-generic Sat Jul 8 03:16 still running
reboot system boot 4.4.0-83-generic Fri Jul 7 23:31 still running
reboot system boot 4.4.0-83-generic Fri Jul 7 22:52 still running
reboot system boot 4.4.0-83-generic Fri Jul 7 20:02 still running
reboot system boot 4.4.0-83-generic Fri Jul 7 16:26 still running
reboot system boot 4.4.0-83-generic Fri Jul 7 10:00 still running

I need methodology of a solution. How to find the reason of a collapse of an operating system and restart. What video card exceeds admissible values and is unstable? I think it it will be interesting to many. Thank you very much!

I had a problem with the fat32 partition on my images. I just had to reimage it... use HDD Raw Copy. It doesn't ALWAYS work, but it does most of the time. Also, make sure your flash drive or hard drive is bigger than 16gb. I ran into a problem with mine where the drive was just a hair shy of the required size for the image and that caused partition file table problems that made the first part unreadable.

You could also use gparted to try to repair the partition which works sometimes. Or use TestDisk if you're savvy with partition file table manipulation at all.

http://www.cgsecurity.org/wiki/TestDisk_Download

It isn't important at all as you do image what software and in what operating system. At the first loading everything is read perfectly!
Important the fact that after incorrect completion of nvOC (for example the system is too overclocked) data on FAT32 /dev/sda1 are damaged and you are stimulated every time to repair this partition and to do mount, remount. look above how many restarts of nvOC at me happen in days. Every time is a potential problem of damage of FAT32. IMHO needs to refuse this partition, to transfer oneBash to other directory and to modify it, using gnome (local) or ssh, sftp (remote).

Of course I will try to find the stable and balanced configuration of my system. I plunge into Linux more and more and I look for analysis techniques of system dumps.
All of good luck!

Quote from: TenaciousJ on July 09, 2017, 04:41:27 PM

I don't disagree with you that oneBash on a fat32 part instead of exFat isn't ideal for a linux o/s to read. I've run into problems today where my oneBash file was just empty entirely and so nvOC wouldn't boot.

Copying oneBash to /home/m1/ on boot might be a more elegant solution to avoid these partition issues, or just avoid that partition entirely by downloading pastebin text directly to /home/m1.

Even windows doesn't like fat32 partitions that small... it forces you to format it in fat instead, so its no surprise that linux doesn't play nice with it I guess.

Most likely the problem is a combination of slow media (although it is possible to have the same problem with fast media) and too short of a timeout in this area of 2unix

Code:

sudo dos2unix /media/m1/1263-A96E/oneBash

sleep 2

bash '/media/m1/1263-A96E/oneBash'

I will increase the timeout in v0018 and most likely this will not be a problem.

I will make the following changes for v0018:

The windows partition will be NTFS.

On first boot (and only first boot) the following will occur:

oneBash will be copied to '/home/m1/oneBash'

dos2unix will run on '/home/m1/oneBash'

the timeout afterwards will be 15 seconds

the windows partition will be zeroized (and will not mount on the next boot)