SUSE / machinery

A systems management toolkit for Linux
GNU General Public License v3.0
158 stars 32 forks source link

machinery-helper-i686: illegal instruction #2243

Closed matwey closed 6 years ago

matwey commented 6 years ago

Hello,

I am trying to do inspect -x and see the following:

Inspecting changed-managed-files...
 -> Extracted 0 changed managed files.
Inspecting unmanaged-files...
 -> Inspection failed!

Errors while inspecting unmanaged-files:
 -> There is no machinery-helper available for the remote system architecture i586.

I understand that i586 is a bit outdated architecture. But machinery is a tool to copy system configurations, so I think there is a reason to support it in order to copy configs from very old legacy systems to be migrated.

thardeck commented 6 years ago

Hey @matwey ,

thy for reporting the issue.

How did you install machinery, from an rpm package, the gem or the source code?

We do support inspection of 32 bit x86 systems but the helper needs to be compiled in some of the installation methods.

Maybe the issue is that the system is reported as i586 and not i686. What is the operating system your are inspecting, which version is it and could you provide the output of the command uname -a on the inspected host?

matwey commented 6 years ago

Hello,

I am using machinery-1.23.0-5.1.x86_64 from openSUSE Leap 42.3 RPM.

I am inspecting openSUSE 11.2 x86 (32-bit)

> uname -a
Linux omicron 2.6.31.14-0.8-default #1 SMP 2011-04-06 18:09:24 +0200 i586 i586 i386 GNU/Linux

Upd: I've updated uname, because first time I pasted from wrong host (next ticket).

matwey commented 6 years ago

This particular host is i586 indeed, how could I rebuild helper for i586? Can we add i586 helper into RPM package?

thardeck commented 6 years ago

You could copy the i686 file to i586 or link it. The file is located under /usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/machinery-helper/.

If it works we need to fix the recognition in the code path, unless the i686 executable really does not work under i586.

matwey commented 6 years ago

Hello,

I made helper i586 as a link to helper i686. Now, the process ends up with the different error:

Inspecting unmanaged-files...
Machinery experienced an unexpected error. Please file a bug report at: https://github.com/SUSE/machinery/issues/new
Execution of "ssh matwey@192.168.10.5 -o LogLevel\=ERROR LANGUAGE\= LC_ALL\=C /home/matwey/machinery-helper --version" failed with status 255 (no error output).

Backtrace:
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/bundle/ruby/2.1.0/gems/cheetah-0.5.0/lib/cheetah.rb:641:in `check_errors'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/bundle/ruby/2.1.0/gems/cheetah-0.5.0/lib/cheetah.rb:404:in `run'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/lib/logged_cheetah.rb:23:in `run'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/lib/remote_system.rb:98:in `run_command'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/lib/machinery_helper.rb:77:in `has_compatible_version?'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/plugins/unmanaged_files/unmanaged_files_inspector.rb:77:in `run_helper_inspection'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/plugins/unmanaged_files/unmanaged_files_inspector.rb:60:in `inspect'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/lib/inspect_task.rb:87:in `block in build_description'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/lib/inspect_task.rb:79:in `each'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/lib/inspect_task.rb:79:in `build_description'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/lib/inspect_task.rb:21:in `inspect_system'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/lib/cli.rb:768:in `block (2 levels) in <class:Cli>'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/bundle/ruby/2.1.0/gems/gli-2.13.1/lib/gli/command_support.rb:126:in `call'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/bundle/ruby/2.1.0/gems/gli-2.13.1/lib/gli/command_support.rb:126:in `execute'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/bundle/ruby/2.1.0/gems/gli-2.13.1/lib/gli/app_support.rb:296:in `block in call_command'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/bundle/ruby/2.1.0/gems/gli-2.13.1/lib/gli/app_support.rb:309:in `call'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/bundle/ruby/2.1.0/gems/gli-2.13.1/lib/gli/app_support.rb:309:in `call_command'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/bundle/ruby/2.1.0/gems/gli-2.13.1/lib/gli/app_support.rb:83:in `run'
/usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.0/bin/machinery:41:in `<top (required)>'
/usr/bin/machinery:24:in `load'
/usr/bin/machinery:24:in `<main>'
thardeck commented 6 years ago

My bad, I think it can not be a soft link, it needs to be a real file or hard link, because a soft link would be transferred as link.

matwey commented 6 years ago

Now, I created a copy of file. But the result is completely the same.

2017-11-21 11:58 GMT+03:00 Tim Hardeck notifications@github.com:

My bad, I think it can not be a link, it needs to be a copy, because a soft link would be copied over on its own.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SUSE/machinery/issues/2243#issuecomment-345959470, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJj0yJ3zsmkM5cc3cXvPe2cm1woVUUWks5s4pDSgaJpZM4QZj24 .

-- With best regards, Matwey V. Kornilov

thardeck commented 6 years ago

I have checked the code and we compile with the arch 386, so it should be no problem. Could you copy the i686 helper over to your machine and run it there manually?

matwey commented 6 years ago

./machinery-helper-i686 --version Illegal instruction

This happens both on i586 an i686 (from the other ticket) hosts.

2017-11-21 12:27 GMT+03:00 Tim Hardeck notifications@github.com:

I have checked the code and we compile with the arch 386, so it should be no problem. Could you copy the i686 helper over to your machine and run it there manually?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SUSE/machinery/issues/2243#issuecomment-345966866, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJj026bTCmpKYcT0zRyrB93EY4ZEt5hks5s4pdzgaJpZM4QZj24 .

-- With best regards, Matwey V. Kornilov

matwey commented 6 years ago

So, I have a core-dump file. It fails at xorps instruction:

0x8080de1       xorps  %xmm0,%xmm0

i686 host:

> cat /proc/cpuinfo 
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 7
model name      : VIA Samuel 2
stepping        : 3
cpu MHz         : 599.867
cache size      : 64 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu de tsc msr cx8 mtrr pge mmx 3dnow up
bogomips        : 1199.73
clflush size    : 32
power management:

i586 host:

> cat /proc/cpuinfo 
processor       : 0
vendor_id       : SiS SiS SiS 
cpu family      : 5
model           : 0
model name      : 05/00
stepping        : 5
cpu MHz         : 166.621
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu tsc cx8 mmx up
bogomips        : 333.24
clflush size    : 32
power management:

As far as I understand, SSE extensions are not strictly required to be present in i686 architecture.

matwey commented 6 years ago

This may be related: https://github.com/golang/go/issues/20009

matwey commented 6 years ago

Compiling with GO386=387 and go 1.7 works for me. It produces the binary that works on i586 host.

matwey commented 6 years ago

Can all this be incorporated into machinery? I mean

  1. building 32-bit helper with GO386=387
  2. resolving helper binary for i586
thardeck commented 6 years ago

Many thanks for debugging this. Sure we can do that but it would be interesting how this change would affect the speed.

matwey commented 6 years ago

Does machinery-helper use floating point much?

2017-11-21 15:43 GMT+03:00 Tim Hardeck notifications@github.com:

Many thanks for debugging this. Sure we can do that but it would be interesting how this change would affect the speed.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SUSE/machinery/issues/2243#issuecomment-346015357, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJj06EZ03eGviWgv17XnvtP5D97YFgGks5s4sVdgaJpZM4QZj24 .

-- With best regards, Matwey V. Kornilov

thardeck commented 6 years ago

I don't think so. But I mean i386 is a rare target anyway so if it is not x times slower it should be no problem.

thardeck commented 6 years ago

I have tested it and on my x86_64 machine is not slower than the regular i686 one. I will add the fix to machinery.

thardeck commented 6 years ago

Machinery 1.23.1 is released with the fix. Many thanks for debugging it.

thardeck commented 6 years ago

@matwey Did you try the latest release, does it work as expected to inspect your old systems?

matwey commented 6 years ago

Hello,

machinery 1.23.1 works very well. thank you.

Only one thing I have to do manually is to copy /usr/lib64/ruby/gems/2.1.0/gems/machinery-tool-1.23.1/machinery-helper/machinery-helper-i686 as machinery-helper-i586 in order to inspect trully-i586 host. i686 works out of the box.

2017-12-05 11:44 GMT+03:00 Tim Hardeck notifications@github.com:

@matwey https://github.com/matwey Did you try the latest release, does it work as expected to inspect your old systems?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SUSE/machinery/issues/2243#issuecomment-349235264, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJj04z550x1toOkJFygWHbfK-WKAgofks5s9QJ9gaJpZM4QZj24 .

-- With best regards, Matwey V. Kornilov

thardeck commented 6 years ago

I missed the second point, I am sorry. I thought we match both versions. It will be fixed with the next release.