Ok I found out that there is a LIBC215 version for O2. But I don't get those on any of my machines.
I guess that's a server/configuration error?
I could be wrong but my impression is that the preference setting and the availability of the libc-2.15 version of the app is for the benefit of people with older systems that don't have the latest versions of libc. According to your earlier post, your system is running a quite recent kernel and has libc-2.28, which is also fairly recent.
So why would you be trying to run an app designed for libc-2.15 or earlier? Have you tried NOT setting the preference for libc-2.15 apps (ie set it to NO instead of YES)? My libc is 2.29 and my setting is on NO and I don't have any problems getting work.
The LIBC215-option is for newer systems:
"This ensures compatibility with new Linux systems that have virtual syscalls disabled, but breaks compatibility with older systems with (G)LIBC prior to 2.15"
The LIBC215 version would work, the native version gives a segmentation fault:
The O2AS20 was a beta app, so you may need to select run beta apps as well. I've picked up a bunch under Debian. Run times are a lot longer than O1OD1 work, my i7-8700's seem to take 12 hours 45 min with them running on all cores.
Credits seem to be set to the same as O1OD1 (1000 per work unit) which given they take more than twice as long seems a bit off. Hopefully the project will adjust that, not that I am fussed about credits but it does make it hard to compare work units.
Also I would suggest not mixing them with other work types as the DCF jumps all over the place when running different apps.
@Markj
You're running debian stretch which is using glibc 2.24. This works with the "native" application.
Your system's glibc doesn't matter here, it's the old glibc that the science application is statically linked to, in combination with the unavailability of vsyscall in your kernel. That's just the same with Markj's backports kernel.
I have verified that I'm also getting the older application with LIBC215 selected. Markj may be right and the newer one had beta status when the O2 search abruptly ended. If that is still the case it should be changed now.
I have "run test applications" enabled and I get O2 workunits for the non-LIBC215, which produce segfaults. So, what do I need to do?
For O1 Engineering Run I get the LIBC215-versions, which run fine.
I have "run test applications" enabled and I get O2 workunits for the non-LIBC215, which produce segfaults. So, what do I need to do?
For O1 Engineering Run I get the LIBC215-versions, which run fine.
Under my preferences I have:
Use CPU - Yes
Use ATI/AMD, Nvidia, Intel GPU - No
Run test apps - Yes
Use LIBC215 - Yes
Under apps I have only the O2AS20 ticked
I did however enable VSYSCALLs before they came up with the apps linked with libc215, so maybe that is why they still run. To fix that you'll need to edit your grub configuration file. There is a rather long message thread about it under Problems and Bug Reports - thats where this came from. You'll need to do this as root or put sudo in front of each command.
nano /etc/default/grub
Comment out the existing GRUB_CMDLINE_LINUX_DEFAULT by putting a # symbol in front of it and paste the following one in:
GRUB_CMDLINE_LINUX_DEFAULT="quiet vsyscall=emulate"
Ok I found out that there is
)
Ok I found out that there is a LIBC215 version for O2. But I don't get those on any of my machines.
I guess that's a server/configuration error?
Have you checked "Run Linux
)
Have you checked "Run Linux app versions built with LIBC 2.15" in your preference page?
Edit: NVM I just saw your previous post
Stef wrote:Ok I found out
)
I could be wrong but my impression is that the preference setting and the availability of the libc-2.15 version of the app is for the benefit of people with older systems that don't have the latest versions of libc. According to your earlier post, your system is running a quite recent kernel and has libc-2.28, which is also fairly recent.
So why would you be trying to run an app designed for libc-2.15 or earlier? Have you tried NOT setting the preference for libc-2.15 apps (ie set it to NO instead of YES)? My libc is 2.29 and my setting is on NO and I don't have any problems getting work.
Cheers,
Gary.
The LIBC215-option is for
)
The LIBC215-option is for newer systems:
"This ensures compatibility with new Linux systems that have virtual syscalls disabled, but breaks compatibility with older systems with (G)LIBC prior to 2.15"
The LIBC215 version would work, the native version gives a segmentation fault:
62522550 Apr 29 21:32 ./einstein_O2AS20-500_1.01_x86_64-pc-linux-gnu
63632957 Apr 15 2018 ./einstein_O2AS20-500_1.01_x86_64-pc-linux-gnu__LIBC215
$ ./einstein_O2AS20-500_1.01_x86_64-pc-linux-gnu --version
Segmentation fault
$ ./einstein_O2AS20-500_1.01_x86_64-pc-linux-gnu__LIBC215 --version
%% Build jenkins-EAH-O2-Release-SLAVE=LIBC215,TARGET=linux-x86_64-16 on pangolin64 at 16
%% BOINC: 22fb1682f3953b8ef3874c651a443a7e35c4a4e7 [] (bm-ubuntu1204-qemu:/home/jenkins/workspace/workspace/EAH-O2-Release/SLAVE/LIBC215/TARGET/linux-x86_64/EinsteinAtHome/source/boinc [(detached from current_gw_apps)])
LAL: 6.18.0.1 (CLEAN f9f1c94b0a4ae84fd5e8c6992235dd36200ffd1b)
LALPulsar: 1.16.0.1 (CLEAN f9f1c94b0a4ae84fd5e8c6992235dd36200ffd1b)
LALApps: 6.21.0.1 (CLEAN f9f1c94b0a4ae84fd5e8c6992235dd36200ffd1b)
The O2AS20 was a beta app, so
)
The O2AS20 was a beta app, so you may need to select run beta apps as well. I've picked up a bunch under Debian. Run times are a lot longer than O1OD1 work, my i7-8700's seem to take 12 hours 45 min with them running on all cores.
Credits seem to be set to the same as O1OD1 (1000 per work unit) which given they take more than twice as long seems a bit off. Hopefully the project will adjust that, not that I am fussed about credits but it does make it hard to compare work units.
Also I would suggest not mixing them with other work types as the DCF jumps all over the place when running different apps.
BOINC blog
@Markj You're running debian
)
@Markj
You're running debian stretch which is using glibc 2.24. This works with the "native" application.
I'm running debian sid/buster, which would require the LIBC215-version to be used.
Stef wrote:@MarkjYou're
)
Your system's glibc doesn't matter here, it's the old glibc that the science application is statically linked to, in combination with the unavailability of vsyscall in your kernel. That's just the same with Markj's backports kernel.
I have verified that I'm also getting the older application with LIBC215 selected. Markj may be right and the newer one had beta status when the O2 search abruptly ended. If that is still the case it should be changed now.
I have "run test
)
I have "run test applications" enabled and I get O2 workunits for the non-LIBC215, which produce segfaults. So, what do I need to do?
For O1 Engineering Run I get the LIBC215-versions, which run fine.
Stef wrote:I have "run test
)
Under my preferences I have:
Use CPU - Yes
Use ATI/AMD, Nvidia, Intel GPU - No
Run test apps - Yes
Use LIBC215 - Yes
Under apps I have only the O2AS20 ticked
I did however enable VSYSCALLs before they came up with the apps linked with libc215, so maybe that is why they still run. To fix that you'll need to edit your grub configuration file. There is a rather long message thread about it under Problems and Bug Reports - thats where this came from. You'll need to do this as root or put sudo in front of each command.
nano /etc/default/grub
Comment out the existing GRUB_CMDLINE_LINUX_DEFAULT by putting a # symbol in front of it and paste the following one in:
GRUB_CMDLINE_LINUX_DEFAULT="quiet vsyscall=emulate"
update-grub
sync
systemctl reboot
BOINC blog
Found the original vsyscalls
)
Found the original vsyscalls message thread here: https://einsteinathome.org/content/vsyscall-now-disabled-latest-linux-distros#comment-162169
Hopefully the admins will get around to a libc215 version of the O2AS20 app at some point.
BOINC blog