Message boards : Number crunching : Rosetta 4.0+
Previous · 1 . . . 3 · 4 · 5 · 6 · 7 · 8 · 9 . . . 19 · Next
Author | Message |
---|---|
Jim1348 Send message Joined: 19 Jan 06 Posts: 881 Credit: 52,257,545 RAC: 0 |
Is there an issue system to report this and see any progress. I think this is the system to report. As for progress, we will see. |
[DPC]Remmus Send message Joined: 9 Nov 05 Posts: 6 Credit: 2,466,696 RAC: 0 |
Not much response yet..... :-( |
![]() ![]() Send message Joined: 18 Aug 11 Posts: 4 Credit: 4,526,367 RAC: 0 |
It may be related, but a workaround has been found on World Community Grid project, which some project have a static link to an (quite) old glibc, and devs says they will rebuilt their apps as soon as possible, as many Linux users with recent kernel will encounter the problem. I didn't do it as it seems to enable again some vulnerabilities... |
rjs5 Send message Joined: 22 Nov 10 Posts: 273 Credit: 22,487,487 RAC: 2,163 ![]() |
Is there an issue system to report this and see any progress. ... maybe a workaround to running static linked glibc old applications on glibc 2.27 systems. I don't have access to sources so I had to guess how Rosetta developers had screwed up. I installed a Fedora 28 which uses glibc 2.27 on Oracle Virtualbox and reproduced the "locale" error. "rosetta_4.07_x86_64-pc-linux-gnu: loadlocale.c:129: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed." I edited the Fedora 28 file /etc/locale.conf to add the 2 extra lines below (LC_CTYPE=C and LC_MESSAGES=C). Rebooted the virtual machine. Instead of Rosetta 4.07 x86_64 failing immediately, a 4.07 x86_64 WU is currently 17 minutes into computation and seems to now function. Try this .... cat /etc/locale.conf LANG="en_US.UTF-8" LC_CTYPE=C LC_MESSAGES=C |
Jim1348 Send message Joined: 19 Jan 06 Posts: 881 Credit: 52,257,545 RAC: 0 |
cat: /etc/locale.conf: No such file or directory It doesn't find that file on Ubuntu 18.04. Is there another location? EDIT: Never mind, I just created it and rebooted. I will report how it works on the next x64. |
rjs5 Send message Joined: 22 Nov 10 Posts: 273 Credit: 22,487,487 RAC: 2,163 ![]() |
cat: /etc/locale.conf: No such file or directory For Ubuntu systems try: cat /etc/default/locale I will build a vbox version of 18.04 so i can test it, in case that does not work. |
Jim1348 Send message Joined: 19 Jan 06 Posts: 881 Credit: 52,257,545 RAC: 0 |
For Ubuntu systems try: EDIT: Placing "locale.conf" in the /etc/ directory seems to prevent a terminal window from opening. But /etc/default/local does exit by default, so I will try that once I get rid of /etc/locale.conf. |
rjs5 Send message Joined: 22 Nov 10 Posts: 273 Credit: 22,487,487 RAC: 2,163 ![]() |
For Ubuntu systems try: making the changes to /etc/default/locale works too. BOINC Rosetta works for x86_64. I will work on getting the terminal part figured out. There is a a set-locale command that probably should be used. https://www.thomas-krenn.com/en/wiki/Configure_Locales_in_Ubuntu Install the "Konsole" command to get a "terminal" back Konsole is like terminal |
rjs5 Send message Joined: 22 Nov 10 Posts: 273 Credit: 22,487,487 RAC: 2,163 ![]() |
For Ubuntu systems try: I played around with the LANGUAGE SETTINGS. I set the Region/Language to Canadian which sets all the locale options, rebooted. Terminal came back but Rosetta 4.07 started failing again. I looked at the locale file settings and the LC_time had been removed and LANGUAGE was set to something other than "C". It looks like Konsole works fine in either case, but the "terminal" and Rosetta 4.07 64-bit have incompatibilities and seem to want conflicting locale settings. Maybe tomorrow evening I will try to isolate the specific combination of changes needed. Too bad someone at Rosetta cannot fix their bug. BTW, while 4.07 64-bit is broken, for anyone wanting the object files, you can formally request that Rosetta give you the object files. If they decline then just email ( license-violation@gnu.org ) and report the lack of Rosetta 4.07 64-bit linkable object files. and that it is failing on glbc 2.27. I saw that someone earlier had requested the object files, so Rosetta is now in violation of the FSF they agreed to by static linking glibc. |
Jim1348 Send message Joined: 19 Jan 06 Posts: 881 Credit: 52,257,545 RAC: 0 |
Thanks, but after unsuccessfully trying to boot into GRUB (maybe a USB problem), I changed to a PS/2 keyboard and booted into Partition Magic. Then, I used their file tool to delete /etc/locale.conf. Now I am back to normal and will proceed accordingly. It looks like it should work. You would think that Rosetta should be able to figure it out. Thanks. EDIT: After making those changes to /etc/default/local, I am again not able to open a terminal. I guess that is what you were saying, but I misinterpreted it. So I will just remove those lines again and wait. Best of luck. (I think they may be putting their development efforts into Windows. I have had better luck with that recently.) |
rjs5 Send message Joined: 22 Nov 10 Posts: 273 Credit: 22,487,487 RAC: 2,163 ![]() |
Sorry. You fell into all the traps that I did. There is another TERMINAL program named "Konsole". You can install it It seems that "terminal" and Rosetta 4.07 64-bit require conflicting locale settings. "konsole" does not seem to depend on locale since I was able to set the locale variables and konsole ran both ways. For a long time, Rosetta built its x86 version ONLY using SSE because they wanted to keep the old, old, old old systems working. It is rather humorous that they are now (and have been for weeks) ignoring the plight of everyone running the NEW Linux distributions on leading edge machines. The "fix" could be as simple as disabling the 64-bit version of Rosetta 4.07 until fixed. I understood and had no problems with any of their previous positions. The project silence now is very disappointing. |
Juha Send message Joined: 28 Mar 16 Posts: 13 Credit: 705,034 RAC: 0 |
/etc/locale.conf Instead of changing language options globally I would suggest limiting changes to only what is needed, in this case BOINC client. For those using repository BOINC package and systemd distro, you can edit boinc-client.service file or add an override to the service. The override would look something like this: [Service] Environment=LC_ALL=C LC_ALL overrides all the other language settings. Put the override file in /etc/systemd/system/boinc-client.service.d/locale.override.conf and restart the client with sudo systemctl restart boinc-client. If changing the distro supplied service file then find boinc-client.service and add the Environment line in Service section. Changes to the file will be overwritten any time the package is updated. For those not using distro package or not using systemd make similar change to whatever startup script you use for the client. |
[DPC]Remmus Send message Joined: 9 Nov 05 Posts: 6 Credit: 2,466,696 RAC: 0 |
Thanks, I will try this if the system entry by Juha dows not work! |
rjs5 Send message Joined: 22 Nov 10 Posts: 273 Credit: 22,487,487 RAC: 2,163 ![]() |
/etc/locale.conf This works for me on Ubuntu 18.04 vbox. "terminal" opens and Boinc 4.07 64-bit executes for several minutes. I added the above to the "/lib/systemd/system/boinc-client.service" file under the [Service] section. Should I make a new "[pre][Service]" section instead? |
[DPC]Remmus Send message Joined: 9 Nov 05 Posts: 6 Credit: 2,466,696 RAC: 0 |
I needed to create the directory boinc-client.service.d and afterwards create the file locale.override.conf with the given entry for the service. [Service] Environment=LC_ALL=C I needed to refresh the systemd services. And now it is working for 4.07 jobs!!!! |
Juha Send message Joined: 28 Mar 16 Posts: 13 Credit: 705,034 RAC: 0 |
I added the above to the "/lib/systemd/system/boinc-client.service" file under the [Service] section. That's ok. Should I make a new "[pre][Service]" section instead? I don't really know what systemd says if you have more than one section with the same name in the same file. |
rjs5 Send message Joined: 22 Nov 10 Posts: 273 Credit: 22,487,487 RAC: 2,163 ![]() |
I added the above to the "/lib/systemd/system/boinc-client.service" file under the [Service] section. I would totally defer to those who better know the Linux internals. Now that "[DPC]Remmus" has his system working, the Rosetta crunchers can at least make the choice to repair the Rosetta 4.07 x86_64 bug ... and have a model. That was my goal. It would have been easier for Rosetta to properly test 4.07 first before releasing OR to respond to problems reported here ... OR even simply stop sending out the 4.07 64-bit version WUs (would probably take 60 seconds). Thanks for your help. |
![]() Send message Joined: 17 Apr 18 Posts: 4 Credit: 2,664,458 RAC: 0 |
Thanks,some time it runs very good,and after a while the error disapear,so i Guess all just ignor. God bless the good work. Mvh.akkin4. |
![]() Send message Joined: 23 Apr 18 Posts: 2 Credit: 38,884 RAC: 0 |
Looks like I'm not first to post a computation error that points to the "chi angle", but I think no explanation or solution has been discussed yet. Or is that not the source of the problem? <core_client_version>7.8.6</core_client_version> |
![]() Send message Joined: 1 Dec 05 Posts: 1958 Credit: 9,099,368 RAC: 978 ![]() |
1001952207 ERROR: Unable to open weights/patch file. None of (./)beta_nov16_cart.wts or (./)beta_nov16_cart.wts.wts or minirosetta_databasescoring/weights/beta_nov16_cart.wts or minirosetta_databasescoring/weights/beta_nov16_cart.wts.wts exist |
Message boards :
Number crunching :
Rosetta 4.0+
©2024 University of Washington
https://www.bakerlab.org