traefik / whoami

Tiny Go server that prints os information and HTTP request to output

Home Page:https://traefik.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Cannot Run with Xeon Processor

mathmaniac43 opened this issue · comments

commented

Hello,

I have recently put together a used Linux PC with an old Intel Xeon processor. I am planning to migrate some Dockerized home services (including traefik, as well as whoami as a sanity check) currently running on an i7 desktop to this new server machine.

I was surprised that I ran into problems getting my Docker containers to run on the new machine. traefik fired up and seems to run with no problem (web API is good), but whoami is giving me an error message.

XXX@YYYYYYYYYY:~$ docker run containous/whoami:v1.5.0-amd64
standard_init_linux.go:228: exec user process caused: exec format error
XXX@YYYYYYYYYY:~$ lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   36 bits physical, 48 bits virtual
CPU(s):                          8
On-line CPU(s) list:             0-7
Thread(s) per core:              2
Core(s) per socket:              4
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       GenuineIntel
CPU family:                      6
Model:                           58
Model name:                      Intel(R) Xeon(R) CPU E3-1265L V2 @ 2.50GHz
Stepping:                        9
CPU MHz:                         1600.128
CPU max MHz:                     3500.0000
CPU min MHz:                     1600.0000
BogoMIPS:                        4999.91
Virtualization:                  VT-x
L1d cache:                       128 KiB
L1i cache:                       128 KiB
L2 cache:                        1 MiB
L3 cache:                        8 MiB
NUMA node0 CPU(s):               0-7
Vulnerability Itlb multihit:     KVM: Mitigation: Split huge pages
Vulnerability L1tf:              Mitigation; PTE Inversion; VMX conditional c
                                 ache flushes, SMT vulnerable
Vulnerability Mds:               Mitigation; Clear CPU buffers; SMT vulnerabl
                                 e
Vulnerability Meltdown:          Mitigation; PTI
Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disable
                                 d via prctl and seccomp
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __u
                                 ser pointer sanitization
Vulnerability Spectre v2:        Mitigation; Full generic retpoline, IBPB con
                                 ditional, IBRS_FW, STIBP conditional, RSB fi
                                 lling
Vulnerability Srbds:             Vulnerable: No microcode
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu vme de pse tsc msr pae mce cx8 apic sep 
                                 mtrr pge mca cmov pat pse36 clflush dts acpi
                                  mmx fxsr sse sse2 ss ht tm pbe syscall nx r
                                 dtscp lm constant_tsc arch_perfmon pebs bts 
                                 rep_good nopl xtopology nonstop_tsc cpuid ap
                                 erfmperf pni pclmulqdq dtes64 monitor ds_cpl
                                  vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid s
                                 se4_1 sse4_2 x2apic popcnt tsc_deadline_time
                                 r xsave avx f16c rdrand lahf_lm cpuid_fault 
                                 epb pti ssbd ibrs ibpb stibp tpr_shadow vnmi
                                  flexpriority ept vpid fsgsbase smep erms xs
                                 aveopt dtherm ida arat pln pts md_clear flus
                                 h_l1d
XXX@YYYYYYYYYY:~$ uname -a
Linux YYYYYYYYYY 5.4.0-84-generic #94-Ubuntu SMP Thu Aug 26 20:27:37 UTC 2021 x86_64 x86_64 x86_64 GNU/Linu

I poked around online, and this kind of error seems to usually come up when there is some kind of architecture disparity between host and Docker image (such as #10). I am confused because I am going from an x86_64 i7 that works fine to an older x86_64 Xeon, and do not understand what the issue may be.

Any thoughts would be appreciated. Thanks!

Edit: best guess I've had so far is that the images are compiled for a newer x86_64 instruction set architecture than my processor... but I would have hoped to get a more useful error message if that were the case =/

commented

I was able to manually build this container on the machine that could not run the image from Dockerhub. I think this may be due to the Dockerhub version being built with/for a new CPU with newer instructions that my old CPU cannot use.