I did a zypper dup tonight on my RPi-3B running TW that went from 20180305 → 20180324 (installing 4.15.7-1 → 4.15.10-1). The update installed some 973 packages. I allowed it to “update” glibc 2.27-482.1 → 2.27-2.1. On the IRC forum, Nebadon responded that he’d done the same and that zypper was working fine, and he was running with glibc 2.27-2.1.
But after I rebooted and tried to do a zypper in gcc8 ..., zypper segfaulted as it had last week. I had retained the glibc 2.27-482 .rpm files, so I reinstalled them (over the “newer” versions, using rpm -iu --force), and the zypper command worked without a problem. No rebooting or other activity between zypper in attempts other than the glibc install.
So there’s an unaccounted-for discrepancy between our experiences, but for those considering a zypper dup on RPi-3B, aarch64, Tumbleweed, you might want to cache copies of the glibc-2.27-482*.rpm files in advance in case zypper segfaults after the update. In my case, the files are:
Yes, I had added the lock, as you suggested, and I had no problems with zypper with the “older” version of glibc. But when nebadon reported that his update had worked fine, that it had installed glibc 2.27-2.1, and that zypper worked with no problems after the update, I unlocked glibc packages and let it update all 973 packages.
But I had kept aside the glibc 2.27-482.1 RPMs you sent me, so when zypper segfaulted, I just went back and reinstalled them and zypper immediately started working (no reboot or anything).
So I can’t explain why nebadon’s update (to same TW) and glibc install (to same version) left him with a working zypper and mine didn’t. But the culprit is clearly glibc.
Hence my caution to those who might try the update and have zypper segfault afterward: keep those “older” RPM’s handy!
I don’t understand the glibc version numbers. I’d have thought that 2.27-482.1 would be a newer version than 2.27-2.1 but zypper clearly doesn’t think so. And 2.27-2.1 causes zypper to fail and 2.27-482.1 doesn’t, hence the need to lock it. Is there a brief explanation about glibc version numbers?
Hi
They are revision numbers, but from a different repo… since they are also installed manually (@system packages/orphans) a dup will override and install from the main repository…
If you created say a local plain rpm repo and it was active they would not switch if you did a zypper dup --from <this local repo> even if different revision numbers.
The bug report is still open/active, seems only related to ipv4, is the IRC user using ipv6 perhaps…?
No, nebadon is using IPv4 too. But I’m not … I’ve disabled IPv6 entirely. So that may still be a factor. Good catch, and might be the reason more people aren’t seeing the problem.
