Bug 1218203

This is also related to https://progress.opensuse.org/issues/152755 and should be handled urgently as many SLE Maintenance update tests in openQA are effectively blocked by this.

Workaround as mentioned is to disable the self-update repositories with openQA test setting INSTALLER_NO_SELF_UPDATES=1

See also https://bugzilla.suse.com/show_bug.cgi?id=1218190#c3, where I could pinpoint this issue to the pending https://smelt.suse.de/incident/31617/ libzypp update (I think).

as this is related to libzypp code

#if CURLVERSION_AT_LEAST(7,19,4)
    // restrict following of redirections from https to https only
    if ( _url.getHost() == "download.opensuse.org" ) {
#if CURLVERSION_AT_LEAST(7,85,0)
      SET_OPTION( CURLOPT_REDIR_PROTOCOLS_STR, "http,https" );
#else
      SET_OPTION( CURLOPT_REDIR_PROTOCOLS, CURLPROTO_HTTP | CURLPROTO_HTTPS );
#endif
    } else {
#if CURLVERSION_AT_LEAST(7,85,0)
      SET_OPTION( CURLOPT_REDIR_PROTOCOLS_STR, "https" );
#else
      SET_OPTION( CURLOPT_REDIR_PROTOCOLS, CURLPROTO_HTTPS );
#endif
    }
#endif // if CURLVERSION_AT_LEAST(7,19,4)


Given that on some SLES this relies on a libcurl version update we did during maintenance, and if SET_OPTION FAILS it will cause an exceptuion, can the 
SET_OPTION perhaps be relaxed to not fail if the curl is older still?

This would avoid that we need to ensure libcurl4 is updated before libzypp.

additionaly perhaps add a RPM requires to libcurl4 >= 7.85.0  to the libzypps where you use it

Why? Rpm's autoreqprov handles this IMO correctly. 

The issue here is, that YAST simply calls 
> sh -c rpm2cpio /tmp/libzypp20231219-3783-1nb929u |
>  cpio --quiet --sparse -dimu --no-absolute-filenames
to unpack the installer self updates directly into the instsys. AFAICS no rpm and no dependency resolution is involdes here. Thus any dependency is meaningless in this case.

This may affect zypp as well as any other package extracted this way.

->YAST

Well, did you check the obvious: Is the SCC reachable at that URL in your network segment?

This looks like the location of the actual error:

> 2023-12-18 20:18:33 <1> install(15922) [Ruby] modules/PackageCallbacks.rb(MediaChange):627
>   MediaChange error: err'INVALID:Error occurred while setting download (curl) options for
>   'https://scc.suse.com/access/services/2227?credentials=SUSE_Linux_Enterprise_Server_15_SP4_x86_64':',
>   url'https://scc.suse.com/access/services/2227?credentials=SUSE_Linux_Enterprise_Server_15_SP4_x86_64',
>   prd'', cur'0'/'', wan'1'/'', devs: [], curr_dev: 0

> 2023-12-18 20:18:33 <5> install(15922) [zypp-core] Exception.cc(log):186 MediaCurl.cc(setupEasy):488
>   THROW:    Error occurred while setting download (curl) options for
>   'https://scc.suse.com/access/services/2227?credentials=SUSE_Linux_Enterprise_Server_15_SP4_x86_64':

> 2023-12-18 20:18:33 <5> install(15922) [zypp-core] Exception.cc(log):186 MediaCurl.cc(attachTo):689
>   RETHROW:  Error occurred while setting download (curl) options for
>   'https://scc.suse.com/access/services/2227?credentials=SUSE_Linux_Enterprise_Server_15_SP4_x86_64':

Also notice that the error already appears in the 4th screen of the "installation" step of the test:

https://openqa.suse.de/tests/13107871#step/installation/4

From _packages.root which shows the package versions on the medium, i.e before the self-update:

> libzypp [17.30.0-150400.1.6.x86_64] < libyui-qt-pkg16
> libcurl4 [7.79.1-150400.3.1.x86_64] < libzypp < libyui-qt-pkg16


This was after the second start of YaST, i.e. after the self-update:

> 18:47:01 <1> [zconfig] ZConfig.cc(Impl):511 libzypp: 17.31.15
> 18:47:01 <1> [zconfig] ZConfig.cc(ZConfig):936 libzypp: 17.31.15
> 18:47:09 <1> [zypp-curl] curlhelper.cc(operator()):68 global_init libcurl: 7.79.1


Notice the newer libzypp-17.31.15, but still the old libcurl4-7.79.1. So my best guess is that then newer libcurl4 never made it to the update server that hosts the self-update.

It looks like Marcus' suspicion was right.

(In reply to Michael Andres from comment #5)
> Why? Rpm's autoreqprov handles this IMO correctly. 
> 
> The issue here is, that YAST simply calls 
> > sh -c rpm2cpio /tmp/libzypp20231219-3783-1nb929u |
> >  cpio --quiet --sparse -dimu --no-absolute-filenames
> to unpack the installer self updates directly into the instsys. AFAICS no
> rpm and no dependency resolution is involdes here. Thus any dependency is
> meaningless in this case.
> 
> This may affect zypp as well as any other package extracted this way.

We don't have luxuries such as an RPM DB in the inst-sys.

AFAIK (but I might be wrong here) the way those installer self-updates work is that they must be self-contained; we simply take what that the server offers. So a libzypp update that needs a newer libcurl4 needs to ensure that the latter is part of the update.

This was the self-update:

> 2023-12-18 18:46:35 <1> install(4180) [Ruby]
>   installation/update_repository.rb(packages):166
>   Found 32 packages:
>   ["autoyast2",
>    "autoyast2-installation",
>    "libsolv-tools",
>    "libstdc++6",
>    "libyui-ncurses-pkg16",
>    "libyui-ncurses-rest-api16",
>    "libyui-ncurses16",
>    "libyui-qt-graph16",
>    "libyui-qt-pkg16",
>    "libyui-qt-rest-api16",
>    "libyui-qt16",
>    "libyui-rest-api16",
>    "libyui16",
>    "libzck1",
>    "libzypp",
>    "release-notes-sles",
>    "skelcd-control-leanos",
>    "system-role-common-criteria",
>    "yast2",
>    "yast2-add-on",
>    "yast2-bootloader",
>    "yast2-country",
>    "yast2-installation",
>    "yast2-network",
>    "yast2-packager",
>    "yast2-pkg-bindings",
>    "yast2-schema-default",
>    "yast2-schema-micro",
>    "yast2-security",
>    "yast2-storage-ng",
>    "yast2-transfer",
>    "yast2-users"]


> 2023-12-18 18:46:35 <1> install(4180) [Ruby] packages/package_downloader.rb(download):71 
> .
> Downloading package autoyast2 from repo 0 to /tmp/autoyast220231218-4180-16nsqc6
> Downloading package autoyast2-installation from repo 0 to /tmp/autoyast2-installation20231218-4180-1at6brc
> Downloading package libsolv-tools from repo 0 to /tmp/libsolv-tools20231218-4180-omtl3j
> Downloading package libstdc++6 from repo 0 to /tmp/libstdc++620231218-4180-1kyegby
> Downloading package libyui-ncurses-pkg16 from repo 0 to /tmp/libyui-ncurses-pkg1620231218-4180-w23rgb
> Downloading package libyui-ncurses-rest-api16 from repo 0 to /tmp/libyui-ncurses-rest-api1620231218-4180-3h8c2y
> Downloading package libyui-ncurses16 from repo 0 to /tmp/libyui-ncurses1620231218-4180-u0ii5t
> Downloading package libyui-qt-graph16 from repo 0 to /tmp/libyui-qt-graph1620231218-4180-1f4arfp
> Downloading package libyui-qt-pkg16 from repo 0 to /tmp/libyui-qt-pkg1620231218-4180-j63l7d
> Downloading package libyui-qt-rest-api16 from repo 0 to /tmp/libyui-qt-rest-api1620231218-4180-14o0eyc
> Downloading package libyui-qt16 from repo 0 to /tmp/libyui-qt1620231218-4180-1fax6f3
> Downloading package libyui-rest-api16 from repo 0 to /tmp/libyui-rest-api1620231218-4180-3id9ok
> Downloading package libyui16 from repo 0 to /tmp/libyui1620231218-4180-1ujtjnh
> Downloading package libzck1 from repo 0 to /tmp/libzck120231218-4180-u0w14l
> Downloading package libzypp from repo 0 to /tmp/libzypp20231218-4180-1bed61o
> Downloading package release-notes-sles from repo 0 to /tmp/release-notes-sles20231218-4180-1tbmme9
> Downloading package skelcd-control-leanos from repo 0 to /tmp/skelcd-control-leanos20231218-4180-6guy53
> Downloading package yast2 from repo 0 to /tmp/yast220231218-4180-ml5z0u
> Downloading package yast2-add-on from repo 0 to /tmp/yast2-add-on20231218-4180-r6mwrw
> Downloading package yast2-bootloader from repo 0 to /tmp/yast2-bootloader20231218-4180-1gojosk
> Downloading package yast2-country from repo 0 to /tmp/yast2-country20231218-4180-wae4nh
> Downloading package yast2-installation from repo 0 to /tmp/yast2-installation20231218-4180-1v7nls9
> Downloading package yast2-network from repo 0 to /tmp/yast2-network20231218-4180-hguyql
> Downloading package yast2-packager from repo 0 to /tmp/yast2-packager20231218-4180-1he6tj4
> Downloading package yast2-pkg-bindings from repo 0 to /tmp/yast2-pkg-bindings20231218-4180-qbp2zo
> Downloading package yast2-schema-default from repo 0 to /tmp/yast2-schema-default20231218-4180-k6joah
> Downloading package yast2-schema-micro from repo 0 to /tmp/yast2-schema-micro20231218-4180-1pqtttg
> Downloading package yast2-security from repo 0 to /tmp/yast2-security20231218-4180-6p083q
> Downloading package yast2-storage-ng from repo 0 to /tmp/yast2-storage-ng20231218-4180-10cijxt
> Downloading package yast2-transfer from repo 0 to /tmp/yast2-transfer20231218-4180-h0d53l
> Downloading package yast2-users from repo 0 to /tmp/yast2-users20231218-4180-1qdc1s1
> Downloading package system-role-common-criteria from repo 0 to /var/lib/YaST2/self_update_addon/system-role-common-criteria.rpm

(In reply to Stefan Hundhammer from comment #10)
> (In reply to Michael Andres from comment #5)
> > Why? Rpm's autoreqprov handles this IMO correctly. 
> > 
> > The issue here is, that YAST simply calls 
> > > sh -c rpm2cpio /tmp/libzypp20231219-3783-1nb929u |
> > >  cpio --quiet --sparse -dimu --no-absolute-filenames
> > to unpack the installer self updates directly into the instsys. AFAICS no
> > rpm and no dependency resolution is involdes here. Thus any dependency is
> > meaningless in this case.
> > 
> > This may affect zypp as well as any other package extracted this way.
> 
> We don't have luxuries such as an RPM DB in the inst-sys.

If YAST can't check the dependencies in the inst-sys, then the one providing instsys and installer self-updates must do it (whoever it is). And this one probably is a WONTFIX.

Created attachment 871514 [details]
y2log part of the self-update with [zypp] or [libsolv.*]

It does *something* with the solver - see the [libsolv++] lines here. What exactly it does I don't know yet. Maybe you get an idea by looking at those log lines.

This is only from the first YaST start that contains the self-update, and filtered only for those log lines; also removed some redundant parts like the date, hostname and YaST PID.

Somebody please take over from here; probably the maintenance team providing the self-update. Please check if the information in the packages is sufficient to automatically also include other packages that a self-updated package depends on.


I'll be gone for the Christmas vacation now; back on 2nd January.

maintenance team - please see comments above about self-update content. Thanks

The  libcurl4 update for the INSTALLATION IMAGES is not yet released, but on TOP of the QA queue since 2 days.

I am still hoping it will fix it once released.

*** Bug 1218392 has been marked as a duplicate of this bug. ***

*** Bug 1218463 has been marked as a duplicate of this bug. ***

Hello. I can see that since Marcus' update was introduced to the queue and later released, all the runs are green. Is the issue resolved?

At least the test scenario mentioned here (https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Server-DVD-Updates&machine=64bit&test=autoyast_filesystem_withouthome_yast&version=15-SP4) and
https://progress.opensuse.org/issues/152755 (https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=Server-DVD-Updates&machine=64bit&test=qam-regression-installation-SLES&version=15-SP4) look good again.

However, it would be good if @Sofia Syrianidou would confirm it works in all
affected scenarios.

The issue is fixed for all tests now. Thank you for the quick actions.