Setting severity to "Major" as this bug practically  leave us without test coverage for YaST in s390x:
https://openqa.suse.de/tests/overview?arch=s390x&flavor=&machine=&test=&modules=&module_re=&group_glob=&not_group_glob=&distri=sle&version=15-SP6&build=44.1&groupid=129#
It happens since previous build to Beta2 (since 42.1).
It might be an scc issue and not an installation one, but it is not clear.

There is one similar issue for 12sp4 
(https://bugzilla.suse.com/show_bug.cgi?id=1104304)
It has been fixed by https://build.suse.de/request/show/169723 SLE-12-SP4 / qclib

Created attachment 871247 [details]
YaST screenshot showing the error popup

Error popup:

  Error

  Connection to registration server failed

  Details: ExecuteError:Cmd:[read_value, -s], RC:1
    Error: exit status 1, Output: Error:
    Unable to open configuration, return_code=-2

> 2023-12-08 10:00:38 <3> install(3868) [Ruby] registration/connect_helpers.rb
>   (rescue in catch_registration_errors):145
>   SCC registration failed: RuntimeError:
>   ExecuteError:
>   Cmd: [read_values -s], RC: 1,
>   Error: exit status 1,
>   Output: Error: Unable to open configuration,
>   return_code =-2,


Backtrace:

> usr/lib64/ruby/vendor_ruby/2.5.0/suse/toolkit/shim_utils.rb:52:in `_check_error',
> usr/lib64/ruby/vendor_ruby/2.5.0/suse/toolkit/shim_utils.rb:18:in `_process_result',
> usr/lib64/ruby/vendor_ruby/2.5.0/suse/connect/yast.rb:61:in `announce_system',
> usr/share/YaST2/lib/registration/registration.rb:60:in `block in register',
> usr/share/YaST2/lib/registration/connect_helpers.rb:73:in `catch_registration_errors',
> usr/share/YaST2/lib/registration/registration.rb:59:in `register',
> usr/share/YaST2/lib/registration/registration_ui.rb:350:in `block (2 levels) in register_system',
> usr/share/YaST2/modules/Popup.rb:1020:in `Feedback',
> usr/share/YaST2/lib/registration/registration_ui.rb:340:in `block in register_system',
> usr/lib64/ruby/vendor_ruby/2.5.0/yast/y2logger.rb:98:in `group',
> usr/share/YaST2/lib/registration/registration_ui.rb:333:in `register_system',
> usr/share/YaST2/lib/registration/registration_ui.rb:61:in `block in register_system_and_base_product',
> usr/share/YaST2/lib/registration/connect_helpers.rb:73:in `catch_registration_errors',
> usr/share/YaST2/lib/registration/registration_ui.rb:60:in `register_system_and_base_product',
> usr/share/YaST2/lib/registration/ui/base_system_registration_dialog.rb:524:in `register_system_and_base_product',
> usr/share/YaST2/lib/registration/ui/base_system_registration_dialog.rb:506:in `handle_registration',
> usr/share/YaST2/lib/registration/ui/base_system_registration_dialog.rb:114:in `next_handler',

"read_values" man page:

https://github.com/SUSE/s390-tools/blob/master/read_values.8

> -s  Outputs the values needed by the SCC (SUSE Customer Center)

"read_values -s" code (unchanged since 8 years ago):

https://github.com/SUSE/s390-tools/blob/master/read_values.c#L190-L234

AFAICS this is the error location:

https://github.com/SUSE/s390-tools/blob/master/read_values.c#L139-L142

So

  /usr/bin/read_values -s

could be called, but it failed when it tried to call 'qc_open()'.

That 'qc_open()' very likely comes from here:

https://github.com/ibm-s390-linux/qclib/tree/main

https://github.com/ibm-s390-linux/qclib/blob/main/query_capacity.c#L837 
https://github.com/ibm-s390-linux/qclib/blob/main/query_capacity.h

So the problem is not on the YaST side AFAICS.

It may be a problem on the kernel side (Something change in /sys), with a change in that qclib, or maybe with 'read_values' needing a change now.

% osc maintainer -e s390-tools

Defined in package: Base:System/s390-tools 
  bugowner of s390-tools : 
   mpost@suse.com, nikolay.gueorguiev@suse.com

  maintainer of s390-tools : 
   mpost@suse.com, nikolay.gueorguiev@suse.com

Defined in project:  Base:System
  bugowner of s390-tools : 
   -

  maintainer of s390-tools : 
   dmueller@suse.com, meissner@suse.com, ro@suse.com, aj@suse.com, seife@novell.slipkontur.de, trenn@suse.com, werner@suse.com, daniel@molkentin.de, -

Defined in project:  Base
  bugowner of s390-tools : 
   -

  maintainer of s390-tools : 
   adrian.schroeter@suse.com, jblunck@novell.com, rguenther@suse.com


====================================================

Nikolay, something for you. 

Please update the metadata for this package in IBS / OBS since Mark Post (retired months ago) is still listed as the primary maintainer there.

(In reply to Stefan Hundhammer from comment #8)
> AFAICS this is the error location:
> 
> https://github.com/SUSE/s390-tools/blob/master/read_values.c#L139-L142
> 
> So
> 
>   /usr/bin/read_values -s
> 
> could be called, but it failed when it tried to call 'qc_open()'.
> 
> That 'qc_open()' very likely comes from here:
> 
> https://github.com/ibm-s390-linux/qclib/tree/main
> 
> https://github.com/ibm-s390-linux/qclib/blob/main/query_capacity.c#L837 
> https://github.com/ibm-s390-linux/qclib/blob/main/query_capacity.h
> 
> So the problem is not on the YaST side AFAICS.
> 
> It may be a problem on the kernel side (Something change in /sys), with a
> change in that qclib, or maybe with 'read_values' needing a change now.

read_values needs/depends on qclib packaga. Please ensure that there is the latest qclib package installed on the target system.

(In reply to Stefan Hundhammer from comment #9)
> % osc maintainer -e s390-tools
> 
> Defined in package: Base:System/s390-tools 
>   bugowner of s390-tools : 
>    mpost@suse.com, nikolay.gueorguiev@suse.com
> 
>   maintainer of s390-tools : 
>    mpost@suse.com, nikolay.gueorguiev@suse.com
> 
> Defined in project:  Base:System
>   bugowner of s390-tools : 
>    -
> 
>   maintainer of s390-tools : 
>    dmueller@suse.com, meissner@suse.com, ro@suse.com, aj@suse.com,
> seife@novell.slipkontur.de, trenn@suse.com, werner@suse.com,
> daniel@molkentin.de, -
> 
> Defined in project:  Base
>   bugowner of s390-tools : 
>    -
> 
>   maintainer of s390-tools : 
>    adrian.schroeter@suse.com, jblunck@novell.com, rguenther@suse.com
> 
> 
> ====================================================
> 
> Nikolay, something for you. 
> 
> Please update the metadata for this package in IBS / OBS since Mark Post
> (retired months ago) is still listed as the primary maintainer there.

I have removed Mark Post as a maintainer of s390-tools on Base:System.

This is now set to NEEDINFO from me, but I don't see a question.

Installed system: SLE-15-SP6-Full-s390x-Build44.1-Media1.iso
Skip registration.
Login the system
Check qclib package:
susetest:~ # zypper se -s qclib
Loading repository data...
Reading installed packages...

S | Name               | Type    | Version          | Arch  | Repository
--+--------------------+---------+------------------+-------+--------------------------------
  | qclib              | package | 2.4.0-150600.3.2 | s390x | Development-Tools-Module 15.6-0
  | qclib-devel        | package | 2.4.0-150600.3.2 | s390x | Development-Tools-Module 15.6-0
  | qclib-devel-static | package | 2.4.0-150600.3.2 | s390x | Development-Tools-Module 15.6-0

This package is not installed by default.

JFTR, this is not an installed system, but the inst-sys. And for another record, inst-sys is not built by the YaST Team.

(In reply to yutao wang from comment #15)
> Installed system: SLE-15-SP6-Full-s390x-Build44.1-Media1.iso
> Skip registration.
> Login the system
> Check qclib package:
> susetest:~ # zypper se -s qclib
> Loading repository data...
> Reading installed packages...
> 
> S | Name               | Type    | Version          | Arch  | Repository
> --+--------------------+---------+------------------+-------+----------------
> ----------------
>   | qclib              | package | 2.4.0-150600.3.2 | s390x |
> Development-Tools-Module 15.6-0
>   | qclib-devel        | package | 2.4.0-150600.3.2 | s390x |
> Development-Tools-Module 15.6-0
>   | qclib-devel-static | package | 2.4.0-150600.3.2 | s390x |
> Development-Tools-Module 15.6-0
> 
> This package is not installed by default.

Could we have more information about the target system? E.g.
cat /proc/cpuinfo | grep machine
cat /proc/sysinfo | grep Type:

or the tar ball /var/log/scc*.txz generated by the 'supportconfig' command.

(In reply to Nikolay Gueorguiev from comment #18)
> (In reply to yutao wang from comment #15)
> > Installed system: SLE-15-SP6-Full-s390x-Build44.1-Media1.iso
> > Skip registration.
> > Login the system
> > Check qclib package:
> > susetest:~ # zypper se -s qclib
> > Loading repository data...
> > Reading installed packages...
> > 
> > S | Name               | Type    | Version          | Arch  | Repository
> > --+--------------------+---------+------------------+-------+----------------
> > ----------------
> >   | qclib              | package | 2.4.0-150600.3.2 | s390x |
> > Development-Tools-Module 15.6-0
> >   | qclib-devel        | package | 2.4.0-150600.3.2 | s390x |
> > Development-Tools-Module 15.6-0
> >   | qclib-devel-static | package | 2.4.0-150600.3.2 | s390x |
> > Development-Tools-Module 15.6-0
> > 
> > This package is not installed by default.
> 
> Could we have more information about the target system? E.g.
> cat /proc/cpuinfo | grep machine
> cat /proc/sysinfo | grep Type:
> 
> or the tar ball /var/log/scc*.txz generated by the 'supportconfig' command.

BTW Could you issue the 'read_value -s' command manually to be sure that there is an issue with it, and not a 'connection timeout error' with the SCC? 
'read_values' is 'display information' only.

(In reply to Nikolay Gueorguiev from comment #19)
> (In reply to Nikolay Gueorguiev from comment #18)
> > (In reply to yutao wang from comment #15)
> > > Installed system: SLE-15-SP6-Full-s390x-Build44.1-Media1.iso
> > > Skip registration.
> > > Login the system
> > > Check qclib package:
> > > susetest:~ # zypper se -s qclib
> > > Loading repository data...
> > > Reading installed packages...
> > > 
> > > S | Name               | Type    | Version          | Arch  | Repository
> > > --+--------------------+---------+------------------+-------+----------------
> > > ----------------
> > >   | qclib              | package | 2.4.0-150600.3.2 | s390x |
> > > Development-Tools-Module 15.6-0
> > >   | qclib-devel        | package | 2.4.0-150600.3.2 | s390x |
> > > Development-Tools-Module 15.6-0
> > >   | qclib-devel-static | package | 2.4.0-150600.3.2 | s390x |
> > > Development-Tools-Module 15.6-0
> > > 
> > > This package is not installed by default.
> > 
> > Could we have more information about the target system? E.g.
> > cat /proc/cpuinfo | grep machine
> > cat /proc/sysinfo | grep Type:
> > 
> > or the tar ball /var/log/scc*.txz generated by the 'supportconfig' command.
> 
> BTW Could you issue the 'read_value -s' command manually to be sure that
> there is an issue with it, and not a 'connection timeout error' with the
> SCC? 
> 'read_values' is 'display information' only.

The latest qclib should be installed manually, too.

susetest:~ # cat /proc/cpuinfo | grep machine
processor 0: version = FF,  identification = 1288E8,  machine = 8561
machine         : 8561
susetest:~ # cat /proc/sysinfo | grep Type:
Type:                 8561

Created attachment 871285 [details]
susetest log file

I have recreated the issue on a test s390x system. 
Before starting the yast.ssh, read_values fails. 

The strace shows the following:

 * * *
0:install:~ # strace -ff -Z -ttt -v read_values -s
1702417091.230307 openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
Error: Unable to open configuration, return_code =-2
1702417091.230567 +++ exited with 1 +++ 

 * * *
0:install:~ # strace read_values -s
execve("/usr/bin/read_values", ["read_values", "-s"], 0x3ffda0fa408 /* 37 vars */) = 0
brk(NULL)                               = 0x3052000
brk(0x3052a00)                          = 0x3052a00
uname({sysname="Linux", nodename="install", ...}) = 0
readlink("/proc/self/exe", "/parts/mp_0001/usr/bin/read_valu"..., 4096) = 34
brk(0x3073a00)                          = 0x3073a00
brk(0x3074000)                          = 0x3074000
mprotect(0x10ca000, 16384, PROT_READ)   = 0
openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=3916, ...}) = 0
read(3, "# GNU libc iconv configuration.\n"..., 1024) = 1024
read(3, "ession matching results.\n#  file"..., 1024) = 1024
read(3, "alias\tISO_8859-15//\t\tISO-8859-15"..., 1024) = 1024
read(3, "BE//\nmodule\tUTF-16BE//\t\tINTERNAL"..., 1024) = 844
read(3, "", 1024)                       = 0
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
write(1, "Error: Unable to open configurat"..., 53Error: Unable to open configuration, return_code =-2
) = 53
exit_group(1)                           = ?
+++ exited with 1 +++

 * * *
During the YaST installation, the error persists. 

 * * *
After successful installation, and reboot, 'read_values -s' works, with regular user IDs and root.  

nico@localhost:~> read_values -s
Version: 1.0.3
Type: 8561
Sequence Code: 00000000000688E8
CPUs Total: 49
CPUs IFL: 49
LPAR Number: 4
LPAR Name: ZL04
LPAR Characteristics: Shared
LPAR CPUs Total: 3
LPAR CPUs IFL: 3
VM00 Name: LINUX202
VM00 Control Program: z/VM    7.3.0
VM00 CPUs Total: 1
VM00 IFLs: 1

localhost:~ # read_values -s
Version: 1.0.3
Type: 8561
Sequence Code: 00000000000688E8
CPUs Total: 49
CPUs IFL: 49
LPAR Number: 4
LPAR Name: ZL04
LPAR Characteristics: Shared
LPAR CPUs Total: 3
LPAR CPUs IFL: 3
VM00 Name: LINUX202
VM00 Control Program: z/VM    7.3.0
VM00 CPUs Total: 1
VM00 IFLs: 1
localhost:~ #

 * * *
Product can be registered, and receive regular updates.

 * * *
It is safe to say that read_values works as designed; the product's installation image is missing something...

(In reply to Nikolay Gueorguiev from comment #24)
> I have recreated the issue on a test s390x system. 
> Before starting the yast.ssh, read_values fails. 
> 
> The strace shows the following:
> 
>  * * *
> 0:install:~ # strace -ff -Z -ttt -v read_values -s
> 1702417091.230307 openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache",
> O_RDONLY) = -1 ENOENT (No such file or directory)
> Error: Unable to open configuration, return_code =-2
> 1702417091.230567 +++ exited with 1 +++ 
> 
>  * * *
> 0:install:~ # strace read_values -s
> execve("/usr/bin/read_values", ["read_values", "-s"], 0x3ffda0fa408 /* 37
> vars */) = 0
> brk(NULL)                               = 0x3052000
> brk(0x3052a00)                          = 0x3052a00
> uname({sysname="Linux", nodename="install", ...}) = 0
> readlink("/proc/self/exe", "/parts/mp_0001/usr/bin/read_valu"..., 4096) = 34
> brk(0x3073a00)                          = 0x3073a00
> brk(0x3074000)                          = 0x3074000
> mprotect(0x10ca000, 16384, PROT_READ)   = 0
> openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = -1
> ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/lib64/gconv/gconv-modules", O_RDONLY|O_CLOEXEC) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=3916, ...}) = 0
> read(3, "# GNU libc iconv configuration.\n"..., 1024) = 1024
> read(3, "ession matching results.\n#  file"..., 1024) = 1024
> read(3, "alias\tISO_8859-15//\t\tISO-8859-15"..., 1024) = 1024
> read(3, "BE//\nmodule\tUTF-16BE//\t\tINTERNAL"..., 1024) = 844
> read(3, "", 1024)                       = 0
> close(3)                                = 0
> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
> write(1, "Error: Unable to open configurat"..., 53Error: Unable to open
> configuration, return_code =-2
> ) = 53
> exit_group(1)                           = ?
> +++ exited with 1 +++

>  * * *
> It is safe to say that read_values works as designed; the product's
> installation image is missing something...

is it possible to make errors like this more explicit on read_values? i.e, what's missing for instance?, or that the errors are a bit more verbose (in case it happens again)

The file /usr/lib64/gconv/gconv-modules.cache is not part of the installation media.

The read_values source code is very simple:

https://build.opensuse.org/package/view_file/Base:System/s390-tools/read_values.c?expand=1

(In reply to Ihno Krumreich from comment #26)
> The file /usr/lib64/gconv/gconv-modules.cache is not part of the
> installation media.

I don't think it ever was, or it should be. And the syscall opens /usr/lib64/gconv/gconv-modules successfully, so how can this be the problem? It's just a normal fallback chain: Try to use a cache file, and if that fails, read the real thing.

Look at /usr/lib64/gconv/gconv-modules on your system: It's encoding conversion information. Not sure why this is even relevant for this little 'read_values.c' program.


What's the difference between calling 'read_values' without '-s' or with it? AFAICS it uses the exact same 'qc_open()' call regardless.

	configuration_handle = qc_open(&return_code);
        ...
        ...
	if (return_code > 0) {
		printf("Warning: Unable to read configuration completely, return_code =%d\n", return_code);
		return -2;
	} /* endif */

This is not a YaST problem.

Maybe it's an installation-images problem, but I really don't believe that.

I suspect that the real problem is that /proc/sysinfo (s/390 specific; which is used according to the man page) could not be opened. Is it there in the inst-sys?

Nikolay, did you check that?

If it's not there, are we missing something that the kernel needs; like a kernel module or parameter?

(In reply to Stefan Hundhammer from comment #30)
> I suspect that the real problem is that /proc/sysinfo (s/390 specific; which
> is used according to the man page) could not be opened. Is it there in the
> inst-sys?
> 
> Nikolay, did you check that?
> 
> If it's not there, are we missing something that the kernel needs; like a
> kernel module or parameter?

SUSE Linux Enterprise 15 SP6 Installation

Run yast.ssh to start the installation.

0:install:~ # cat /proc/sysinfo 
Manufacturer:         IBM             
Type:                 8561
LIC Identifier:       306825ff650c46c1
Model:                400              LT1             
Sequence Code:        00000000000688E8
Plant:                02  
Model Capacity:       400              00000000
Capacity Adj. Ind.:   100
Capacity Ch. Reason:  0
Capacity Transient:   0
Type 1 Percentage:    0
Type 2 Percentage:    0
Type 3 Percentage:    0
Type 4 Percentage:    0
Type 5 Percentage:    0

CPUs Total:           71
CPUs Configured:      0
CPUs Standby:         0
CPUs Reserved:        71
CPUs G-MTID:          0
CPUs S-MTID:          1
Capability:           3085
Nominal Capability:   3085
Secondary Capability: 416
Adjustment 02-way:    62750
Adjustment 03-way:    61302
Adjustment 04-way:    60198
Adjustment 05-way:    59285
Adjustment 06-way:    58473
Adjustment 07-way:    57722
Adjustment 08-way:    57012
Adjustment 09-way:    56333
Adjustment 10-way:    55677
Adjustment 11-way:    55042
Adjustment 12-way:    54423
Adjustment 13-way:    53818
Adjustment 14-way:    53227
Adjustment 15-way:    52648
Adjustment 16-way:    52080
Adjustment 17-way:    51522
Adjustment 18-way:    51013
Adjustment 19-way:    50546
Adjustment 20-way:    50114
Adjustment 21-way:    49712
Adjustment 22-way:    49336
Adjustment 23-way:    48983
Adjustment 24-way:    48650
Adjustment 25-way:    48334
Adjustment 26-way:    48034
Adjustment 27-way:    47748
Adjustment 28-way:    47475
Adjustment 29-way:    47213
Adjustment 30-way:    46961
Adjustment 31-way:    46718
Adjustment 32-way:    46484
Adjustment 33-way:    46257
Adjustment 34-way:    46037
Adjustment 35-way:    46037
Adjustment 36-way:    46037
Adjustment 37-way:    46037
Adjustment 38-way:    46037
Adjustment 39-way:    46037
Adjustment 40-way:    46037
Adjustment 41-way:    46037
Adjustment 42-way:    46037
Adjustment 43-way:    46037
Adjustment 44-way:    46037
Adjustment 45-way:    46037
Adjustment 46-way:    46037
Adjustment 47-way:    46037
Adjustment 48-way:    46037
Adjustment 49-way:    46037
Adjustment 50-way:    46037
Adjustment 51-way:    46037
Adjustment 52-way:    46037
Adjustment 53-way:    46037
Adjustment 54-way:    46037
Adjustment 55-way:    46037
Adjustment 56-way:    46037
Adjustment 57-way:    46037
Adjustment 58-way:    46037
Adjustment 59-way:    46037
Adjustment 60-way:    46037
Adjustment 61-way:    46037
Adjustment 62-way:    46037
Adjustment 63-way:    46037
Adjustment 64-way:    46037
Adjustment 65-way:    46037
Adjustment 66-way:    46037
Adjustment 67-way:    46037
Adjustment 68-way:    46037
Adjustment 69-way:    46037
Adjustment 70-way:    46037
Adjustment 71-way:    46037

LPAR Number:          4
LPAR Characteristics: Shared 
LPAR Name:            ZL04    
LPAR Adjustment:      61
LPAR CPUs Total:      3
LPAR CPUs Configured: 3
LPAR CPUs Standby:    0
LPAR CPUs Reserved:   0
LPAR CPUs Dedicated:  0
LPAR CPUs Shared:     3
LPAR CPUs G-MTID:     0
LPAR CPUs S-MTID:     1
LPAR CPUs PS-MTID:    0

VM00 Name:            LINUX203
VM00 Control Program: z/VM    7.3.0   
VM00 Adjustment:      333
VM00 CPUs Total:      1
VM00 CPUs Configured: 1
VM00 CPUs Standby:    0
VM00 CPUs Reserved:   0
0:install:~ #

I don't see what a missing gconv-modules.cache would have to do with it.

As you see in the strace log, glibc just parses gconv-modules instead.

Also, gconv-modules.cache has never been present in the installation system.
The question would be why it should make a difference in sle15-sp6 specifically.

The "Unable to open configuration" error is a result of qc_open() failing.
Why it does, I've no idea.

There might well be a difference between the installation system and the
installed system. But I've no idea what it could be. Also, why does it work
in sp5, then?

Sorry, I think this is a s390-tools specific problem. Maybe check what this
qc_open() actually does.

Note that there is gdb available iin the installation system after you
run 'extend gdb'.

Upstream source code repo of the QCLib that is used in 'read_values':

https://github.com/ibm-s390-linux/qclib

BTW as we already found out earlier, `read_values` is statically linked, which includes QCLib.

Setting the QC_DEBUG environment variable to a positive numeric value should get some more information:

https://github.com/ibm-s390-linux/qclib/blob/main/query_capacity.c#L37-L42

qc_open() source:

https://github.com/ibm-s390-linux/qclib/blob/main/query_capacity.c#L757-L835

Maybe related?

https://bugzilla.suse.com/show_bug.cgi?id=1214466#c1

Yeah, QC_DEBUG would be interesting.

https://github.com/ibm-s390-linux/qclib/blob/main/query_capacity.h#L644-L663

Uhm, yes, bug 1214466 looks interesting.

"Secure Boot/IPL enables kernel lockdown mode..."

I suspect the 'read_values' binary / the s390-tools package are not the latest in this build, not yet containing the fix to QCLib from bug #121466.

Nikolay is trying to build the correct version of the binary and copy / bind-mount it to the inst-sys of this build that he started on his test machine to check.

 * * *
Manually copied the read_values from s390-tools ver. 2.29. It works. 
The SCC registration works, the installation completes. 

See below.

 * * *
SUSE Linux Enterprise 15 SP6 Installation

Run yast.ssh to start the installation.

0:install:~ # cd /tmp/

0:install:/tmp # ls -laFh
total 24K
drwxrwxrwt  3 root root 4.0K Dec 14 02:30 ./
drwxr-xr-x 25 root root 4.0K Dec 14 02:30 ../
-rw-r--r--  1 root root   30 Dec 14 02:30 host_ips
-rw-r--r--  1 root root   14 Dec 14 02:30 host_name
-rw-r--r--  1 root root    5 Dec 14 02:30 linuxrc_installer_name
drwx------  3 root root 4.0K Dec 14 02:30 tmp.arUrVGKU4F/

0:install:/tmp # scp nico@10.144.136.37://usr/bin/read_values ./
read_values                                                                                                                                                                                          100%  882KB  38.2MB/s   00:00    

0:install:/tmp # ls -laFh
total 912K
drwxrwxrwt  3 root root 4.0K Dec 14 02:32 ./
drwxr-xr-x 25 root root 4.0K Dec 14 02:30 ../
-rw-r--r--  1 root root   30 Dec 14 02:30 host_ips
-rw-r--r--  1 root root   14 Dec 14 02:30 host_name
-rw-r--r--  1 root root    5 Dec 14 02:30 linuxrc_installer_name
-rwxr-xr-x  1 root root 882K Dec 14 02:32 read_values*
drwx------  3 root root 4.0K Dec 14 02:30 tmp.arUrVGKU4F/

0:install:/tmp # ./read_values -s
Version: 1.0.3
Type: 8561
Sequence Code: 00000000000688E8
CPUs Total: 49
CPUs IFL: 49
LPAR Number: 4
LPAR Name: ZL04
LPAR Characteristics: Shared
LPAR CPUs Total: 3
LPAR CPUs IFL: 3
VM00 Name: LINUX202
VM00 Control Program: z/VM    7.3.0
VM00 CPUs Total: 1
VM00 IFLs: 1
0:install:/tmp #

0:install:/tmp # cd ..

0:install:/ # mount -o bind /tmp/read_values /usr/bin/read_values

0:install:/ # read_values -s
Version: 1.0.3
Type: 8561
Sequence Code: 00000000000688E8
CPUs Total: 49
CPUs IFL: 49
LPAR Number: 4
LPAR Name: ZL04
LPAR Characteristics: Shared
LPAR CPUs Total: 3
LPAR CPUs IFL: 3
VM00 Name: LINUX202
VM00 Control Program: z/VM    7.3.0
VM00 CPUs Total: 1
VM00 IFLs: 1
0:install:/ #

OK, that's great to hear; so what remains to be done is make sure that the latest version of the s390-tools package with that newer 'read_values' is actually included in SLE-15-SP6.

I found SUSEConnect fails to register extension on our CC role LPAR SLES15SP4 QU3 in FIPS mode with Error: exit status 1, Output: Error: Unable to open configuration, return_code =-2

Setup: In CC role https://confluence.suse.com/pages/viewpage.action?pageId=1058603521

SUSEConnect --list-extensions
AVAILABLE EXTENSIONS AND MODULES

    Basesystem Module 15 SP4 s390x (Activated)
    Deactivate with: SUSEConnect -d -p sle-module-basesystem/15.4/s390x

        Containers Module 15 SP4 s390x
        Activate with: SUSEConnect -p sle-module-containers/15.4/s390x

        Desktop Applications Module 15 SP4 s390x
        Activate with: SUSEConnect -p sle-module-desktop-applications/15.4/s390x

            Development Tools Module 15 SP4 s390x
            Activate with: SUSEConnect -p sle-module-development-tools/15.4/s390x

        Python 3 Module 15 SP4 s390x
        Activate with: SUSEConnect -p sle-module-python3/15.4/s390x

        SUSE Linux Enterprise Live Patching 15 SP4 s390x
        Activate with: SUSEConnect -p sle-module-live-patching/15.4/s390x -r ADDITIONAL REGCODE

        SUSE Package Hub 15 SP4 s390x
        Activate with: SUSEConnect -p PackageHub/15.4/s390x

        Server Applications Module 15 SP4 s390x (Activated)
        Deactivate with: SUSEConnect -d -p sle-module-server-applications/15.4/s390x

            Legacy Module 15 SP4 s390x
            Activate with: SUSEConnect -p sle-module-legacy/15.4/s390x

            Public Cloud Module 15 SP4 s390x
            Activate with: SUSEConnect -p sle-module-public-cloud/15.4/s390x

            SUSE Linux Enterprise High Availability Extension 15 SP4 s390x
            Activate with: SUSEConnect -p sle-ha/15.4/s390x -r ADDITIONAL REGCODE

            Web and Scripting Module 15 SP4 s390x
            Activate with: SUSEConnect -p sle-module-web-scripting/15.4/s390x

        Transactional Server Module 15 SP4 s390x
        Activate with: SUSEConnect -p sle-module-transactional-server/15.4/s390x

    Certifications Module 15 SP4 s390x
    Activate with: SUSEConnect -p sle-module-certifications/15.4/s390x

    SUSE Linux Enterprise Server LTSS 15 SP4 s390x
    Activate with: SUSEConnect -p SLES-LTSS/15.4/s390x -r ADDITIONAL REGCODE


REMARKS

(Not available) The module/extension is not enabled on your RMT/SMT
(Activated)     The module/extension is activated on your system

MORE INFORMATION

You can find more information about available modules here:
https://www.suse.com/documentation/sles-15/singlehtml/art_modules/art_modules.html


#####Issue#####
SUSEConnect --debug -p sle-module-development-tools/15.4/s390x
cmd line: [SUSEConnect --debug -p sle-module-development-tools/15.4/s390x]
For http debug use: GODEBUG=http2debug=2 SUSEConnect --debug -p sle-module-development-tools/15.4/s390x
open /etc/SUSEConnect: no such file or directory
Registering system to SUSE Customer Center
Reading credentials: /etc/zypp/credentials.d/SCCcredentials
Credentials read: file: /etc/zypp/credentials.d/SCCcredentials, username: SCC_721a7653561e4f06972221bd04f5235b, password: REDACTED, system_token: 88eb48d1-8c30-4304-b842-8911e5638c6d

Updating system details on https://scc.suse.com ...
Executing: [/usr/bin/zypper targetos]
Return code: 0
Output: sle-15-s390x
Executing: [uname -i]
Return code: 0
Output: s390x
Executing: [dmidecode -t system]
Return code: -1
Executing: [read_values -s]
Return code: 1
Output: Error: Unable to open configuration, return_code =-2
SUSEConnect error: ExecuteError: Cmd: [read_values -s], RC: 1, Error: exit status 1, Output: Error: Unable to open configuration, return_code =-2

The bug should have been fixed by https://bugzilla.suse.com/show_bug.cgi?id=1214466 https://build.suse.de/request/show/313129

(In reply to Viktors Trubovics from comment #43)
> I found SUSEConnect fails to register extension on our CC role LPAR
> SLES15SP4 QU3 in FIPS mode with Error: exit status 1, Output: Error: Unable
> to open configuration, return_code =-2
> 
Does it mean we need to update also SP4 by a new qclib and s390-tools? Did it work before or this is the first FIPS test?

(In reply to Marcela Maslanova from comment #45)
> (In reply to Viktors Trubovics from comment #43)
> > I found SUSEConnect fails to register extension on our CC role LPAR
> > SLES15SP4 QU3 in FIPS mode with Error: exit status 1, Output: Error: Unable
> > to open configuration, return_code =-2
> > 
> Does it mean we need to update also SP4 by a new qclib and s390-tools? Did
> it work before or this is the first FIPS test?

I cannot say right now - I tried to register extension on my LPAR to investigate another issue happened on s390x test node. Did not do it before.
https://openqa.suse.de/tests/13187930
https://openqa.suse.de/tests/13187930/logfile?filename=autoinst-log.txt

[2024-01-03T15:52:54.205757+01:00] [info] [pid:14047] ::: basetest::runtest: # Test died: command 'pip3 --quiet install lxml pytest pytest_cov json2html sphinxcontrib-jinjadomain autojinja sphinx_rtd_theme myst_parser prometheus_client mypy openpyxl pandas pcre2 cmakelint sphinx' failed at /usr/lib/os-autoinst/testapi.pm line 926.
  	testapi::assert_script_run("pip3 --quiet install lxml pytest pytest_cov json2html sphinxc"..., "timeout", 600) called at /var/lib/openqa/pool/2/os-autoinst-distri-opensuse/lib/oscap_tests.pm line 699
  	oscap_tests::get_cac_code() called at /var/lib/openqa/pool/2/os-autoinst-distri-opensuse/lib/oscap_tests.pm line 924
  	oscap_tests::oscap_security_guide_setup(oscap_security_guide_setup=HASH(0x557900c8cc00)) called at /var/lib/openqa/pool/2/os-autoinst-distri-opensuse/tests/security/oscap_profile_tests/oscap_security_guide_setup.pm line 26
  	oscap_security_guide_setup::run(oscap_security_guide_setup=HASH(0x557900c8cc00)) called at /usr/lib/os-autoinst/basetest.pm line 352
  	eval {...} called at /usr/lib/os-autoinst/basetest.pm line 346
  	basetest::runtest(oscap_security_guide_setup=HASH(0x557900c8cc00)) called at /usr/lib/os-autoinst/autotest.pm line 415
  	eval {...} called at /usr/lib/os-autoinst/autotest.pm line 415
  	autotest::runalltests() called at /usr/lib/os-autoinst/autotest.pm line 272
  	eval {...} called at /usr/lib/os-autoinst/autotest.pm line 272
  	autotest::run_all() called at /usr/lib/os-autoinst/autotest.pm line 323
  	autotest::__ANON__(Mojo::IOLoop::ReadWriteProcess=HASH(0x55790197a4f8)) called at /usr/lib/perl5/vendor_perl/5.26.1/Mojo/IOLoop/ReadWriteProcess.pm line 329
  	eval {...} called at /usr/lib/perl5/vendor_perl/5.26.1/Mojo/IOLoop/ReadWriteProcess.pm line 329
  	Mojo::IOLoop::ReadWriteProcess::_fork(Mojo::IOLoop::ReadWriteProcess=HASH(0x55790197a4f8), CODE(0x557902a20390)) called at /usr/lib/perl5/vendor_perl/5.26.1/Mojo/IOLoop/ReadWriteProcess.pm line 492
  	Mojo::IOLoop::ReadWriteProcess::start(Mojo::IOLoop::ReadWriteProcess=HASH(0x55790197a4f8)) called at /usr/lib/os-autoinst/autotest.pm line 325
  	autotest::start_process() called at /usr/lib/os-autoinst/OpenQA/Isotovideo/Runner.pm line 94
  	OpenQA::Isotovideo::Runner::start_autotest(OpenQA::Isotovideo::Runner=HASH(0x5578fc080650)) called at /usr/bin/isotovideo line 133
  	eval {...} called at /usr/bin/isotovideo line 122

(In reply to Marcela Maslanova from comment #45)
> Does it mean we need to update also SP4 by a new qclib and s390-tools? Did
> it work before or this is the first FIPS test?

At least CC role on s390x originally worked when the last 15-SP4 QU media was being tested half a year ago:

Full: https://openqa.suse.de/tests/11575158#step/partitioning/1

Online: https://openqa.suse.de/tests/11575224#step/partitioning/1

(In reply to Timo Jyrinki from comment #47)
> (In reply to Marcela Maslanova from comment #45)
> > Does it mean we need to update also SP4 by a new qclib and s390-tools? Did
> > it work before or this is the first FIPS test?
> 
> At least CC role on s390x originally worked when the last 15-SP4 QU media
> was being tested half a year ago:
> 
> Full: https://openqa.suse.de/tests/11575158#step/partitioning/1
> 
> Online: https://openqa.suse.de/tests/11575224#step/partitioning/1

Was secure boot enabled in this test?

(In reply to Marcela Maslanova from comment #45)
> (In reply to Viktors Trubovics from comment #43)
> > I found SUSEConnect fails to register extension on our CC role LPAR
> > SLES15SP4 QU3 in FIPS mode with Error: exit status 1, Output: Error: Unable
> > to open configuration, return_code =-2
> > 
> Does it mean we need to update also SP4 by a new qclib and s390-tools? Did
> it work before or this is the first FIPS test?

If SP4 should be loaded with secure boot this update has to happen.

(In reply to Ihno Krumreich from comment #48)
> > At least CC role on s390x originally worked when the last 15-SP4 QU media
> > was being tested half a year ago:
> > 
> > Full: https://openqa.suse.de/tests/11575158#step/partitioning/1
> > 
> > Online: https://openqa.suse.de/tests/11575224#step/partitioning/1
> 
> Was secure boot enabled in this test?

No to both SP4 and current testing, we're only able to test automatically with qemu/svirt at the moment, and we're not aware that bits to utilize secure boot (also called IBM Secure Execution?) would be available in s390x VMs.

(In reply to Ihno Krumreich from comment #49)
> (In reply to Marcela Maslanova from comment #45)
> > (In reply to Viktors Trubovics from comment #43)
> > > I found SUSEConnect fails to register extension on our CC role LPAR
> > > SLES15SP4 QU3 in FIPS mode with Error: exit status 1, Output: Error: Unable
> > > to open configuration, return_code =-2
> > > 
> > Does it mean we need to update also SP4 by a new qclib and s390-tools? Did
> > it work before or this is the first FIPS test?
> 
> If SP4 should be loaded with secure boot this update has to happen.

It can of course be questioned whether this is a supported configuration.

Question to PM

(In reply to Timo Jyrinki from comment #51)
> (In reply to Ihno Krumreich from comment #48)
> > > At least CC role on s390x originally worked when the last 15-SP4 QU media
> > > was being tested half a year ago:
> > > 
> > > Full: https://openqa.suse.de/tests/11575158#step/partitioning/1
> > > 
> > > Online: https://openqa.suse.de/tests/11575224#step/partitioning/1
> > 
> > Was secure boot enabled in this test?
> 
> No to both SP4 and current testing, we're only able to test automatically
> with qemu/svirt at the moment, and we're not aware that bits to utilize
> secure boot (also called IBM Secure Execution?) would be available in s390x
> VMs.

secure boot and secure execution are two different things.
They are __not__ equal.

We fully support IBM Z-Series secure boot since (I think) SLES 15 SP3 or SP4.

So it is a supported configuration.

Let me clarify mentioned technologies on s390x:
Secure Executing in short are runtime RAM encryption on KVM s390x VM. Requires KVM host configuration and specially compiled KVM image.
Secure boot on s390x currently available only for SLES/SLEM running directly on LPAR. Requires LPAR configuration and SLES/SLEM configuration.
Secure Boot on KVM s390x VM currently are not available. It is somewhere in IBM's plans to release it soon for s390x KVM.

SUSE-RU-2024:0363-1: An update that contains nine features and has six fixes can now be installed.

Category: recommended (moderate)
Bug References: 1214466, 1214534, 1216257, 1217838, 1217923, 1219227
Jira References: PED-4604, PED-578, PED-5783, PED-6373, PED-6539, PED-6649, PED-6785, PED-7136, PED-7138
Sources used:
openSUSE Leap 15.5 (src): s390-tools-2.30.0-150500.9.10.1
SUSE Linux Enterprise Micro 5.5 (src): s390-tools-2.30.0-150500.9.10.1
Basesystem Module 15-SP5 (src): s390-tools-2.30.0-150500.9.10.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

s390-tools 2.30 released. Bug fixed.