| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: BOINC Agent Support
Thread: Linux Upgrade: Best Practices to Preserve Device ID? |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 24
|
|
| Author |
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7846 Status: Offline Project Badges: 
|
Surely you will not be able to have two T7400. If you do a clone, then one of them (I think the one which will be launched later) will be registered as a new machine. You may be entirely correct. But, when I get another machine to replace the original I may just try it and see what happens. Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 865 Status: Offline Project Badges: 
|
Edited to add: This post is deprecated, since I tested using just Zika work units, which did not error, and thought the root cause was because of a faulty upgrade. I re-tested with SCC1 work units and got the error again. The root cause is indeed Debian 10 (buster) using a kernel that disables the VSYSCALL emulation parameter. See my next post for the re-test.
----------------------------------------Since I'm now on a clean install of Buster (compared to the original post of this thread), I decided to test @xithryx's idea. I reversed @daka's original workaround (that did work for me btw when I upgraded): I edited /etc/default/grub and changed: GRUB_CMDLINE_LINUX_DEFAULT="quiet vsyscall=emulate"back to its default: GRUB_CMDLINE_LINUX_DEFAULT="quiet" then: sudo update-grub and Reboot. After a reboot I fetched a couple WCG work units, and they are executing normally with no Error (e.g. the Segmentation fault error). So there may be some accuracy to what xithryx said that somehow when I did the in-place upgrade from Debian 9 to Debian 10 that it borked some libraries. I'm running this all headless (i.e. not using BOINC Manager) so there's no GUI components to BOINC and I only installed the "boinc-client" 7.14.2 package, but I suppose the upgrade didn't upgrade some dependent libraries or something that BOINC needed. Now that it's working on a clean install without needing to do the "vsyscall=emulate" part, that points to the upgrade process not going 100%.
[Edit 3 times, last edit by hchc at Aug 26, 2019 12:10:26 PM] |
||
|
|
daka
Advanced Cruncher Sweden Joined: Apr 4, 2017 Post Count: 92 Status: Offline Project Badges: 
|
After a reboot I fetched a couple WCG work units, and they are executing normally with no Error (e.g. the Segmentation fault error). I'm guessing none from the HST or SCC projects? You will probably get problems once you get one of them. They seem to be the project binaries currently compiled with glibc 2.13 or earlier. From the Debian kernel changelog for version 4.10: * [amd64] Enable LEGACY_VSYSCALL_NONE instead of LEGACY_VSYSCALL_EMULATE and from /usr/share/doc/linux-image-amd64/NEWS.Debian.gz * From Linux 4.10, the old 'virtual syscall' interface on 64-bit PCs
2 x i5-5300U @ 2.7GHz (2 x 2c4t, 40W power usage total)
46 x i5-5200U @ 2.5GHz (46 x 2c4t, 920W power usage total) Not running currently: 96 x i5-7200U @ 3.1GHz (96 x 2c4t, 2400W power usage total) |
||
|
|
hchc
Veteran Cruncher USA Joined: Aug 15, 2006 Post Count: 865 Status: Offline Project Badges:
|
@daka said:
----------------------------------------@hchc said: After a reboot I fetched a couple WCG work units, and they are executing normally with no Error (e.g. the Segmentation fault error). I'm guessing none from the HST or SCC projects? You will probably get problems once you get one of them. They seem to be the project binaries currently compiled with glibc 2.13 or earlier. Nice catch. I stand corrected. When I did my test, I downloaded a couple work units -- they happened to both be Zika -- and since they didn't error out, I called it a day. Just now, I forced a download of SCC1 work units and got the error again: <core_client_version>7.14.2</core_client_version> <![CDATA[ <message> process got signal 11</message> <stderr_txt> SIGSEGV: segmentation violation </stderr_txt> ]]> After adding the "vsyscall=emulate" kernel parameter again per your first post and rebooting, SCC1 work units are proceeding without error. So it turns out @daka is indeed correct that this has everything to do with Debian 10 (with kernel 4.19.x) disabling VSYSCALL and not @xithryx's suspicion that it was due to a faulty upgrade from Debian 9 (stretch) to 10 (buster). The clean install I just did had nothing to do with it: vsyscall emulation is the sole root cause. Solution would be for WCG Techs to compile the problem binaries with at least glibc 2.14 if not the latest and greatest.
[Edit 2 times, last edit by hchc at Aug 26, 2019 12:05:56 PM] |
||
|
|
|