Development for LHC@home

10/11/2022 14:14:26 | lhcathome-dev | work fetch resumed by user
10/11/2022 14:14:26 | lhcathome-dev | Sending scheduler request: To fetch work.
10/11/2022 14:14:26 | lhcathome-dev | Requesting new tasks for CPU
10/11/2022 14:14:27 | lhcathome-dev | Scheduler request completed: got 2 new tasks
10/11/2022 14:14:27 | lhcathome-dev | Project requested delay of 61 seconds
10/11/2022 14:14:29 | lhcathome-dev | update requested by user
10/11/2022 14:14:29 | lhcathome-dev | Started download of vboxwrapper_26206_windows_x86_64.exe
10/11/2022 14:14:32 | lhcathome-dev | Finished download of vboxwrapper_26206_windows_x86_64.exe
10/11/2022 14:14:33 | lhcathome-dev | Starting task CMS_2966346_1667912538.876527_0
10/11/2022 14:14:33 | lhcathome-dev | Starting task CMS_2970324_1667914940.149287_0

2022-11-10 14:14:40 (7768): Adding virtual disk drive to VM. (CMS_2022_09_07.vdi)
2022-11-10 14:14:47 (7768): Error in check if parent hdd is registered.
Command:
VBoxManage -q showhdinfo "C:\ProgramData\BOINC/projects/lhcathomedev.cern.ch_lhcathome-dev/CMS_2022_09_07.vdi" 
Output:
VBoxManage.exe: error: Could not find file for the medium 'C:\ProgramData\BOINC\projects\lhcathomedev.cern.ch_lhcathome-dev\CMS_2022_09_07.vdi' (VERR_FILE_NOT_FOUND)
VBoxManage.exe: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component MediumWrap, interface IMedium, callee IUnknown
VBoxManage.exe: error: Context: "OpenMedium(Bstr(pszFilenameOrUuid).raw(), enmDevType, enmAccessMode, fForceNewUuidOnOpen, pMedium.asOutParam())" at line 205 of file VBoxManageDisk.cpp

Thought it was a interrupt at 13 UTC in the CMS-Servers (WM-Agent upgrade).

No, there were enough jobs.

Since 05.30 UTC this morning we ran out of CMS-jobs.

Jobs now available again. I believe the little glitch here in -dev has been repaired but I won't be able to confirm it myself until mid-morning tomorrow.

Not looking good so far:

cmsRun  -j FrameworkJobReport.xml PSet.py
warn  [frontier.c:1014]: Request 507 on chan 1 failed at Thu Sep 15 21:48:52 2022: -6 [fn-socket.c:239]: read from 172.64.206.32 timed out after 10 seconds
warn  [frontier.c:1136]: Trying next server cms-frontier.openhtc.io[172.64.207.32]
warn  [frontier.c:1014]: Request 701 on chan 1 failed at Thu Sep 15 21:49:07 2022: -6 [fn-socket.c:239]: read from 172.64.207.32 timed out after 10 seconds
warn  [frontier.c:1136]: Trying next server cms-frontier.openhtc.io[2606:4700:e6::ac40:cf20]
warn  [frontier.c:1014]: Request 702 on chan 1 failed at Thu Sep 15 21:49:07 2022: -9 [fn-socket.c:85]: network error on connect to 2606:4700:e6::ac40:cf20: Network is unreachable
warn  [frontier.c:1136]: Trying next server cms-frontier.openhtc.io[2606:4700:e6::ac40:ce20]
warn  [frontier.c:1014]: Request 703 on chan 1 failed at Thu Sep 15 21:49:07 2022: -9 [fn-socket.c:85]: network error on connect to 2606:4700:e6::ac40:ce20: Network is unreachable
warn  [frontier.c:1136]: Trying next server cms1-frontier.openhtc.io
warn  [frontier.c:1014]: Request 704 on chan 1 failed at Thu Sep 15 21:49:27 2022: -6 [fn-urlparse.c:178]: host name cms1-frontier.openhtc.io problem: Name or service not known
warn  [frontier.c:1136]: Trying next server cms2-frontier.openhtc.io

... but finally:

Begin processing the 1st record. Run 1, Event 1920001, LumiSection 3841 on stream 0 at 15-Sep-2022 21:51:36.256 CEST

There has been a delay, I'm afraid. Still, tomorrow is for clean-up!

I have a problem on my Win10 box -- a task ran all night without actually running a job. Started a new VM just now and it seemed to try to run the glidein script in the wrong directory.

I'm running a new CMS-task doing its first CMS-job inside the VM.
After 25% into this first job, I noticed a differencing image in the snapshot folder with the size of 4444913664 bytes, 4.13 GB.

Is this to be expected?

The only current glitch is that the "Show VM Console" button doesn't appear (nor does the "Show graphics" option show the current logs) so I cannot check that it is actually running cmsRun jobs.

The reason for this is reported here, but you already found the suggested workaround.

2022-07-28 23:52:52 (212243): Required extension pack not installed, remote desktop not enabled.

[The only current glitch is that the "Show VM Console" button doesn't appear (nor does the "Show graphics" option show the current logs) so I cannot check that it is actually running cmsRun jobs.

[ I managed to get vboxwrapper to compile by using devtools-11; gcc 8.0 didn't have a 32-bit libstdc++.a.
Now waiting for my task backoff to time-out so I can try with the "new" vboxwrapper -- at least it passes an ldd test without problem.

[lxplus789:~] > condor_status -pool vocms0840.cern.ch|grep '@9-'
glidein_4804_350226202@9-4416-18346           LINUX      X86_64 Claimed   Busy          3.360 2500  0+00:23:36
glidein_4821_834398040@9-4599-1833            LINUX      X86_64 Claimed   Busy          1.350 2500  0+00:20:05

In cc_config.xml add/set:
|dont_check_file_sizes|1|/dont_check_file_sizes|
Then reload config files via boincmanager.

Even then the client will occasionally download a fresh copy from the server, e.g. after a crash.

... I managed to get vboxwrapper to compile ...

The most recent changes are not yet merged to BOINC master.
You would have to download them from the links below, then recompile vboxwrapper.
Otherwise you would get a version that may run into the "VirtualBox 4.0" error.

https://github.com/BOINC/boinc/blob/5347c8068c5594cc008dacb80e97c4c85601a08c/samples/vboxwrapper/vbox_common.cpp

https://github.com/BOINC/boinc/blob/5347c8068c5594cc008dacb80e97c4c85601a08c/samples/vboxwrapper/vbox_vboxmanage.cpp

... It seems vboxwrapper_26205_x86_64-pc-linux-gnu was built on a system with glibc 2.29 but I'm using Rocky Linux 8.6 (derived from RHEL 8) which still uses 2.28.

As an option you may want to upgrade to Rocky Linux 9.
It installs glibc-2.34-28.el9_0.x86_64.rpm

For details see:
https://download.rockylinux.org/pub/rocky/
https://download.rockylinux.org/pub/rocky/9/BaseOS/x86_64/os/Packages/g/