I seem to have gotten stuck with a zypper problem that I can’t resolve: looking for suggestions.
I noted earlier that zypper dup occasionally segfaults but that I was generally able to get it to do the updates. At this point, I’m
at 4.15.7-1-default and dup says there’s nothing to do (as does zypper up).
But if I try to install something, as in zypper in git, it begins the first download and immediately segfaults. I see that my process list is littered with entries like:
2217 ? Ss 0:00 gpg-agent --homedir /var/tmp/zypp.z3CcYQ/zypp-trusted-krEAzZII --use-standard-socket --daemon
So I’m assuming that there’s a problem with GPG in zypper. I disable GPG checking for the repository (only one
Still get segfaults – and new dead gpg-agents!!! – if I try to install anything again.
At this point, I’m not even convinced that zypper is really doing its zypper dup check correctly, but I surely can’t get anything to install.
So:
Is anyone else seeing this problem?
Is there a way of working around this to install specific software systems and/or to check for distribution updates?
If the problem is in zypper and friends, how might I go about re-downloading and reinstalling them? zypper install zypper gets me a segfault every time.
Thanks for any advice you can give. For now … back to Leap 42.3 (which has its own problems on RPi-3B).
Yes, I remembered that you’d had the problem, too, but it seemed different in that mine worked – most of the time – with segfaults only about 1/2 the time on zypper dup. zypper dup still works (or purports to), but zypper in fails reliably.
The new piece of information (new for me, anyway) is that it seems to be GPG-related. But after disabling GPG verification, zypper still fails (and gpg-agent is still invoked), so I’m not sure my conclusion is correct.
And I think this is resolvable. It’s not an issue buried deep in the kernel. I’m just not sure where to look next, and if I figured out what’s causing it, I’m not sure how I’d download and install the corrected package.
And I really like the TW aarch64 implementation for RPi. The Leap distro works but has other problems (video, wifi) that impact performance and functionality. The current TW distro just works … mostly.
So … the only other person using TW on RPi-3 has given up using it?!! That can’t be a good sign!
For others who might follow this, the files were:
glibc-2.27-482.1.aarch64.rpm glibc-extra-2.27-482.1.aarch64.rpm
glibc-devel-2.27-482.1.aarch64.rpm glibc-locale-2.27-482.1.aarch64.rpm
Installing them with rpm -i failed because of version conflict. Installing with rpm -i --force *.rpm succeeded.
And without rebooting, zypper in git succeeded just as it should have!
Subsequent zypper up finds nothing to update. zypper dup finds 4 problems – the four glibc-2.27-482.1.aarch64 packages that were just installed are obsolete. (I didn’t let it delete them!)
Thanks, again, Malcolm! That’s not a place I would have looked for a solution!
No, not resolvable here and anybody (especially Malcom L) will be happy if there is not so much problems popping up in the forum with aarch64, as I’m not going to use opensuse on raspi any longer.
If one installs these packages, do they get automatically overwritten when a proper fix is released?
(Note I have already added “195.135.221.134 download.opensuse.org” to “/etc/hosts” so zypper does work, so if you know a zypper based download means that would be totally fine)
Jeroen,
I don’t know the answer to (1) [Malcolm might], but regarding (2): Having installed these 4 packages on TW aarch64 4.15.7-1-default on RPi-3B,
A subsequent zypper up works without reference to the glibc packages but finds nothing to update
A subsequent zypper dup gives a warning:
Computing distribution upgrade...
4 Problems:
Problem: problem with installed package glibc-2.27-482.1.aarch64
Problem: problem with installed package glibc-devel-2.27-482.1.aarch64
Problem: problem with installed package glibc-extra-2.27-482.1.aarch64
Problem: problem with installed package glibc-locale-2.27-482.1.aarch64
Problem: problem with installed package glibc-2.27-482.1.aarch64
Solution 1: deinstallation of glibc-2.27-482.1.aarch64
Solution 2: keep obsolete glibc-2.27-482.1.aarch64
Choose from above solutions by number or skip, retry or cancel [1/2/s/r/c] (c):
from which I select (c) - cancel. zypper apparently sees those 2.27.482 versions of glibc as obsolete and wants to replace them with the current distribution packages – the ones that have the bug that caused the problem in the first place.
I think I could lock those 2.27.482 packages, but I think the better approach is to continue to do occasional zypper dup's and cancel until I see one that includes glibc along with a number of other packages in the update. I’ll assume that distribution update includes a fix to the glibc package and let it be installed. [Other advice welcomed!]
Thanks. Back to question 1: Are there any other means to get these packages (I think a lot more people bump into it; some contacted me on my blog post https://wiert.me/2018/03/15/tumblewe…me-resolution/ )
This will create a directory called binaries, in here are the four
files required. Since by default OBS does not publish packages that
are branched.
–
Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE Leap 42.3|GNOME 3.20.2|4.4.120-45-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!
Sorry for not getting back on the forum earlier on this, but when working on a reply for more than an hour, the forum bit me hard two times in similar ways it pestered me in the past resulting in message loss.
What I did do is create public git based repository with:
binaries of the packages (various versions obtained via OSC on a secondary system)
instructions how to apply these packages
instructions on how to get more recent binaries (including osc install instructions, and getting osc credentials)
