|
Bugzilla – Full Text Bug Listing |
| Summary: | [Build 44.1] SCC registration failed: RuntimeError: ExecuteError: Cmd: [read_values -s], RC: 1, Error: exit status 1, Output: Error: Unable to open configuration, return_code =-2 | ||
|---|---|---|---|
| Product: | [openSUSE] PUBLIC SUSE Linux Enterprise Server 15 SP6 | Reporter: | yutao wang <yuwang> |
| Component: | Other | Assignee: | Nikolay Gueorguiev <nikolay.gueorguiev> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | Major | ||
| Priority: | P1 - Urgent | CC: | felix.niederwanger, ihno, jeriveramoya, llzhao, marcela.maslanova, meissner, msvec, nikolay.gueorguiev, qe-virt, rtsvetkov, santiago.zarate, shundhammer, snwint, tjyrinki, viktors.trubovics, xlai, yuwang |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | S/390 | ||
| OS: | SLES 15 | ||
| URL: | https://openqa.suse.de/tests/13003012/modules/register_via_scc/steps/256 | ||
| Whiteboard: | |||
| Found By: | openQA | Services Priority: | |
| Business Priority: | Blocker: | Yes | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | 1214466 | ||
| Bug Blocks: | |||
| Attachments: |
yast 2 log
YaST screenshot showing the error popup susetest log file |
||
|
Description
yutao wang
2023-12-11 03:30:34 UTC
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=¬_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. |