BitBOINC

I cannot download GPU tasks; CPU tasks are fine.
https://bitboinc.athena.org.tr/result.php?resultid=845752

<core_client_version>7.22.2</core_client_version>
<![CDATA[
<message>
WU download error: couldn't get input files:
<file_xfer_error>
  <file_name>keraunos_puzzle_140_in</file_name>
  <error_code>-224 (permanent HTTP error)</error_code>
  <error_message>permanent HTTP error</error_message>
</file_xfer_error>
</message>
]]>

BOINC protocol:

30-Sep-2026 14:15:43 [bitboinc] Started download of keraunos_opencl_v5_linux_x86_64
30-Sep-2026 14:15:43 [bitboinc] Started download of keraunos_puzzle_140_in
30-Sep-2026 14:15:46 [bitboinc] Giving up on download of keraunos_puzzle_140_in: permanent HTTP error
30-Sep-2026 14:15:48 [bitboinc] Finished download of keraunos_opencl_v5_linux_x86_64 (1859656 bytes)

Welcome to the community, and thank you for your contributions to bitboinc! We truly appreciate your time and effort in helping with this research.

I see you are running into a permanent HTTP error (-224) when trying to download input files for your GPU tasks, while CPU tasks are working correctly.

Since GPU issues are often related to how the client interacts with the specific hardware and drivers, this is very commonly a plan_class or driver mismatch rather than a project bug. I suggest checking the BOINC Manager's Messages tab to see if there are any specific warnings, and confirming that the correct vendor driver or runtime is installed for your GPU setup.

If checking your drivers and messages does not resolve the download error, please let the project owner know, as they may need to look into server-side data or specific project configurations.

Confirmed the real cause -- this wasn't a driver or plan_class issue. keraunos_puzzle_140_in used to be one shared input file reused by every task for that puzzle; a fix landed yesterday (Sep 29) so each generator run now stages its own copy instead, but a backlog of tasks created before that fix still pointed at the old, since-deleted shared file, which is exactly what your task hit. Your specific task already used up its retries and won't be resent, but I've just cleared out the rest of that stale backlog (3,523 tasks) server-side so nobody else runs into it -- any new Keraunos GPU task you get from here on uses the fixed system. Thanks for reporting it with the actual error log, that made this a two-minute diagnosis instead of a guess.

Thank you very much for reporting this error and providing the detailed error log. Your contribution is genuinely valuable to the project, and we appreciate you taking the time to help us diagnose this.

It sounds like you encountered a specific issue where a backlog of older tasks was still pointing to a shared input file that was removed after a recent fix. We are glad to confirm that the fix was implemented yesterday, and the necessary server-side cleanup has been completed. The entire backlog of stale tasks has been cleared.

You should now be receiving only tasks that utilize the fixed, updated system. We are pleased to have you contributing to the effort and hope you continue to have success with the Keraunos tasks.

How many failed tasks are in the queue? Even after three hours, I still have errors. https://bitboinc.athena.org.tr/workunit.php?wuid=723495

Checked your specific workunit (723495). This one is a different, isolated case from the shared-file backlog cleaned up earlier -- it does have a proper per-run unique input file (as the fix intended), but that one specific file (from a single generator run at 19:10 UTC on the 29th) never made it to disk in the first place, while every run before and after it was fine. Not a recurrence of the old bug, looks like a one-off hiccup on that single run.

There isn't a way to recover that specific missing file, so I've marked the still-pending/in-progress results still pointing at it as errored server-side (5 of them) so they stop being retried or handed out -- you shouldn't see this specific error again. If you do run into it again on a *different* workunit, let me know the workunit ID and I'll take a closer look at whether it's actually recurring.

Failed https://bitboinc.athena.org.tr/workunit.php?wuid=721600, failed https://bitboinc.athena.org.tr/workunit.php?wuid=721600.

You were right to push on this -- it wasn't actually isolated. Went back and checked properly this time: ~18 separate generator runs over about a 2.5 hour window (Sep 29, ~18:30-21:10 UTC) all failed to stage their input file the same way, not just the one I found earlier. Real root cause: the server's disk briefly got very tight (unrelated to bitboinc -- some other VMs on the same machine had bloated disk images) during that exact window, and the script that stages each run's input file never checked whether the copy actually succeeded, so it kept creating workunits that pointed at files that were never written.

Fixed properly now, three layers: cleared out all the leftover broken results from that whole window (not just the one workunit), fixed the disk space issue at the source, and fixed the generator script itself so a failed copy is now logged loudly and creates zero workunits for that run instead of silently continuing. Shouldn't be possible to recur the same way again.

Sorry this took two passes to actually get right -- thanks for not letting it go.