Current x86-64 microarchitecture is unsupported even though all flags are present #1182

cseres3 · 2024-02-19T14:45:11Z

Actual behavior
I am trying to upgrade from AlmaLinux8 to AlmaLinux9 using elevate-ng. Preupgrade gives me inhibitor "Current x86-64 microarchitecture is unsupported in RHEL9", "Missings flags detected are: cmov, cx8, fpu, fxsr, mmx, syscall, sse, sse2, cx16, lahf_lm, popcnt, pni, sse4_1, sse4_2, ssse3". However cat /proc/cpuinfo lists all of them and I have successfully upgraded another VM in the same Proxmox VE virtualization environment.

# cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 85 model name : Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz stepping : 7 microcode : 0x5003302 cpu MHz : 2194.842 cache size : 16384 KB physical id : 0 siblings : 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 22 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat umip pku ospke avx512_vnni md_clear arch_capabilities bugs : spectre_v1 spectre_v2 spec_store_bypass swapgs taa mmio_stale_data retbleed eibrs_pbrsb gds bogomips : 4389.68 clflush size : 64 cache_alignment : 64 address sizes : 46 bits physical, 48 bits virtual power management:

To Reproduce
Steps to reproduce the behavior

sudo curl -o /etc/yum.repos.d/elevate-ng.repo https://repo.almalinux.org/elevate/testing/elevate-ng-el$(rpm -E %rhel).repo
sudo rpm --import https://repo.almalinux.org/elevate/RPM-GPG-KEY-ELevate
sudo yum install -y leapp-upgrade leapp-data-almalinux
sudo leapp preupgrade --debug
Output contains "Upgrade has been inhibited due to the following problems:
1. Current x86-64 microarchitecture is unsupported in RHEL9"

Expected behavior
Preupgrade should success, because CPU Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz is supported for RHEL9.

System information:

OS and version: AlmaLinux release 8.9 (Midnight Oncilla)
Linux finlaysoninsaa.fi 4.18.0-513.11.1.el8_9.x86_64 #1 SMP Wed Jan 17 02:00:40 EST 2024 x86_64 x86_64 x86_64 GNU/Linux

rpm -qa "leapp"

python3-leapp-0.16.0-2.el8.noarch
leapp-data-almalinux-0.2-6.el8.noarch
leapp-upgrade-el8toel9-deps-0.19.0-5.el8.noarch
leapp-0.16.0-2.el8.noarch
leapp-deps-0.16.0-2.el8.noarch
leapp-upgrade-el8toel9-0.19.0-5.el8.noarch

Log files attached:

All files in /var/log/leapp
/var/lib/leapp/leapp.db

leapp-logs.tar.gz

Additional context
The processor type for this VM is set to 'host' in Proxmox VE. In the other VM which I successfully upgraded using leapp, this solved the microarchitecture error.

The text was updated successfully, but these errors were encountered:

pirat89 · 2024-02-19T18:28:03Z

Hi @cseres3. Thank you for the report and provided data. I checked the data and I can confirm it's really bug in the scancpu actor.

$ leapp-inspector messages --recursive-expand --type CPUInfo 
######################################################################
                          PRODUCED MESSAGES                           
######################################################################
Stamp: 2024-02-19T14:05:32.401736Z
Actor: scancpu
Phase: FactsCollection
Type: CPUInfo
Message_data:
{
    "flags": [],
    "machine_type": null
}
######################################################################

while the original lscpu output has been in your case this:

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):           1
NUMA node(s):        2
Vendor ID:           GenuineIntel
BIOS Vendor ID:      QEMU
CPU family:          6
Model:               85
Model name:          Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz
BIOS Model name:     pc-i440fx-7.2
Stepping:            7
CPU MHz:             2194.842
BogoMIPS:            4389.68
Virtualization:      VT-x
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            4096K
L3 cache:            16384K
NUMA node0 CPU(s):   0
NUMA node1 CPU(s):   
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat umip pku ospke avx512_vnni md_clear arch_capabilities

See that for the NUMA node1 CPU(s) key there is empty. Current code in scancpu actor expects that each key has also value. The parsed output than looks like this:

{'Architecture': 'x86_64',
 'BIOS Model name': 'pc-i440fx-7.2',
 'BIOS Vendor ID': 'QEMU',
 'BogoMIPS': '4389.68',
 'Byte Order': 'Little Endian',
 'CPU MHz': '2194.842',
 'CPU family': '6',
 'CPU op-mode(s)': '32-bit, 64-bit',
 'CPU(s)': '1',
 'Core(s) per socket': '1',
 'Hypervisor vendor': 'KVM',
 'L1d cache': '32K',
 'L1i cache': '32K',
 'L2 cache': '4096K',
 'L3 cache': '16384K',
 'Model': '85',
 'Model name': 'Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz',
 'NUMA node(s)': '2',
 'NUMA node0 CPU(s)': '0',
 'NUMA node1 CPU(s)': 'Flags:               fpu vme de pse tsc msr pae mce cx8 '
                      'apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr '
                      'sse sse2 ss ht syscall nx pdpe1gb rdtscp lm '
                      'constant_tsc arch_perfmon rep_good nopl xtopology cpuid '
                      'tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm '
                      'pcid sse4_1 sse4_2 x2apic movbe popcnt '
                      'tsc_deadline_timer aes xsave avx f16c rdrand hypervisor '
                      'lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single '
                      'ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi '
                      'flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 '
                      'avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed '
                      'adx smap clflushopt clwb avx512cd avx512bw avx512vl '
                      'xsaveopt xsavec xgetbv1 xsaves arat umip pku ospke '
                      'avx512_vnni md_clear arch_capabilities',
 'On-line CPU(s) list': '0',
 'Socket(s)': '1',
 'Stepping': '7',
 'Thread(s) per core': '1',
 'Vendor ID': 'GenuineIntel',
 'Virtualization': 'VT-x',
 'Virtualization type': 'full'}

The problematic code is here:

leapp-repository/repos/system_upgrade/common/actors/scancpu/libraries/scancpu.py

Line 141 in 6421225

lscpu = dict(LSCPU_NAME_VALUE.findall(_get_lscpu_output()))

pirat89 · 2024-02-19T19:31:33Z

Playing a little bit around:

(Pdb) from pprint import pprint as pp
(Pdb) myls = _get_lscpu_output()
(Pdb) pp(dict(re.findall(r'(?P<name>[^:]+):[ \t]+(?P<value>.*)\n', myls)))
{'Architecture': 'x86_64',
 'BIOS Model name': 'pc-i440fx-7.2',
 'BIOS Vendor ID': 'QEMU',
 'BogoMIPS': '4389.68',
 'Byte Order': 'Little Endian',
 'CPU MHz': '2194.842',
 'CPU family': '6',
 'CPU op-mode(s)': '32-bit, 64-bit',
 'CPU(s)': '1',
 'Core(s) per socket': '1',
 'Flags': 'fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat '
          'pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm '
          'constant_tsc arch_perfmon rep_good nopl xtopology cpuid '
          'tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 '
          'sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c '
          'rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault '
          'invpcid_single ssbd ibrs ibpb stibp ibrs_enhanced tpr_shadow vnmi '
          'flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep '
          'bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt '
          'clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves arat '
          'umip pku ospke avx512_vnni md_clear arch_capabilities',
 'Hypervisor vendor': 'KVM',
 'L1d cache': '32K',
 'L1i cache': '32K',
 'L2 cache': '4096K',
 'L3 cache': '16384K',
 'Model': '85',
 'Model name': 'Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz',
 'NUMA node(s)': '2',
 'NUMA node0 CPU(s)': '0',
 'NUMA node1 CPU(s)': '',
 'On-line CPU(s) list': '0',
 'Socket(s)': '1',
 'Stepping': '7',
 'Thread(s) per core': '1',
 'Vendor ID': 'GenuineIntel',
 'Virtualization': 'VT-x',
 'Virtualization type': 'full'}

I haven't checked the kernel code generating the /proc/cpuinfo file whether it's safe or not to do it in this way. If we are sure that there is not a multiline value for any field, it should be ok.

cseres3 · 2024-02-19T21:54:51Z

Thank you for finding the problematic code!
I just noticed that lscpu in EL8 (from util-linux-2.32.1-43.el8.x86_64) also supports json output with option -J which could be easier to parse. Unfortunately the same switch does not seem to work in EL7 even though man page lists -J there as well in synopsis.

pirat89 · 2024-02-20T11:38:04Z

@cseres3 yeah, it's unfortunate it's not on EL7, as I found that yesterday also :D it was very short happy moment. but for future I definitely vote to consume the json output instead of manual parsing.

Fixes oamg#1182

Original solution expected always ``key: val`` pair on each line. However, it has not been expected that val could be actually empty string, which would lead to situation where the following line is interpreted as a value. The new solution updates the parsing for output on RHEL 7, but also calls newly ``lscpu -J`` on RHEL 8+ to obtain data in the JSON format, which drops all possible parsing problems from our side. Fixes oamg#1182

fernflower · 2024-03-01T11:53:50Z

@cseres3 hi, we have a fix ready. Could you please check that it solves your issue?

cseres3 · 2024-03-01T11:59:10Z

Sure, I can test it gladly. What should I do to get the fixed version?

fernflower · 2024-03-01T12:04:07Z

Probably the easiest way is to install leapp-repository build that contains the fix https://copr.fedorainfracloud.org/coprs/g/oamg/leapp/build/7046991/
Alternatively you could manually apply the patch #1184

cseres3 · 2024-03-01T13:46:20Z

Hi,
sorry I have practically never used copr repositories, can you give exact comands how to enable that repository/build?

fernflower · 2024-03-01T13:52:26Z

Sure! Something like this will install you the recent version of leapp-repository PR1184 .

curl https://copr.fedorainfracloud.org/coprs/g/oamg/leapp/repo/epel-8/group_oamg-leapp-epel-8.repo --output /etc/yum.repos.d/copr_build.repo
yum install -y leapp-upgrade*pr1184*

cseres3 · 2024-03-01T14:10:43Z

Thanks a lot!
I guess I am missing some package as I get the following error:
2024-03-01 15:44:14.041108 [ERROR] Actor: distribution_signed_rpm_scanner Message: Cannot find distribution signature configuration. Summary: Problem: Distribution almalinux was not found in /etc/leapp/repos.d/system_upgrade/common/files/distro. 2024-03-01 15:44:19.827011 [ERROR] Actor: scan_source_kernel Message: Unable to identify package providing the booted kernel.

# rpm -qa|grep leapp
leapp-upgrade-el8toel9-0.20.0-0.20240221191305021533.pr1184.3.g50f4b081.el8.noarch
leapp-deps-0.17.0-100.20240213170309274358.master.0.g1c9e2ee.el8.noarch
python3-leapp-0.17.0-100.20240213170309274358.master.0.g1c9e2ee.el8.noarch
leapp-upgrade-el8toel9-deps-0.20.0-0.20240221191305021533.pr1184.3.g50f4b081.el8.noarch
leapp-0.17.0-100.20240213170309274358.master.0.g1c9e2ee.el8.noarch

fernflower · 2024-03-01T14:16:47Z

Sorry, Friday vibes - I was so eager to tell how to get leapp bits installed that completely forgot that your issue was not with rhel upgrades with leapp but with alma upgrades with elevate :)
Not an expert here, but I believe to test it you would need to patch the elevate code manually by applying fixes from the PR. @pirat89 if there is an easier way - please tell us.

pirat89 · 2024-03-01T23:44:29Z

@cseres3 : @fernflower is right. In case you want to upgrade Almlinux, you need to apply the patch in the elevate project. Fixing that one particular actor on your machine locally, seems like most simple way right now.

cseres3 · 2024-03-05T10:03:00Z

I was able to patch the file scancpu.py manually (Hunk #2 failed for some reason, but I modified those few lines manually). I can confim that the false inhibitor is now gone and the fix seems to work. Thank you again!

pirat89 · 2024-03-05T11:19:37Z

Thank you for the feedback. We will close the issue once we merge it.

Original solution expected always ``key: val`` pair on each line. However, it has not been expected that val could be actually empty string, which would lead to situation where the following line is interpreted as a value. The new solution updates the parsing for output on RHEL 7, but also calls newly ``lscpu -J`` on RHEL 8+ to obtain data in the JSON format, which drops all possible parsing problems from our side. Fixes #1182

Original solution expected always ``key: val`` pair on each line. However, it has not been expected that val could be actually empty string, which would lead to situation where the following line is interpreted as a value. The new solution updates the parsing for output on RHEL 7, but also calls newly ``lscpu -J`` on RHEL 8+ to obtain data in the JSON format, which drops all possible parsing problems from our side. Fixes oamg#1182 (cherry picked from commit 050620e)

cseres3 added the bug Something isn't working label Feb 19, 2024

dkubek added a commit to dkubek/leapp-repository that referenced this issue Feb 20, 2024

Fix incorrect lscpu parsing

9373e63

Fixes oamg#1182

dkubek mentioned this issue Feb 20, 2024

Fix incorrect lscpu parsing #1184

Merged

dkubek added a commit to dkubek/leapp-repository that referenced this issue Feb 21, 2024

Fix incorrect lscpu parsing

05ba55e

Fixes oamg#1182

pirat89 closed this as completed in #1184 Mar 18, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Current x86-64 microarchitecture is unsupported even though all flags are present #1182

Current x86-64 microarchitecture is unsupported even though all flags are present #1182

cseres3 commented Feb 19, 2024

pirat89 commented Feb 19, 2024

pirat89 commented Feb 19, 2024 •

edited

Loading

cseres3 commented Feb 19, 2024

pirat89 commented Feb 20, 2024

fernflower commented Mar 1, 2024 •

edited

Loading

cseres3 commented Mar 1, 2024

fernflower commented Mar 1, 2024

cseres3 commented Mar 1, 2024

fernflower commented Mar 1, 2024

cseres3 commented Mar 1, 2024

fernflower commented Mar 1, 2024 •

edited

Loading

pirat89 commented Mar 1, 2024

cseres3 commented Mar 5, 2024

pirat89 commented Mar 5, 2024

Current x86-64 microarchitecture is unsupported even though all flags are present #1182

Current x86-64 microarchitecture is unsupported even though all flags are present #1182

Comments

cseres3 commented Feb 19, 2024

rpm -qa "leapp"

pirat89 commented Feb 19, 2024

pirat89 commented Feb 19, 2024 • edited Loading

cseres3 commented Feb 19, 2024

pirat89 commented Feb 20, 2024

fernflower commented Mar 1, 2024 • edited Loading

cseres3 commented Mar 1, 2024

fernflower commented Mar 1, 2024

cseres3 commented Mar 1, 2024

fernflower commented Mar 1, 2024

cseres3 commented Mar 1, 2024

fernflower commented Mar 1, 2024 • edited Loading

pirat89 commented Mar 1, 2024

cseres3 commented Mar 5, 2024

pirat89 commented Mar 5, 2024

pirat89 commented Feb 19, 2024 •

edited

Loading

fernflower commented Mar 1, 2024 •

edited

Loading

fernflower commented Mar 1, 2024 •

edited

Loading