I did read it all.
Your “3 hour symptoms” are not the same.
You have not posted information on your pool choice, miner choice, or if you have persistent miner logs enabled.
In fact, you have yet to post a visual from the hiveos.farm worker interface or the pool stats.
Not sure how anyone can assist you with such a lack of information.
You don’t find information about my “3 hour issue” because this thread is about the selfupgrade command that doesn’t work.
I added the information about the 3 hour issue just to let all know that my installation could be in fact corrupted.
Anyway, the main issue here is that the selfupgrade command doesn’t work for me even after running HiveOS from a fresh new installation from a pendrive.
Anybody knows if the fact that I used the same rig ID could let me bring the issue i had before into the new fresh installation? Otherwise I don’t know how is possible that even a new fresh installation can have the same issue as the one installed in the SSD
This is a potentially worse than corruption, but you have provided no data.
Many potential reasons, yes, a bad install, hacking, network issues, and the list goes on. Yet, you have not provided a screen shot of the failure from the shell.
rig.conf or rig id entered with first run process, no. Malware on the station used for flashing, maybe.
Unfortunately, USB drives have their own issues.
Does the hive-replace -y --stable command work when entered via the shell interface?
As I told you before, all the information about the selfupgrade has been already shared in the previous replies.
Here is where the screenshot of the shell was posted. Even if I’m not the one who posted it, i have the same result.
I don’t think that the the install or the computer used to flash the image can be the issue, because the issues that I’m seeing now after the new installation are exactly the same as before. The reason why i decided to do a fresh new installation was exactly this two issues: the selfupgrade command and the 3hour max mining. So i decided to do a new installation to solve them.
Another information is that both the two problems started after executing the hive-replace command in April. Once the process finished the two issues started and never stopped. Now not even after a new installation.
Command Not Found “result” has more than 1 cause. And in that posters image, not yours, there are clearly install errors.
Did yours have the exact same install errors? If so, attempt the below:
If hive-replace -y --stable command runs properly on YOUR rig now, that would be a significant detail in the troubleshooting. Of course, if successful, it will re image the target media. Which you would then want to immediately lock down securely, disable VNC, change passwords, etc.
If your rig provides you a command not found error for hive-replace, your rig is exhibiting classic direct compromise from outside parties.
Let’s confirm or deny that worst case scenario.
I tried so many times the hive-replace command before deciding to do a fresh install.
Do you think that running it now from the USB pendrive can have a different result than before when I was on the SSD installation?
When I tried it with the SSD installation, the hive-replace command always completed successfully, but after the new boot the 2 issue were always there.
Anyway, if you really want to see my shell output I can proved it, but is exactly the same as the one above (I’m talking about the shell output, not the entire screenshot).
It is a good sign the hive-replace works 
Humbly, I’d suggest working with your original SSD as it will be the long term platform and it would support persistent logging to track that “3 hr” issue.
I’d expect we are chasing at least (2) issues.
I don’t think that it’s a problem to work with the USB pendrive, as I could clone bit-wise the entire pendrive into the SSD whenever I want.
I already did it the first time, I set up everything on the pendrive and then moved all into the SSD with a dd command.
I hoped that the hive-replace command could solve my issues in the first place. But now not even a fresh new install can solve them, and this was my last chance for what I know I can do.
Have you attempted a fresh download from the GPU Zip link and flashed with Etcher? This method has yet to fail me and we are talking about many Rigs.
I use this for all my SSD, M2SATA, and the few remaining USBs.
I not doubting your file management skills, but as you see above, some of the same issues were: bad install, hacked rigs, etc.
This is exactly how I did the last installation. I downloaded the zip from the website and flashed the usb pendrive with etcher. I then inserted the pendrive into the rig and started a fresh new OS. I used the same rig ID I had in the previous installation and after logging in I had the exact same 2 issues as before, like I didn’t reinstalled at all.
Personally, I would place the rig.conf file in the hive directory while on the USB flashing workstation.
Do you have direct access to the rig with local monitor and keyboard? As well as via hiveos.farm worker interface?
I have access via the web interface. I can have physical access to the rig but it’s very difficult and can be done just some specific days of the month.
Remote only does reduce a few troubleshooting options.
Is the rig mining for it’s few hours and currently manageable by hiveos.farm worker interface?
Do you get the same error when attempting to upgrade from the “upgrade arrow” or just clicking on the version in yellow?
This is how I discovered the selfupgrade command error. I just tried to update as usual with the web interface and i got an error. The error should also be in one of the screenshots above.
If you believe your error is the same as already posted, you have the solution posted in this thread above.
The problem is that i reflash it and the issue is still here.
If you really want my screenshots, here they are:
This is by just trying to update from the web interface.
There are a few reasons, those commands are not there or are not run.
Have you tried the following from inside hiveshell with no other data: selfupgrade
The only solution I would trust is a rebuild from a known good source, on a known good media, and have it well protected from outsider access.
With the 3hr run time symptoms you shared, I would assume the worst: outside access occurred or source was compromised.
This is what I already did. I downloaded and flashed using a brand new USB pendrive, bought just for this purpose using a windows computer that was always only used occasionally for office work (just writing documents and social media).
I don’t have anything against you, but in the last replies I just re-answered the same questions I answered before and I just did again all the steps I already did before, just to continue the conversation with you.
Just for contest, I’m a computer engineer, not a novice computer user. So I know very well how computer and operative systems work. I was here to find some deep technical HiveOS-specific help that I could miss.
So any good standard practice to avoid simple external or internal corruption has been already taken.
P.S. I’m appreciating your help anyway, I wrote it just to avoid any further time waste for both.
