I moved a mini-ITX motherboard from a fullsize ATX case into a mini-ITX case.  This has a A10-7860k APU.  It was  planned to run with a R7-250, but that seemed to require Crimson, which was a nightmare.  The R7-250 was replaced with a HD-6450, which ran under Catalyst (but was proprietary).  On the move, I put a RX-550 into the machine.  The HDMI output is plugged into the motherboard, and so makes use of the GPU part of the A10.  The RX-550 is left all alone to do crunching.  Perhaps in the future it will be possible to get the GPU side of the A10 to number crunch as well.

Initial E@H estimated time was 1:11, first job ran in 34 minutes.

I am only allowing 2 (of 4) CPU cores to run BOINC, leaving 2 free for other stuff.  Perhaps a person can throw another CPU at things?

The computer with the 8CPU processor, I was running a perldb job in emacs, and generating a LOT of output, and emacs started running out of memory (8GB RAM and 16GB swap).  I got "Computation Error" on a whole bunch of BOINC jobs.  :-)

I am not too overjoyed at having purchased hardware to find it deprecated, or about to be deprecated.  Some of this I may be mis-interpreting.

Advances in the Xorg server have made fglrx (Catalyst or Crimson) a non-starter for anyone with an up to date OS.  Mesa/Clover/libclc/Clang is providing a OpenCL-1.1 environment, and work continues.  It appears that the choke point in this is libclc.  Apparently nobody has tried (published?) an attempt to run OpenCL-1.2 tests against this combination.  What is there now, is 1.1 with extensions, and most of what is needed for 1.2 seems to be done.  But there doesn't seem to be any urgency in getting to this 1.2 state.  I'm not writing code, so it is easy for me to write.

AMD helped with the open source amdgpu module, and produces a proprietary amdgpu-pro driver.  Does this driver following the same philosophy as fglrx?  Is it just as enjoyable to work with?  In any event,  I gather AMDs answer to Clover is ROCm.  While amdgpu is supposed to support all GCN cards/GPUs, ROCm doesn't seem to support all of GCN.  So, if you follow the AMD hardware side and go to ROCm for OpenCL support, you may find that your older hardware will not play any more.  For instance, my A10-7860k APU and R7-250 GPU would be too old.

---

In any event, Einstein CPU and GPU jobs are working on the RX-460 using MESA (no fglrx).  SETI sent some GPU jobs, but as near as I can tell it is only compiling them for Oland (and fglrx).  So I get a build failure, and it pauses for a while, and then another build failure.  Oland is what was in this computer before (the R7-250).  I have looked to see if there is some old data file doing this, but I am drawing a blank.  The CPU jobs are coming through fine.

I have stopped downloading new tasks on this machine to empty the queue (except for these build failures, which will never run I guess), as I am ready to copy my old /home to a new disk, and BOINC data actually sits in /home.

Which may give me time to see what this HD5450 can do again.

Happy Thanksgiving!

They don't seem to be segfaulting in the first few seconds, but who knows if they calculate anything useful at this point?

It is looking for a OpenCL kernel file, which is not present.  Is this file supposed to be part of the download from Seti@Home, or is it supposed to be calculated locally?

This is being manually typed (not cut and paste), so there could be errors

AstroPulse_Kernels_ r2751.cl_ bin_V7_TWIN_FFA_1721

The only OpenCL things I am seeing for GPU, are Oland files.

There seems to be a problem with the Einstein@Home package, every BRP job segfaults as well.  Since I have vsyscall=emulate already set, there has to be some other explanation for these early segfaults.

It seems that at about the 4.8 kernel, the vsyscall was set to "none".  If you look in your logs, you should see a bunch of lines where BOINC jobs are getting squashed because of this.  These are the system logs, not the files in the BOINC directories.

On booting in grub, you can edit a command line and add
vsyscall=emulate
to the linux (kernel boot) line.

If this works, you can change the grub default linux boot line in /etc/default/grub and add
vsyscall=emulate
to that parameter, and then update-grub.

Maybe with something working, I will see why amdgpu (not amdgpu-pro) and mesa are not getting together to run GPU jobs.  Or maybe they will start by magic as well.  :-)

There are two executables in that directory now, one is a statically linked 64 bit file (so ldd can't help on that).  The other is a dynamically linked 32 bit program.  Two of the libraries are not found.  I have tried downloading the packages for LibGL.so.1 and libX11.so.6 for i386, but there is a conflict at the moment for ascii/ceres that involves my choice of using LLVM-5.

Working on the farm, there are always things to keep me occupied.  I try to only work on computer problems when I don't want to be outside.  Since we've had a drought much of the summer, there have been few rainy days.

The computer with the dual core AMD64 and the HD5450 is running World Community Grid CPU jobs.  At the moment, there is 1 job running, 2 to report, and 4 tasks with computation error (I wonder what happened there?).  I will have to look into the GPU issues a little later.  I may put a RX550 in this, but the power supply is quite small.

---

I upgraded another computer from B24 dual core to 8 core FX-8320e, and put back the RX-460 I meant to run there over the last few days.  I installed Devuan/Jessie to a 40 GB partition on SSD from DVD (the install from the Jessie CD wouldn't work, something about network access).  A fairly minimal install.  I then upgraded that to Ascii/Ceres and a 4.12 kernel.  On the SSD I had the root, /boot, /usr and /var partitions of Debian/Jessie.  I removed almost everything that was OS (so mostly /etc left), and made a tarball of that.  All of those partitions were ext4.  I then redid the root partition as btrfs, and unrolled the tarball on the root partition.  I then pruned what was below /boot, /usr and /var.  After that, I mounted the 3 "Debian" partitions at the appropriate places, and copied (with archive switch set) all of the Devuan/Ascii-Ceres to this set of 4 partitions.  I adjusted the few files in /etc that needed adjusting.  Chrooting into the root partition and running update-grub was not sufficient to allow this to boot, I had to dpkg-reconfigure grub.  But it booted then.

I had partitions for swap, /tmp, /var/log and /usr/local on another disk, which were relisted in fstab.  And this "homeless" system booted fine.  Even seamonkey in /usr/local ran.

I then loaded in clang-5.0, llvm-5.0, mesa, opencl and boinc stuff.

Boincmgr ran fine the first time.  I removed the hold on new tasks for setiathome and einstein.  Nothing was downloading for quite a while.  I looked in the logs a bit, and I had been dumb.  The UID and GID for boinc had changed, so it couldn't write things.  Fix permissions, and jobs started appearing.  All of them failing (GPU and CPU jobs).

I started today by setting dpkg to allow for i386 libraries if it needs to, but haven't installed any yet.  I then entered the setiathome project directory with emacs in dired mode and shell in the other half window.  And I started running 'file' against files found there, to find out what they are (and to run ldd against the executables I find).

There is an ELF32 file there, with Oland in the name (so some kind of GPU file) of unknown architecture that is reported to have a corrupt program header size (according to file).  ldd says it is not a dynamic executable.  And another similar file of same properties.

And there are four different 8.22 ati OpenCL files, which are all x64 ELF executables with ldd reporting that all of them have the libraries they need to run.

I don't seem to find any executable files meant to run on the CPU (only).

I haven't yet looked through the einstein directory, to see if there is anything to find out there.  But BOINC seems to clean too much up after problems, so I probably need to visit the two projects in question to see if there are stdout or stderr outputs that have more information on the problems.

I hate for your troubles. But in the last few months, I've been thru EXACTLY (mostly) what you're going thru, and I'd like to try to help. What makes my experience 'mostly' is that I had compile problems on 3 computers, and I had AMD Catalyst problems on a 4th computer. Hopefully, you can combine my lessons learned on one computer and find joy. I'm gonna try to take your posts one at a time, top to bottom.

Letting the tasks finish and upload and get no new work was the right thing...kudos. That should have been enough, and I know the projects appreciated it.

Your HD 5450 is barely in the usable range of compatible GPUs. Might consider an upgrade soon. In my BOINCsperience, NVIDIA is much easier to work with. BTW, I love the term BOINC-fu. Maybe your room needs some BOINC-shui.

MESA is designed to work only with non-proprietary drivers, in your case, Radeon and AmdGpu (not Pro) in the repos. xorg-radeon is AMD's non-proprietary driver for its older GPUs, xorg-amdgpu is AMD's non-proprietary driver for its newer GPUs. I don't know where the dividing line between old and new is.

I have seen boinc-client show up in my home folder before. I ignored it and just kept going. BTW, not in Devuan, in MX.

Using the Distro's Version, rather than compiling, is the best way to go if you can. I think your upgrade to an upgrade to an upgrade may have left some things not right, systemically. Multiple unsuccessful re-installs of an Application is a sign of this.

I hate that noone replied to you for so long. I saw your post 2 weeks ago, but was not in the right mind to reply. Today, I am.

I love to move and upgrade hardware. Hope you had fun.

The boinc-client starts on boot-up by default. Users must suspend/resume projects/tasks manually to their likin'.

Glad you found that 'compile client only' flag. I had to visit 3 or so different Web Pages to get all the instructions I needed. Then I still had to wait for the compiler to tell me something was missing.

I extracted and compiled in my Home Folder. I think this made write permissions less of a problem.

It sounds to me like you're trying to mix files from the Distro's BOINC installation with the Compiled BOINC installation. This is a booboo. They are not compatible. The Distro Version uses Symbolic Links throughout the tree. The Compiled Version is completely self-contained in its own folder. It compiles completely and solely in the same folder to which it was extracted. It places nothing anywhere else in the tree, not in /etc, not in /var. The Distro Version's symbolic links will interact with any files anywhere in the tree that have 'boinc' in their name, including those in the Compiled Version's folder. You must choose one version or the other, and completely remove all files of the one you don't choose (backup boinc-client first). Catfish is your friend.

Your last post indicates that you chose the Compiled Version and it's working, except for GPU. Congratulations. Still uninstall the Distro Version and remove all rogue files. Apt-get autoremove, GtkOrphan, and BleachBit are good friends too.

OPINION: After all the things you did, undid, and rearranged, a fresh install of DevJessie upgraded to Ascii may be worth considering. If you wish, see my reply to leloft for my take on that.

Now you're back to the original problem in your original post, getting your GPUs to run OpenCL tasks.

I don't think you need any 32-bit libs, other than the deps pulled in by BOINC and the Video/OpenCL Drivers.

MY TAKE: Uninstall/remove all things proprietary AMD/Catalyst/fglrx and use the xorg-radeon driver only. If it won't uninstall, claiming that some files have been changed, just remove /etc/X11/xorg.conf and /etc/modprobe.d/blacklist-fglrx. A reboot should take you back to the xorg-radeon driver.

You're experienced with MESA so install whatever you like from it's collection. I installed: glx-provider-mesa, opencl, va, utils & extra, vdpau, and vulkan. There was plenty of MESA stuff already installed by the OS install, but these pkgs looked necessary/handy to me, and I don't think too much MESA will do any harm.

FAIR: This is my first attempt at MESA, it having been made necessary by smelly AMD OpenCL support in Stretch/Ascii/xUbuntu16.04/DevJessie. It was fine in DebJessie. So, my skillset in this area is highly undeveloped.

IMPORTANT NOTE!!!: As well as my AMD GPUs run BOINC tasks now, this Radeon/MESA combination is not powerful enough to run tasks and desktop graphics/video well simultaneously. Some 'points & clicks' take a few seconds to respond. Since the computer in question is our Home Theater PC, and Graphics/Video are primary, my solution was to 'exclude_gpu_0' in cc_config.xml, as that is the GPU that runs the TV/Monitor. The other two AMD GPUs run tasks continuously without consequence.

These are my thoughts, hope they help.
Post your progress, regardless of my influence. I'm interested.

Gary

I have put 3 machines thru the 'Jessie to Ascii' upgrade. On all, I used the same 'auto' mirrors, as you did. However, I'm not so committed to 'free' software that I use only the 'main' section of each repo. I enabled the 'contrib' and 'non-free' sections of each repo as well. I find that they contain many packages/dependencies that I want, and sometimes need, especially for not-necessarily-linux packages like BOINC. I honestly don't know if this helped, but I haven't experienced any of the things that you describe. They all upgraded to the 4.9 kernel and I installed the 7.6 BOINC Client and Manager. All cores of all CPU Cores are running tasks, as well as all GPUs. I can't speak to 'boinccmd' as I've never used it.

NOTE: If a 'contrib' or 'non-free' section of a repo can't be found, Apt/Synaptic will tell you and you can remove that section from the repo line.

You can upgrade the 3.16 kernel to 4.9 manually, and I recommend that you do. Just be sure to reboot to the 4.9 kernel before you uninstall the 3.16.

As for the lock-out, if you told the upgrade to 'use the package maintainer's version' of any config files rather than keep the old one, that could have changed your login settings, especially with lightdm.conf or slim.conf. 'passwd' in a terminal will get you going again.
Come to think of it, this could affect 'boinccmd' as well. It may have messed with owners, groups, and/or permissions.

I can't speak much to the firewall or iptables, little skillset there. But my 'opinion' is that they aren't issues.

NOTE2: During the upgrade, I left the 'Jessie' repos enabled, complete with 'contrib' and 'non-free' sections, and didn't disable them until the upgrade was complete and reboot successful. Whether or not this helped is unknown. I know Apt/Synaptic pulls in the newest version of a package, but I thought that if Ascii didn't have something, maybe the upgrade could pull a suitable substitute from 'Jessie' and be OK. I also made sure that Jessie (again, with all sections enabled) was completely up to date before enabling any of the Ascii Repos.

These are my thoughts, hope they help.
Post your progress, regardless of my input. I'm interested.

Gary

I deleted libcurl4-nss-dev and the binary library associated with it, and installed libcurl4-gnutls-dev and recompiled BOINC client from the Berkeley source.  Of course, make install overwrites a couple of things.  :-)  But, it connected to SETI@Home and downloaded some tasks and it is working.  Sort of, it doesn't seem to be doing any GPU work.  I think there are a bunch of 32bit libraries a person has to have installed, in order to do GPU work on an amd64.  But I'll work on that later.  I am trying to get that working via Mesa3d/Clover, instead of that deprecated binary junk from amd that was not really supported at the best of times from what I can tell.

Problem still exists.

Libraries cached in memory/swap, and I need a reboot to "fix" things?

I've tried connecting to Seti@Home, World Community Grid and Einstein and there is no connection.  I don't seem to have any firewall blocking things, but I suppose looking at what iptables is doing might be useful.

A Boinc or Seti forum suggested setting http_debug, http:xfer_debug and file_xfer_debug in cc_config.  I am manually typing in (edited) snippets of error messages, so there could be typos.

TCP_NODELAY set
Connected to Boinc port 443
Initialising NSS with certpath:none
WARNING: failed to load NSS PEM library.  Using OpenSSL PEM certificates will not work.
HTTP error: Problem with the SSL CA cert (path? access rights?)
...
Next it tries the SetiAtHome server at Berkeley, and this seems to handshake and everything.
Downloads some stuff.
Tries the same to SetiAtHome as Boinc, and we see the NSS PEM thing again.
Then it tries https to google.com, and same NSS PEM thing and gives up.

/var/lib/boinc-client/ca-bundle.crt -> /etc/ssl/certs/ca-certificates.crt

The ca-certificates.crt file is 261407 bytes, 644 permissions root.root ownership.

Not sure what else needed.