[QUOTE=petrw1;541106]5 re-starts in a row P4. Bad luck ... or do I need to wait a few minutes between restarts?[/QUOTE]

I've /never/ not gotten at least a P100 after five attempts immediately after each other. But perhaps try waiting an hour and then do the Factory Reset thing.

[QUOTE=chalsall;541107]OK, thanks very much for the report. I am ***not*** seeing any CP files from the first instance, which can only be explained by the cron sub-system not being installed.[/QUOTE]I have 2 that are running that same exponent again. The second started ~35.6% again, just like the first, same as yesterday. It is at 88% and I will be going offline with this laptop before it hits 100. At this rate, it will never get done during a single session.
:groan:
Groundhog day, yet again.

[QUOTE=Uncwilly;541214]:groan: Groundhog day, yet again.[/QUOTE]

Weird. Sorry about this. I'll have some cycles to drill-down on this tomorrow.

I was able to stay connected long enough for it to complete. It shows as credited.

[QUOTE=chalsall;541107]OK, thanks very much for the report. I am ***not*** seeing any CP files from the first instance, which can only be explained by the cron sub-system not being installed.[/QUOTE]

OK... I've *finally* seen an example of this happening with one of my own instances. And, as inferred, it is because of the cron sub-system not being installed.[CODE]
20200331_145125: DEEP: AptA: Reading package lists...
Building dependency tree...
Reading state information...
Suggested packages:
anacron logrotate checksecurity exim4 | postfix | mail-transport-agent
The following NEW packages will be installed:
cron
0 upgraded, 1 newly installed, 0 to remove and 25 not upgraded.
Need to get 68.8 kB of archives.
After this operation, 253 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu bionic/main amd64 cron amd64 3.0pl1-128.1ubuntu1 [68.8 kB]
Fetched 68.8 kB in 1s (108 kB/s)
dpkg: error: cannot access archive '/var/cache/apt/archives/cron_3.0pl1-128.1ubuntu1_amd64.deb': No such file or directory[/CODE]

Weirdly, I have *never* had this problem with my SSH Reverse Tunnels package, which uses the exact same command to install cron.

Does anyone who regularly works with Ubuntu understand what's going on here? It looks like the package was downloaded successfully, but drilling down on the filesystem shows the package is in fact not where it should be.

Now, to figure out how to recover from this rare edge case... Just retrying the install may not be enough, since both the CPUWrapper script and the CPUPayload both attempt to install and launch cron.

If you are using aptitude or apt-get to install packages, be sure to do:

aptitude update

or

apt-get update

Before installing any packages.

[QUOTE=PhilF;541501]If you are using aptitude or apt-get to install packages, be sure to do:[/QUOTE]

Thank you!!! That almost certainly explains the issue.

I currently have 300 assignments from GPU to 72 that I ran on two work computers. They should have finished a few weeks ago, but I'm stuck at home due to the COVID-19 pandemic and couldn't submit the results. Complicating matters don't have remote access to these systems. Is there a limit on how long assignments can be extended?

[QUOTE=ixfd64;541791]Is there a limit on how long assignments can be extended?[/QUOTE]

How does a year sound? :smile:

Assignments aren't actually expired any longer, except for cases where the user has clearly abandoned the work.

I'd much rather you stay safe than have a few results be submitted!

Current Trial Factoring Depth for all Candidates
 

On the "Current Trial Factoring Depth for all Candidates" report page, does factoring beyond 77 bits get added in to the 77 column?

[QUOTE=Chuck;542256]On the "Current Trial Factoring Depth for all Candidates" report page, does factoring beyond 77 bits get added in to the 77 column?[/QUOTE]

No. That's one of the reports I need to update.

Edit: Updated. Included the links to the new charts.