Bug 2094099
| Summary: | Cannot read DMI info with SecureBoot enabled | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Ramesh kumar <ramkumar> | ||||
| Component: | subscription-manager | Assignee: | Pino Toscano <ptoscano> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Red Hat subscription-manager QE Team <rhsm-qe> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 9.0 | CC: | abkulkar, andrin, cdonnell, joerg.kastning, john.sincock, jsefler, msunil, myllynen, parathi, ptoscano, redakkan, sbt, sgajendr, shivagup, vchepkov, yuefliu | ||||
| Target Milestone: | rc | Keywords: | Triaged, ZStream | ||||
| Target Release: | 9.1 | Flags: | pm-rhel:
mirror+
|
||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | subscription-manager-1.29.29-1.el9 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | |||||||
| : | 2101718 2173581 2173583 (view as bug list) | Environment: | |||||
| Last Closed: | 2022-11-15 11:19:33 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 2091421, 2101718, 2173581, 2173583 | ||||||
| Deadline: | 2022-07-18 | ||||||
| Attachments: |
|
||||||
|
Description
Ramesh kumar
2022-06-06 20:27:03 UTC
Hi Ramesh, Thank for opening the bug. Can you please share additional details to help us troubleshoot further. 1. Details of the test system, Can you please share the hypervisor details ( Ex : kvm, ESX ) , also the output of dmidecode 2. Please share the output of `subscription-manager facts --list` with rhsm.log output ( in Debug mode) 3. Output of "ls -l /dev/mem" Thanks, Rehana
I am seeing this too, on vmware hypervisor, and it happens even when secure boot is disabled.
It is a real issue.
Please un-triage this and get it fixed, thank, you.
eg this vm:
[root@audccfored09 06-16 18:07:39 ~]# subscription-manager facts| grep uuid
[root@audccfored09 06-27 12:03:15 ~]#
[root@audccfored09 06-27 12:03:15 ~]# ls -l /dev/mem
crw-r-----. 1 root kmem 1, 1 Jun 10 14:20 /dev/mem
[root@audccfored09 06-27 12:03:37 ~]#
[root@audccfored09 06-27 12:03:37 ~]# subscription-manager facts --list
cpu.core(s)_per_socket: 1
cpu.cpu(s): 1
cpu.cpu_socket(s): 1
cpu.thread(s)_per_core: 1
cpu.topology_source: kernel /sys cpu sibling lists
distribution.id: Plow
distribution.name: Red Hat Enterprise Linux
distribution.version: 9.0
distribution.version.modifier: Unknown
kpatch.installed: Unknown
kpatch.loaded: Unknown
last_boot: 2022-06-10 04:20:13 UTC
lscpu.address_sizes: 43 bits physical, 48 bits virtual
lscpu.architecture: x86_64
lscpu.bios_model_name: Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz
lscpu.bios_vendor_id: GenuineIntel
lscpu.bogomips: 4190.15
lscpu.byte_order: Little Endian
lscpu.core(s)_per_socket: 1
lscpu.cpu(s): 1
lscpu.cpu_family: 6
lscpu.cpu_op-mode(s): 32-bit, 64-bit
lscpu.flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer hypervisor lahf_lm pti ssbd ibrs ibpb stibp tsc_adjust arat flush_l1d arch_capabilities
lscpu.hypervisor_vendor: VMware
lscpu.l1d_cache: 32 KiB (1 instance)
lscpu.l1i_cache: 32 KiB (1 instance)
lscpu.l2_cache: 1 MiB (1 instance)
lscpu.l3_cache: 33 MiB (1 instance)
lscpu.model: 26
lscpu.model_name: Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz
lscpu.numa_node(s): 1
lscpu.numa_node0_cpu(s): 0
lscpu.on-line_cpu(s)_list: 0
lscpu.socket(s): 1
lscpu.stepping: 4
lscpu.thread(s)_per_core: 1
lscpu.vendor_id: GenuineIntel
lscpu.virtualization_type: full
lscpu.vulnerability_itlb_multihit: KVM: Mitigation: VMX unsupported
lscpu.vulnerability_l1tf: Mitigation; PTE Inversion
lscpu.vulnerability_mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
lscpu.vulnerability_meltdown: Mitigation; PTI
lscpu.vulnerability_spec_store_bypass: Mitigation; Speculative Store Bypass disabled via prctl
lscpu.vulnerability_spectre_v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
lscpu.vulnerability_spectre_v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP disabled, RSB filling
lscpu.vulnerability_srbds: Not affected
lscpu.vulnerability_tsx_async_abort: Not affected
memory.memtotal: 2013620
memory.swaptotal: 2097148
net.interface.ens192.ipv4_address: 10.150.74.109
net.interface.ens192.ipv4_address_list: 10.150.74.109
net.interface.ens192.ipv4_broadcast: 10.150.74.255
net.interface.ens192.ipv4_broadcast_list: 10.150.74.255
net.interface.ens192.ipv4_netmask: 24
net.interface.ens192.ipv4_netmask_list: 24
net.interface.ens192.mac_address: 00:50:56:bc:5c:1d
net.interface.lo.ipv4_address: 127.0.0.1
net.interface.lo.ipv4_address_list: 127.0.0.1
net.interface.lo.ipv4_broadcast: Unknown
net.interface.lo.ipv4_broadcast_list: Unknown
net.interface.lo.ipv4_netmask: 8
net.interface.lo.ipv4_netmask_list: 8
net.interface.lo.ipv6_address.host: ::1
net.interface.lo.ipv6_address.host_list: ::1
net.interface.lo.ipv6_netmask.host: 128
net.interface.lo.ipv6_netmask.host_list: 128
network.fqdn: audccfored09.au.harveynorman.com
network.hostname: audccfored09.au.harveynorman.com
network.ipv4_address: 10.150.74.109
network.ipv6_address: ::1
proc_cpuinfo.common.address_sizes: 43 bits physical, 48 bits virtual
proc_cpuinfo.common.apicid: 0
proc_cpuinfo.common.bogomips: 4190.15
proc_cpuinfo.common.bugs: cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
proc_cpuinfo.common.cache_alignment: 64
proc_cpuinfo.common.cache_size: 33792 KB
proc_cpuinfo.common.clflush_size: 64
proc_cpuinfo.common.core_id: 0
proc_cpuinfo.common.cpu_cores: 1
proc_cpuinfo.common.cpu_family: 6
proc_cpuinfo.common.cpu_mhz: 2095.078
proc_cpuinfo.common.cpuid_level: 11
proc_cpuinfo.common.flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer hypervisor lahf_lm pti ssbd ibrs ibpb stibp tsc_adjust arat flush_l1d arch_capabilities
proc_cpuinfo.common.fpu: yes
proc_cpuinfo.common.fpu_exception: yes
proc_cpuinfo.common.initial_apicid: 0
proc_cpuinfo.common.microcode: 0x2006a08
proc_cpuinfo.common.model: 26
proc_cpuinfo.common.model_name: Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz
proc_cpuinfo.common.physical_id: 0
proc_cpuinfo.common.power_management: Unknown
proc_cpuinfo.common.processor: 0
proc_cpuinfo.common.siblings: 1
proc_cpuinfo.common.stepping: 4
proc_cpuinfo.common.vendor_id: GenuineIntel
proc_cpuinfo.common.wp: yes
proc_stat.btime: 1654834813
system.certificate_version: 3.2
system.default_locale: en_AU.UTF-8
uname.machine: x86_64
uname.nodename: audccfored09.au.harveynorman.com
uname.release: 5.14.0-70.13.1.el9_0.x86_64
uname.sysname: Linux
uname.version: #1 SMP PREEMPT Thu Apr 14 12:42:38 EDT 2022
virt.host_type: vmware
virt.is_guest: True
[root@audccfored09 06-27 12:06:57 ~]# dmidecode | less
# dmidecode 3.3
Getting SMBIOS data from sysfs.
SMBIOS 2.7 present.
158 structures occupying 9705 bytes.
Table at 0x0DF8601F.
Handle 0x0000, DMI type 0, 26 bytes
BIOS Information
Vendor: VMware, Inc.
Version: VMW71.00V.13989454.B64.1906190538
Release Date: 06/19/2019
ROM Size: 2 MB
Characteristics:
ISA is supported
PCI is supported
PNP is supported
BIOS is upgradeable
Targeted content distribution is supported
UEFI is supported
Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: VMware, Inc.
Product Name: VMware7,1
Version: None
Serial Number: VMware-42 3c a8 81 4f df 56 21-9d dc e1 31 03 a9 3e 96
UUID: 81a83c42-df4f-2156-9ddc-e13103a93e96
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified
Handle 0x0002, DMI type 2, 15 bytes
Base Board Information
Manufacturer: Intel Corporation
Product Name: 440BX Desktop Reference Platform
Version: None
Serial Number: None
Asset Tag: Not Specified
Features: None
Location In Chassis: Not Specified
Chassis Handle: 0x0000
Type: Other
Contained Object Handles: 0
Handle 0x0003, DMI type 3, 21 bytes
Chassis Information
Manufacturer: No Enclosure
Type: Other
Lock: Not Present
Version: N/A
Serial Number: None
Asset Tag: No Asset Tag
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: Unspecified
Contained Elements: 0
Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: CPU 0
Type: Central Processor
Family: Unknown
Manufacturer: GenuineIntel
ID: A4 06 01 00 FF FB 8B 0F
Version: Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz
Voltage: 3.3 V
External Clock: Unknown
Max Speed: 1998 MHz
Current Speed: 1998 MHz
Status: Populated, Enabled
Upgrade: ZIF Socket
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Core Count: 1
Core Enabled: 1
Characteristics:
64-bit capable
Execute Protection
Handle 0x0005, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J19
Internal Connector Type: 9 Pin Dual Inline (pin 10 cut)
External Reference Designator: COM 1
External Connector Type: DB-9 male
Port Type: Serial Port 16550A Compatible
Handle 0x0006, DMI type 8, 9 bytes
Port Connector Information
Internal Reference Designator: J23
Internal Connector Type: 25 Pin Dual Inline (pin 26 cut)
External Reference Designator: Parallel
Serial Number: None
Asset Tag: No Asset Tag
Boot-up State: Safe
Power Supply State: Safe
Thermal State: Safe
Security Status: None
OEM Information: 0x00000000
Height: Unspecified
Number Of Power Cords: Unspecified
Contained Elements: 0
Handle 0x0004, DMI type 4, 48 bytes
Processor Information
Socket Designation: CPU 0
Type: Central Processor
Family: Unknown
Manufacturer: GenuineIntel
ID: A4 06 01 00 FF FB 8B 0F
Version: Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz
Voltage: 3.3 V
External Clock: Unknown
Max Speed: 1998 MHz
Current Speed: 1998 MHz
Status: Populated, Enabled
Upgrade: ZIF Socket
L1 Cache Handle: Not Provided
L2 Cache Handle: Not Provided
L3 Cache Handle: Not Provided
Serial Number: Not Specified
Asset Tag: Not Specified
Part Number: Not Specified
Core Count: 1
Core Enabled: 1
Characteristics:
64-bit capable
Execute Protection
[snip]
more dmidecode output follows. I will attach full output as a file, shortly.
Environment is: vSphere Client version 7.0.3.00500 ESX hosts are ESXi version 6.7.0 On el9 host: dmidecode-3.3-7.el9.x86_64 python3-dmidecode-3.12.2-27.el9.x86_64 [root@audccfored09 06-27 15:41:17 ~]# rpm -qa | grep subscription-manager | sort libdnf-plugin-subscription-manager-1.29.26-3.el9_0.x86_64 python3-subscription-manager-rhsm-1.29.26-3.el9_0.x86_64 subscription-manager-1.29.26-3.el9_0.x86_64 subscription-manager-cockpit-1.29.26-3.el9_0.noarch subscription-manager-rhsm-certificates-1.29.26-3.el9_0.x86_64 Created attachment 1892866 [details]
dmidecode from vm on which subscription-manager fails to get UUID.
Just to clarify, the VMWare (VSphere) environment is: Version: 7.0.3 Build: 19480866 And the ESX hosts are ESXi version 6.7.0 Now, we have 2 datacenters, both running exact same VSphere and ESXi, and i have an EL9 VM at each DC. Both VMs have exact same rpms installed: [root@audccfored09 06-27 17:27:41 z_admin]# diff rpm.all.cfored09.txt rpm.all.ultred09.txt [root@audccfored09 06-27 17:27:52 z_admin]# Both have exact same results from dmidecode, apart from some very minor, irrelevant details: [root@audccfored09 06-27 17:37:26 z_admin]# diff dmidecode.cfored09.txt dmidecode.ultred09.txt 26,27c26,27 < Serial Number: VMware-42 3c a8 81 4f df 56 21-9d dc e1 31 03 a9 3e 96 < UUID: 81a83c42-df4f-2156-9ddc-e13103a93e96 --- > Serial Number: VMware-42 14 ee f7 51 35 2f f2-0f b8 13 21 08 84 3c 1a > UUID: f7ee1442-3551-f22f-0fb8-132108843c1a 238c238 < Maximum Capacity: 2 GB --- > Maximum Capacity: 5 GB 248c248 < Size: 2 GB --- > Size: 4 GB 259c259 < Part Number: VMW-2048MB --- > Part Number: VMW-4096MB [root@audccfored09 06-27 17:37:38 z_admin]# And yet: 1) ONE of these VMs subscription manager finds the UUID, and can subscribe to a VDC license. 2) while on the other, subscription-manager, despite repeated attempts to clean and re-register, never manages to collect a UUID, and so we cannot subscribe to a license. Please advise if there's any other info you need, I'll be happy to supply if Ramesh is busy. It is pretty clear that there is something very stupid going in inside subscription-manager, because it works fine on one VM and fails on another - with both in exact same environment, and with both having the same good info from dmidecode. There is no reason why subscription-manager should have any trouble getting UUID from dmidecode - the info is right there, staring it in the face, so this is a real problem. AH. I thought i should double-check the problem VM did have secure boot disabled... and turns out I was mistaken, earlier. Secure boot was off on the VM that gets uuid successfully, but it was ON, for the problem VM. I have now disabled secure boot in the VMware options for problem VM, and registered again, and now it DOES register with UUID. [root@audccfored09 06-27 18:08:56 ~]# subscription-manager facts | grep -i uuid dmi.system.uuid: 81A83C42-DF4F-2156-9DDC-E13103A93E96 virt.uuid: 81A83C42-DF4F-2156-9DDC-E13103A93E96 So the bug report title is correct, this problem is related to the secure boot, and, probably the python-dmidecode package failing to get info from /dev/mem, if secure boot tightens that up a bit. I note the actual file permissions on /dev/mem have not changed since disabling secure boot, but perhaps there is more to it than the file permissions. Subscription/manager and/or python-dmidecode needs to be fixed ASAP, to get the UUID properly. dmidecode successfully gets the info, so use that if necessary. I look forward to a fix ASAP. Thanks. Hi John, indeed, my explanation was added as private comment, as it contained customer details, and I forgot to split it into public and private parts. Let me write the public explanation for this. ================================= Something I found while looking for a similar error message is that the guest uses EFI with Secure Boot (SB) enabled. Indeed, trying a RHEL 9.0 guest with EFI+SB on both ESX 6.7 and QEMU (on Fedora 36) shows the same problem reported. A bit more details: on a system with EFI+SB, a kernel feature called Kernel Lockdown is automatically enabled: https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html Among the various features that are disabled or restricted, there is the direct reading of the kernel memory, i.e. what the special device /dev/mem exposes. Guess what, reading from /dev/mem is exactly what the python-dmidecode library does to read the DMI information. However, dmidecode(1) works just fine, as it uses different ways to read the DMI bits (i.e. it uses the various efi-related bits in sysfs). python-dmidecode [1] seems pretty dead at the time of this writing, and it does not seem that there are good alternatives (active projects with a compatible license with GPLv2-only). This means that the only way to sanely fix this is to stop using python-dmidecode and write our parser of the dmidecode(1) output... One more thing I got when testing on ESX 6.7: when creating a new guest with the OS information set as Linux + RHEL 8, among the default boot values EFI and SB are automatically enabled; this means that, unless users/sysadmins manually change the firmware or disable SB, they will get a RHEL VM with EFI+SB. >> Pre-verification testing against RHEL 9.0 GA with subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64: [root@r90secureboot ~]# mokutil --sb-state SecureBoot enabled [root@r90secureboot ~]# rpm -q subscription-manager subscription-manager-1.29.26-3.el9_0.x86_64 [root@r90secureboot ~]# subscription-manager facts > sb.old [root@r90secureboot ~]# yum update subscription-manager Updating Subscription Management repositories. Last metadata expiration check: 0:02:51 ago on Mon 27 Jun 2022 12:25:33 PM EDT. Dependencies resolved. ==================================================================================================================================================================================================================== Package Architecture Version Repository Size ==================================================================================================================================================================================================================== Upgrading: libdnf-plugin-subscription-manager x86_64 1.29.28-1.git.22.617048e.el9 brew-task-repo-subscription-manager-1.29.28-1.git.22.617048e.el9-scratch 82 k python3-cloud-what x86_64 1.29.28-1.git.22.617048e.el9 brew-task-repo-subscription-manager-1.29.28-1.git.22.617048e.el9-scratch 91 k python3-subscription-manager-rhsm x86_64 1.29.28-1.git.22.617048e.el9 brew-task-repo-subscription-manager-1.29.28-1.git.22.617048e.el9-scratch 166 k subscription-manager x86_64 1.29.28-1.git.22.617048e.el9 brew-task-repo-subscription-manager-1.29.28-1.git.22.617048e.el9-scratch 768 k subscription-manager-plugin-ostree x86_64 1.29.28-1.git.22.617048e.el9 brew-task-repo-subscription-manager-1.29.28-1.git.22.617048e.el9-scratch 76 k Transaction Summary ==================================================================================================================================================================================================================== Upgrade 5 Packages Total download size: 1.2 M Is this ok [y/N]: y Downloading Packages: (1/5): libdnf-plugin-subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64.rpm 204 kB/s | 82 kB 00:00 (2/5): python3-cloud-what-1.29.28-1.git.22.617048e.el9.x86_64.rpm 188 kB/s | 91 kB 00:00 (3/5): python3-subscription-manager-rhsm-1.29.28-1.git.22.617048e.el9.x86_64.rpm 262 kB/s | 166 kB 00:00 (4/5): subscription-manager-plugin-ostree-1.29.28-1.git.22.617048e.el9.x86_64.rpm 296 kB/s | 76 kB 00:00 (5/5): subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64.rpm 1.6 MB/s | 768 kB 00:00 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 1.3 MB/s | 1.2 MB 00:00 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing : 1/1 Upgrading : python3-cloud-what-1.29.28-1.git.22.617048e.el9.x86_64 1/10 Upgrading : python3-subscription-manager-rhsm-1.29.28-1.git.22.617048e.el9.x86_64 2/10 Upgrading : libdnf-plugin-subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 3/10 Running scriptlet: subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 4/10 Upgrading : subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 4/10 warning: /etc/rhsm/rhsm.conf created as /etc/rhsm/rhsm.conf.rpmnew Running scriptlet: subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 4/10 Upgrading : subscription-manager-plugin-ostree-1.29.28-1.git.22.617048e.el9.x86_64 5/10 Cleanup : subscription-manager-plugin-ostree-1.29.26-3.el9_0.x86_64 6/10 Running scriptlet: subscription-manager-1.29.26-3.el9_0.x86_64 7/10 Cleanup : subscription-manager-1.29.26-3.el9_0.x86_64 7/10 Running scriptlet: subscription-manager-1.29.26-3.el9_0.x86_64 7/10 Cleanup : python3-subscription-manager-rhsm-1.29.26-3.el9_0.x86_64 8/10 Cleanup : python3-cloud-what-1.29.26-3.el9_0.x86_64 9/10 Cleanup : libdnf-plugin-subscription-manager-1.29.26-3.el9_0.x86_64 10/10 Running scriptlet: subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 10/10 Running scriptlet: libdnf-plugin-subscription-manager-1.29.26-3.el9_0.x86_64 10/10 Verifying : libdnf-plugin-subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 1/10 Verifying : libdnf-plugin-subscription-manager-1.29.26-3.el9_0.x86_64 2/10 Verifying : python3-cloud-what-1.29.28-1.git.22.617048e.el9.x86_64 3/10 Verifying : python3-cloud-what-1.29.26-3.el9_0.x86_64 4/10 Verifying : python3-subscription-manager-rhsm-1.29.28-1.git.22.617048e.el9.x86_64 5/10 Verifying : python3-subscription-manager-rhsm-1.29.26-3.el9_0.x86_64 6/10 Verifying : subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 7/10 Verifying : subscription-manager-1.29.26-3.el9_0.x86_64 8/10 Verifying : subscription-manager-plugin-ostree-1.29.28-1.git.22.617048e.el9.x86_64 9/10 Verifying : subscription-manager-plugin-ostree-1.29.26-3.el9_0.x86_64 10/10 Installed products updated. Upgraded: libdnf-plugin-subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 python3-cloud-what-1.29.28-1.git.22.617048e.el9.x86_64 python3-subscription-manager-rhsm-1.29.28-1.git.22.617048e.el9.x86_64 subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 subscription-manager-plugin-ostree-1.29.28-1.git.22.617048e.el9.x86_64 Complete! [root@r90secureboot ~]# subscription-manager facts > sb.new [root@r90secureboot ~]# rpm -q subscription-manager subscription-manager-1.29.28-1.git.22.617048e.el9.x86_64 [root@r90secureboot ~]# diff sb.old sb.new 9a10,62 > dmi.bios.address: 0xe8000 > dmi.bios.bios_revision: 0.0 > dmi.bios.release_date: 02/06/2015 > dmi.bios.rom_size: 64 kB > dmi.bios.runtime_size: 96 kB > dmi.bios.vendor: EFI Development Kit II / OVMF > dmi.bios.version: 0.0.0 > dmi.chassis.boot-up_state: Safe > dmi.chassis.contained_elements: 0 > dmi.chassis.lock: Not Present > dmi.chassis.manufacturer: QEMU > dmi.chassis.oem_information: 0x00000000 > dmi.chassis.power_supply_state: Safe > dmi.chassis.thermal_state: Safe > dmi.chassis.type: Other > dmi.chassis.version: pc-q35-6.2 > dmi.memory.array_handle: 0x1000 > dmi.memory.error_correction_type: Multi-bit ECC > dmi.memory.error_information_handle: Not Provided > dmi.memory.form_factor: DIMM > dmi.memory.location: Other > dmi.memory.locator: DIMM 0 > dmi.memory.manufacturer: QEMU > dmi.memory.maximum_capacity: 4 GB > dmi.memory.number_of_devices: 1 > dmi.memory.set: None > dmi.memory.size: 4 GB > dmi.memory.type: RAM > dmi.memory.type_detail: Other > dmi.memory.use: System Memory > dmi.meta.cpu_socket_count: 4 > dmi.processor.characteristics: None > dmi.processor.core_count: 1 > dmi.processor.core_enabled: 1 > dmi.processor.current_speed: 2000 MHz > dmi.processor.family: Other > dmi.processor.id: A6 06 06 00 FF FB 8B 0F > dmi.processor.l1_cache_handle: Not Provided > dmi.processor.l2_cache_handle: Not Provided > dmi.processor.l3_cache_handle: Not Provided > dmi.processor.manufacturer: QEMU > dmi.processor.max_speed: 2000 MHz > dmi.processor.socket_designation: CPU 3 > dmi.processor.status: Populated, Enabled > dmi.processor.thread_count: 1 > dmi.processor.type: Central Processor > dmi.processor.upgrade: Other > dmi.processor.version: pc-q35-6.2 > dmi.system.manufacturer: QEMU > dmi.system.product_name: Standard PC (Q35 + ICH9, 2009) > dmi.system.uuid: C443F5AE-DED1-46C7-860E-D688795DDFC8 > dmi.system.version: pc-q35-6.2 > dmi.system.wake-up_type: Power Switch 89c142 < network.ipv6_address: fe80::5054:ff:fece:84c3, 2620:52:0:800:5054:ff:fece:84c3, fe80::c813:bff:fe4c:fa50 --- > network.ipv6_address: 2620:52:0:800:5054:ff:fece:84c3, fe80::c813:bff:fe4c:fa50, fe80::5054:ff:fece:84c3 122a176 > virt.uuid: C443F5AE-DED1-46C7-860E-D688795DDFC8 >> sb.old are facts output from before updating subman, sb.new is after installing the scratch. >> The diff shows that we are now capturing a lot of dmi.* info, including .system.uuid and therefore virt.uuid is present. >> Only other difference seen, which may be relevant to another discussion is the layout/ordering of those ipv6 addrs. >> Checking output of counts: [root@r90secureboot ~]# subscription-manager facts | grep -ie socket -e core -e thread cpu.core(s)_per_socket: 1 cpu.cpu_socket(s): 4 cpu.thread(s)_per_core: 1 dmi.meta.cpu_socket_count: 4 dmi.processor.core_count: 1 dmi.processor.core_enabled: 1 dmi.processor.socket_designation: CPU 3 dmi.processor.thread_count: 1 lscpu.core(s)_per_socket: 1 lscpu.socket(s): 4 lscpu.thread(s)_per_core: 1 proc_cpuinfo.common.core_id: 0 proc_cpuinfo.common.cpu_cores: 1 >> All of these counts are accurate based on selection (socket_designation / core_id), and configuration of this vm (4 socket, 1 core, 1 thread) >> Continuing testing against a non-secure-boot VM (non-UEFI, BIOS BOOT), same procedure followed - gathered facts before update to scratch and compared to facts after update: >> nb.old are facts with 9.0 GA subman, nb.new from scratch. [root@r9normalboothw ~]# diff nb.old nb.new 13,14c13,14 < dmi.bios.rom_size: 64 KB < dmi.bios.runtime_size: 96 KB --- > dmi.bios.rom_size: 64 kB > dmi.bios.runtime_size: 96 kB 17d16 < dmi.chassis.asset_tag: Unknown 18a18 > dmi.chassis.contained_elements: 0 20a21 > dmi.chassis.oem_information: 0x00000000 22,23d22 < dmi.chassis.security_status: Unknown < dmi.chassis.serial_number: Unknown 28,30d26 < dmi.memory.assettag: Unknown < dmi.memory.bank_locator: Unknown < dmi.memory.data_width: Unknown 38,42c34,36 < dmi.memory.part_number: Unknown < dmi.memory.serial_number: Unknown < dmi.memory.size: 4096 MB < dmi.memory.speed: (ns) < dmi.memory.total_width: Unknown --- > dmi.memory.number_of_devices: 1 > dmi.memory.set: None > dmi.memory.size: 4 GB 43a38 > dmi.memory.type_detail: Other 46c41,44 < dmi.processor.asset_tag: Unknown --- > dmi.processor.characteristics: None > dmi.processor.core_count: 1 > dmi.processor.core_enabled: 1 > dmi.processor.current_speed: 2000 MHz 48,49c46,51 < dmi.processor.part_number: Unknown < dmi.processor.serial_number: Unknown --- > dmi.processor.id: A6 06 06 00 FF FB 8B 0F > dmi.processor.l1_cache_handle: Not Provided > dmi.processor.l2_cache_handle: Not Provided > dmi.processor.l3_cache_handle: Not Provided > dmi.processor.manufacturer: QEMU > dmi.processor.max_speed: 2000 MHz 51c53,54 < dmi.processor.status: Populated:Enabled --- > dmi.processor.status: Populated, Enabled > dmi.processor.thread_count: 1 55,56d57 < dmi.processor.voltage: Unknown < dmi.system.family: Unknown 59,61d59 < dmi.system.serial_number: Unknown < dmi.system.sku_number: Unknown < dmi.system.status: No errors detected >> Some fact differences here are related to getting data using the new verison of SMBIOS (3.3), which was not the case of python3-dmidecode implementation. >> Some differences are simply because of case, for instance: KB vs kB >> Additional difference that was added to code this go around was to hide facts that did not provide values from dmi.* items, for instance ones returning 'Unknown' are hidden. >> One quick additional check here is to check the differences between the new versions reported facts between secure boot and non-sb systems: >> (Took the keys only from the facts output of each system and diff) [root@r90secureboot ~]# diff sb.keys.new nb.keys.new 63d62 < insights_id 103,113d101 < net.interface.cni-podman0.ipv4_address < net.interface.cni-podman0.ipv4_address_list < net.interface.cni-podman0.ipv4_broadcast < net.interface.cni-podman0.ipv4_broadcast_list < net.interface.cni-podman0.ipv4_netmask < net.interface.cni-podman0.ipv4_netmask_list < net.interface.cni-podman0.ipv6_address.link < net.interface.cni-podman0.ipv6_address.link_list < net.interface.cni-podman0.ipv6_netmask.link < net.interface.cni-podman0.ipv6_netmask.link_list < net.interface.cni-podman0.mac_address >> As we can see, no differences except for a different interface on one host, and having reference to insights_id - both of which are unrelated to this change (and are the direct result of a test-run against this host, otherwise there would be no diff at all). >> This result is the same for a UEFI BOOT system that has Secure Boot disabled. >> LGTM. Ah great work, ty Pino & Craig, i look fwd to the fix making its way into el9! Cheers & regards, John *** Bug 2100759 has been marked as a duplicate of this bug. *** *** Bug 2111873 has been marked as a duplicate of this bug. *** I confirm - disabling secureboot on a virtual machine with RHEL9 installed (without virt-who) solves the problem with automatic attaching of subscription in RHSM. Reports to RHSM are sent from a different host with virt-who (on RHEL8.6) installed. the VMWare (VSphere and ESXi) environment: Version: 7.0.3 subscription-manager-1.29.26-3.el9_0.x86_64 Virt-who is installed on RHEL8.6 with secureboot enabled on VM. *** Bug 2115224 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (subscription-manager bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:8341 |