Page 4 of 4 FirstFirst ... 234
Results 31 to 38 of 38

Thread: Upgrade 15.2 to 15.3 leads to libhandle.so.1.0.3 conflict

  1. #31

    Default Re: Upgrade 15.2 to 15.3 leads to libhandle.so.1.0.3 conflict

    Hi,
    thank you again for your input.

    This were my steps:

    Code:
    sed -i 's/$releasever\|15.2/15.3/' /etc/zypp/repos.d/*.repo
    sed -i '/priority\=/d' /etc/zypp/repos.d/*.repo
    sed -i 's/keeppackages\=0/keeppackages\=1/' /etc/zypp/repos.d/*.repo
    
    
    zypper ar -fgk https://mirrorcache-eu.opensuse.org/update/leap/15.3/sle/ repo-sle-update
    zypper ar -fgk https://mirrorcache-eu.opensuse.org/update/leap/15.3/backports/ repo-backports-update
    zypper mr -d 3
    
    
    zypper ref
    zypper al texlive*
    
    
    zypper al kerne*
    
    
    rpm -e --nodeps libhandle1
    
    
    
    
    rpm -qa |grep -i xfs
      xfsinfo-1.0.5-lp152.3.5.x86_64
      xfsdump-3.1.6-lp152.3.6.x86_64
      xfsprogs-4.15.0-lp152.12.6.1.x86_64
      xfs-1.2.0-lp152.4.6.x86_64
    
    
    rpm -e --nodeps xfsinfo-1.0.5-lp152.3.5.x86_64 xfsdump-3.1.6-lp152.3.6.x86_64 xfsprogs-4.15.0-lp152.12.6.1.x86_64 xfs-1.2.0-lp152.4.6.x86_64
    xfs.service is not a native service, redirecting to systemd-sysv-install.
    Executing: /usr/lib/systemd/systemd-sysv-install disable xfs
    
    
    
    
    zypper install --force curl libcurl4 zypper zypper-log zypper-lifecycle-plugin zypper-needs-restarting libzypp libzypp-plugin-appdata snapper-zypp-plugin
    
    zypper dup -d
    
    
    zypper dup -l --allow-vendor-change
    Locking the kernel leads to the following requirement to solve: https://susepaste.org/373f109c
    I don't know which option to choose from, so I took option 1.

    Code:
    Solution 1: Following actions will be done:
      remove lock to allow installation of kernel-debug-5.3.18-59.30.1.x86_64[repo-sle-update]
      install kernel-debug-5.3.18-59.30.1.x86_64 although it has been retracted
    This is the complete log: https://susepaste.org/3ec0244e

    The result is unfortunately the same that the system seems to be crashing on this step:
    Code:
    ]
    (2177/2803) Installing: kmod-29-4.15.1.x86_64 .........................................................................................................[done]
    warning: /etc/systemd/journald.conf created as /etc/systemd/journald.conf.rpmnew
    warning: /etc/systemd/system.conf created as /etc/systemd/system.conf.rpmnew
    Creating group systemd-resolve with gid 473.
    Creating user systemd-resolve (systemd Resolver) with uid 473 and gid 473.
    I was connected via web console to this VM and it instantly rebooted and then showed the following stack trace on the first boot: https://susepaste.org/aaaae22c

    Thus I can't recover from that. During installation I was checking on disk space which showed around 50% used from 64 GB, thus it was around 30 GB free space.

  2. #32
    Join Date
    Sep 2012
    Posts
    7,844

    Default Re: Upgrade 15.2 to 15.3 leads to libhandle.so.1.0.3 conflict

    Quote Originally Posted by derDaywalker View Post
    the following stack trace on the first boot
    It is always the same - system fails to run init (the very first process started during boot) which is sytsemd. If I had access to this system I would try to stop in initrd before it attempts to switch to the real filesystem (add rd.break=pre-pivot to kernel command line), chroot into real root and played around. Tried to start systemd manually - this could result in more meaningful error message etc.

  3. #33
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    3,954
    Blog Entries
    1

    Default Re: Upgrade 15.2 to 15.3 leads to libhandle.so.1.0.3 conflict

    Quote Originally Posted by derDaywalker View Post
    Locking the kernel leads to the following requirement to solve: https://susepaste.org/373f109c
    I don't know which option to choose from, so I took option 1.
    Wrong one. It will auto-correct when kernel installation occurs if you choose break suse-module-tools.

    Code:
    Solution 1: Following actions will be done:
      remove lock to allow installation of kernel-debug-5.3.18-59.30.1.x86_64[repo-sle-update]
      install kernel-debug-5.3.18-59.30.1.x86_64 although it has been retracted
    This is the complete log: https://susepaste.org/3ec0244e
    Choosing 1 hasn't happened here, so I can't opine. I rarely allow a kernel to install until all the new pieces are in place, and certainly would not at this point, if I ever was at this point.

    The result is unfortunately the same that the system seems to be crashing on this step:
    Code:
    (2177/2803) Installing: kmod-29-4.15.1.x86_64 .........................................................................................................[done]
    warning: /etc/systemd/journald.conf created as /etc/systemd/journald.conf.rpmnew
    warning: /etc/systemd/system.conf created as /etc/systemd/system.conf.rpmnew
    Creating group systemd-resolve with gid 473.
    Creating user systemd-resolve (systemd Resolver) with uid 473 and gid 473.
    IMO, kmod successfully completed, and the installation of systemd at #2178 is a big problem. From the log:
    In cache kmod-29-4.15.1.x86_64.rpm (2166/2782)
    In cache systemd-246.16-150300.7.45.1.x86_64.rpm (2167/2782)
    Where you got
    Code:
    zypper install --force curl libcurl4 zypper zypper-log zypper-lifecycle-plugin zypper-needs-restarting libzypp libzypp-plugin-appdata snapper-zypp-plugin
    from I don't know, but it isn't what happens here. Systemd needs to be in sync with a certain set of other packages. In comment #2 I explained how to start. Maybe a bad improvisation of that caused you to leave systemd out. I follow up with zypper up, followed by zypper dup. Up prior to dup does multiple things I like, such as separating minor changes from potentially more serious changes. Up goes swiftly and cleanly, dup often not so much.
    Reg. Linux User 211409 *** multibooting since 1992
    Primary: 15.3, TW, 15.1 & 13.1 on Haswell @earthlink.net
    Secondary: eComStation (OS/2) &15.2 on i965P/Radeon
    Tertiary: Debian, Fedora, Mageia, more on Rocket Lake & older Intel, AMD, NVidia....

  4. #34

    Default Re: Upgrade 15.2 to 15.3 leads to libhandle.so.1.0.3 conflict

    Hi @all,

    sorry, wasn't available the last days.

    Quote Originally Posted by mrmazda View Post
    Wrong one. It will auto-correct when kernel installation occurs if you choose break suse-module-tools.

    Choosing 1 hasn't happened here, so I can't opine. I rarely allow a kernel to install until all the new pieces are in place, and certainly would not at this point, if I ever was at this point.
    What do you mean? I chose Option 1 as you can see on the log that in line 244 I typed a 1 for choosing Option 1 (https://susepaste.org/3ec0244e).


    Quote Originally Posted by mrmazda View Post
    IMO, kmod successfully completed, and the installation of systemd at #2178 is a big problem. From the log:

    Where you got
    Code:
    zypper install --force curl libcurl4 zypper zypper-log zypper-lifecycle-plugin zypper-needs-restarting libzypp libzypp-plugin-appdata snapper-zypp-plugin
    from I don't know, but it isn't what happens here. Systemd needs to be in sync with a certain set of other packages. In comment #2 I explained how to start. Maybe a bad improvisation of that caused you to leave systemd out.
    I got this zypper install line from Comment #25

    Quote Originally Posted by mrmazda View Post
    I follow up with zypper up, followed by zypper dup. Up prior to dup does multiple things I like, such as separating minor changes from potentially more serious changes. Up goes swiftly and cleanly, dup often not so much.
    Okay, so did now this:

    Code:
    sed -i 's/$releasever\|15.2/15.3/' /etc/zypp/repos.d/*.repo
    sed -i '/priority\=/d' /etc/zypp/repos.d/*.repo
    sed -i 's/keeppackages\=0/keeppackages\=1/' /etc/zypp/repos.d/*.repo
    
    zypper ar -fgk https://mirrorcache-eu.opensuse.org/update/leap/15.3/sle/ repo-sle-update
    zypper ar -fgk https://mirrorcache-eu.opensuse.org/update/leap/15.3/backports/ repo-backports-update
    zypper mr -d 3
    
    zypper ref
    
    zypper al texlive*
    zypper al kerne*
    
    rpm -e --nodeps libhandle1
    rpm -e --nodeps xfsinfo-1.0.5-lp152.3.5.x86_64 xfsdump-3.1.6-lp152.3.6.x86_64 xfsprogs-4.15.0-lp152.12.6.1.x86_64 xfs-1.2.0-lp152.4.6.x86_64
    
    zypper -v in --download-in-advance zypper libzypp libsolv-tools rpm libproxy1 libmodman1 curl openSUSE-release coreutils filesystem systemd udev aaa_base
    
    zypper up

    zypper in command asked:

    Code:
    Problem: the installed product:openSUSE-15.2-1.x86_64 requires 'product(openSUSE) = 15.2-1', but this requirement cannot be provided
      deleted providers: openSUSE-release-15.2-lp152.575.1.x86_64
     Solution 1: Following actions will be done:
      do not install product:Leap-15.3-2.x86_64
      do not install product:Leap-15.3-2.x86_64
     Solution 2: deinstallation of product:openSUSE-15.2-1.x86_64
     Solution 3: break product:openSUSE-15.2-1.x86_64 by ignoring some of its dependencies
    
    
    Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): 2
    I chose option 2 and on another try also option 3, but while issuing zypper up afterwards (without rebooting after zypper in) both options lead to conflicts again which I can't resolve (glibc-devel and plymouth-0.9.4 might be resolvable) because its about installing git (git-core vs. perl-Git) and the conflict happens between two repos (repo-sle-update vs. oss) as far as I understand this. Here is the full output (I typed no and abort the update): https://susepaste.org/9ffe2b24

  5. #35
    Join Date
    Mar 2011
    Location
    Sauerland
    Posts
    7,198

    Default AW: Upgrade 15.2 to 15.3 leads to libhandle.so.1.0.3 conflict

    File conflicts happen when two packages attempt to install files with the same name but different contents. If you continue, conflicting files will be replaced losing the previous content.
    Continue? [yes/no] (no):
    yes.....

    git-core-2.26.2-3.34.1 is a Leap 15.2 package.......

  6. #36

    Default Re: AW: Upgrade 15.2 to 15.3 leads to libhandle.so.1.0.3 conflict

    Quote Originally Posted by Sauerland View Post
    yes.....

    git-core-2.26.2-3.34.1 is a Leap 15.2 package.......
    Ah okay, I'll do it again.

    Meanwhile I tried another approach I just learned on last Thursday, doing a offline upgrade which seems to be advisable. There it can at least upgrade the system without rebooting during the upgrade process. But I get two errors while upgrading and after the first system boot a kernel panic. The offline upgrade was done just using the CD packages, so no online repos involved (during/after upgrade it asks if it should check online).

    1. error: https://susepaste.org/f7ebccf4
    So it complains about that there is no such directory or file. I just can ignore the issue because retry doesn't help.

    2. error: https://susepaste.org/04bff15d
    Here dracut complains about apparmor_2.13 and/or apparmor_2.10 not found and (hard to spot, but its the 6. line from the bottom) it complains about systemd version is not a number().

    I found nothing really on the internet but just found something suggesting running dracut with --debug etc. So I ran it manually and found the script responsible for printing systemd version is not a number. Its /usr/lib/dracut/modules.d/00systemd/module-setup.sh and there:

    Code:
    # called by dracut
    check() {
        [[ $mount_needs ]] && return 1
        if require_binaries $systemdutildir/systemd; then
            SYSTEMD_VERSION=$($systemdutildir/systemd --version | { read a b a; echo $b; })
            # Check if the systemd version is a valid number
            if ! [[ $SYSTEMD_VERSION =~ ^[0-9]+$ ]]; then
                dfatal "systemd version is not a number ($SYSTEMD_VERSION)"
                exit 1
            fi
            (( $SYSTEMD_VERSION >= 198 )) && return 0
           return 255
        fi
    I just did a dirty hack and inserted SYSTEMD_VERSION="234" into it (because the original system says with systemd --version that its version 234). Then I did the offline upgrade again, switched to the console while it was upgrading and applied the dirty hack, hoping that it works somehow. The complete dracut error disappears with this dirty hack such that I only get the 1. error. But the reboot afterwards ended up with a ugly kernel panic: https://susepaste.org/4e4ac0a7

  7. #37

    Default Re: Upgrade 15.2 to 15.3 leads to libhandle.so.1.0.3 conflict

    Okay, did it again (manually, not the offline approach) with typing yes to replace the files while doing zypper up. It went fine and even dracut didn't reproduced a error. This is the output of zypper up: https://susepaste.org/1498b272

    After that I proceeded with zypper dup. It asked me again about the lock of the kernel and this time I tried to choose the option to break suse-module-tools-15.3.15-3.17.1.x86_64 and multipath-tools-0.8.5+82+suse.746b76e-2.7.1.x86_64 but I every time I choose to break it, it just asked again. For the suse-module I tried option 115 at least 15 times, but every time it just asked again, thus in the end I chose 'Solution 2: keep obsolete suse-module-tools-15.2.16-lp152.5.12.1.x86_64'. For the multipath-tools it was the same, that it didn't accept to break it with solution 97, thus I chose "Solution 22: keep obsolete multipath-tools-0.8.2+166.7501a27-lp152.3.9.1.x86_64". After that it proceeded with the installation but again just rebooted the machine while upgrading:

    Code:
    ( 51/521) Installing: coreutils-8.32-150300.3.5.1.x86_64 ..............................................................................................................................................................................................................................................................[done]
    ( 52/521) Installing: libblogger2-2.26-150300.4.3.1.x86_64 ............................................................................................................................................................................................................................................................[done]
    ( 53/521) Installing: blog-2.26-150300.4.3.1.x86_64 ...................................................................................................................................................................................................................................................................[done]
    ( 54/521) Installing: sysvinit-tools-2.99-1.1.x86_64 ..................................................................................................................................................................................................................................................................[done]
    warning: /etc/systemd/journald.conf created as /etc/systemd/journald.conf.rpmnew
    warning: /etc/systemd/system.conf created as /etc/systemd/system.conf.rpmnew
    Creating group systemd-resolve with gid 473.
    Creating user systemd-resolve (systemd Resolver) with uid 473 and gid 473.
    Timeout, server XXX.XXX.XXX.XXX not responding.
    The system then is broken again. Here is the complete output: https://susepaste.org/455a429c

    Also trying to apply rd.break=pre-pivot does not help: https://susepaste.org/50a83dd5

  8. #38
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    3,954
    Blog Entries
    1

    Default Re: Upgrade 15.2 to 15.3 leads to libhandle.so.1.0.3 conflict

    Quote Originally Posted by derDaywalker View Post
    After that I proceeded with zypper dup. It asked me again about the lock of the kernel and this time I tried to choose the option to break suse-module-tools-15.3.15-3.17.1.x86_64 and multipath-tools-0.8.5+82+suse.746b76e-2.7.1.x86_64 but I every time I choose to break it, it just asked again. For the suse-module I tried option 115 at least 15 times, but every time it just asked again, thus in the end I chose 'Solution 2: keep obsolete suse-module-tools-15.2.16-lp152.5.12.1.x86_64'. For the multipath-tools it was the same, that it didn't accept to break it with solution 97, thus I chose "Solution 22: keep obsolete multipath-tools-0.8.2+166.7501a27-lp152.3.9.1.x86_64". After that it proceeded with the installation but again just rebooted the machine while upgrading:
    I deal with such conflicts by downloading suse-module-tools and multipath-tools in advance, and after initializing upgrade via
    Code:
    zypper dup  --download-in-advance --releasever=15.3
    rpm -e --nodeps libhandle1
    zypper -v in --download-in-advance --releasever=15.3 zypper libzypp libsolv-tools rpm libproxy1 libmodman1 curl openSUSE-release coreutils filesystem systemd udev aaa_base
    I do
    Code:
    rpm -Uvh --nodeps suse-module-tools-15.3.15-3.17.1.x86_64 multipath-tools-0.8.5+82+suse.746b76e-2.7.1.x86_64
    Generally I do this after zypper up and before zypper dup, which gets all the ups completed without interruptions, and saves the questions for the final dup processing. Note that I don't ever use --releasever in Leap. Instead I edit all .repo files in /etc/zypp/repos.d/ to read 15.3 before beginning an upgrade to 15.3.

    In every case of conflict unresolvable otherwise, when the conflict is with a 15.2 package, I cancel the transaction, force remove that package: rpm -e --nodeps, then restart the transaction. The zypper dup that ultimately follows will via dependency resolution install the current version of that force removed package.

    Something I hadn't taken into account here until now is that I disallow automatic rebuilds of initrds known to work. Building initrds may incorporate use of suse-module-tools and multipath-tools. Thus, breakage can occur when the prior release's initrd rebuild is attempted. That can't happen here, since I apply the immutable flag (chattr +i) to initrds before a rebuild might otherwise be attempted.

    Another issue would be devel packages, which must be matched to the installed or to be installed package version. I wouldn't attempt what I've recommended in this thread without removing or installing devel packages related to those getting special handling. More likely I'd remove all devel packages before beginning an upgrade.

    The system then is broken again. Here is the complete output: https://susepaste.org/455a429c
    All the the zillion "must" install kernel messages are dealt with by choosing break package or keep package and/or upgrading to the new package(s) using rpm --nodeps. Prior to starting I lock all kernel packages:
    Code:
    # zypper ll | grep rne
    28 | kernel-az*                  | package | (any)      |
    29 | kernel-de*                  | package | (any)      |
    30 | kernel-kv*                  | package | (any)      |
    31 | kernel-pree*                | package | (any)      |
    32 | kernel-rt*                  | package | (any)      |
    33 | kernel-sy*                  | package | (any)      |
    Only after all else is upgraded, including suse-module-tools and multipath-tools, I install kernel-default. I have a strong aversion to seeing multiple initrd rebuilds in relatively short succession as has historically happened during upgrades. The "breakage", which apparently only affects initrd building AFAICT, functionally disappears after the forced suse-module-tools and multipath-tools upgrades are done, and a current kernel is allowed to be installed. The 15.3 kernels' initrds cannot be successfully built if the 15.2 versions of those packages remain installed.

    Code:
    Creating group systemd-resolve with gid 473.
    Creating user systemd-resolve (systemd Resolver) with uid 473 and gid 473.
    Timeout, server XXX.XXX.XXX.XXX not responding.
    This looks like upgrade has decided /etc/resolv.conf needs to be updated, but something is preventing it from getting done right, so the new one ends up empty. That can't happen here, as my resolv.conf is not "managed" by anyone but me. systemd-resolved.service is disabled and masked here, and /etc/resolv.conf has the immutable flag set to prevent anything else from mangling it. I don't know why this would happen to you, as previous instruction was starting dup with -d option, to have all packages downloaded in advance of any package installations or upgrades.

    I have 23 15.4 installations and 32 15.3 installations. Most are upgrades from the prior leap or the prior prior leap. I get lots of upgrade practice from keeping 40+ TW installations upgraded periodically. They're all working fine, subject to a very few known bugs, none of which are related to successfully upgrading Leap.
    Reg. Linux User 211409 *** multibooting since 1992
    Primary: 15.3, TW, 15.1 & 13.1 on Haswell @earthlink.net
    Secondary: eComStation (OS/2) &15.2 on i965P/Radeon
    Tertiary: Debian, Fedora, Mageia, more on Rocket Lake & older Intel, AMD, NVidia....

Page 4 of 4 FirstFirst ... 234

Posting Permissions

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