Results 1 to 5 of 5

Thread: TW 20180305 --> 20180324 update *appears* to continue the zypper segfault problem (from glibc)

  1. #1
    Join Date
    Feb 2017
    Location
    Montana, USA & Vermont, USA
    Posts
    134

    Default TW 20180305 --> 20180324 update *appears* to continue the zypper segfault problem (from glibc)

    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:
    • glibc-2.27-482.1.aarch64.rpm
    • glibc-devel-2.27-482.1.aarch64.rpm
    • glibc-extra-2.27-482.1.aarch64.rpm
    • glibc-locale-2.27-482.1.aarch64.rpm

    and the command to reinstall them was
    Code:
    rpm -iv --force *.rpm

  2. #2
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    32,316
    Blog Entries
    15

    Default Re: TW 20180305 --> 20180324 update *appears* to continue the zypper segfault problem (from glibc)

    Quote Originally Posted by hdtodd View Post
    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:
    • glibc-2.27-482.1.aarch64.rpm
    • glibc-devel-2.27-482.1.aarch64.rpm
    • glibc-extra-2.27-482.1.aarch64.rpm
    • glibc-locale-2.27-482.1.aarch64.rpm

    and the command to reinstall them was
    Code:
    rpm -iv --force *.rpm
    Hi
    Did you not add a lock to the packages?
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  3. #3
    Join Date
    Feb 2017
    Location
    Montana, USA & Vermont, USA
    Posts
    134

    Default Re: TW 20180305 --> 20180324 update *appears* to continue the zypper segfault problem (from glibc)

    Quote Originally Posted by malcolmlewis View Post
    Hi
    Did you not add a lock to the packages?
    Hi, Malcolm,

    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?

    David

  4. #4
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    32,316
    Blog Entries
    15

    Default Re: TW 20180305 --> 20180324 update *appears* to continue the zypper segfault problem (from glibc)

    Quote Originally Posted by hdtodd View Post
    Hi, Malcolm,

    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?

    David
    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...?
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  5. #5
    Join Date
    Feb 2017
    Location
    Montana, USA & Vermont, USA
    Posts
    134

    Default Re: TW 20180305 --> 20180324 update *appears* to continue the zypper segfault problem (from glibc)

    Quote Originally Posted by malcolmlewis View Post
    The bug report is still open/active, seems only related to ipv4, is the IRC user using ipv6 perhaps...?
    Malcolm,

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •