Recently there was an update rolled out to glibc-2.25.
This update will reproducible destroy my machine when installed. It causes all kinds of programs including systemd to dump core and then will prevent booting because a lot of service won’t come up, including login service.
I tracked the problem down to glibc-2.25.i686 which when installed also causes zypper to not work anymore…only chance to recover was an earlier image of system partition.
Then i found out, that there are two glibc-2.25 versions available on the tumbleweed repository:
glibc-2.25-1.1.i586
and
glibc-2.25-1.1.i686
The i686 version crashes my machine, but the i586 version is working.
Because the earlier installed glibc was glibc-2.24-1.1.i686, it defaulted to use the i686 type of the new version.
My processor is an Atom N270. To my knowledge this should be i686 compatible.
So the question is, what is wrong with the glibc-2.25-1.1.i686 and why is the i586 version working?
Similar problems here, on both Atom-N270 and Atom-330. Other processors don’t seem to be affected.
It took some trickery, but I managed to run GDB on a core dump:
Program terminated with signal SIGSEGV, Segmentation fault. #0 __memchr_sse2 () at …/sysdeps/i386/i686/multiarch/memchr-sse2.S:249
249 …/sysdeps/i386/i686/multiarch/memchr-sse2.S: No such file or directory.
(Sorry for late reply – Silly me, I thought “subscribe to thread” would automatically send me an email alert!)
I am pretty sure this is related to glibc, probably some configure option or compiler flag. The ArchLinux glibc-2.25-1-i686 package works flawlessly on Atom. I actually substituted their glibc for the tumbleweed version and it worked fine. Your suggestion of using the i586 tumbleweed package is of course a much better solution, now that I know a separate i586 package exists. Not sure what the best solution is from an installation and/or packaging standpoint, either fix the i686 package to run on Atom, or detect the problem at installation time and install the i586 version for Atom processors. I have tried the “pae” kernel, the “default” kernel, and even the Archlinux kernel image and none of them has any effect on the problem so I think it’s safe to say it’s not a kernel issue.