The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

Bug #10261

Facter reports incorrect windows architecture

Added by Corey Osman over 2 years ago. Updated about 1 year ago.

Status:ClosedStart date:10/24/2011
Priority:NormalDue date:
Assignee:Josh Cooper% Done:

0%

Category:windows
Target version:1.6.10
Keywords:windows, facter customer Affected Facter version:1.5.8
Branch:https://github.com/puppetlabs/facter/pull/217

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com

This issue is currently not available for export. If you are experiencing the issue described below, please file a new ticket in JIRA. Once a new ticket has been created, please add a link to it that points back to this Redmine ticket.


Description

Facter on windows reports the wrong architecture.

Screen_Shot_2011-10-24_at_6.19.06_PM.png (20.9 KB) Corey Osman, 10/24/2011 06:20 pm

Screen_Shot_2011-10-24_at_6.18.17_PM.png (48.2 KB) Corey Osman, 10/24/2011 06:20 pm


Related issues

Related to Facter - Bug #16948: Facter hardwaremodel windows issue Closed
Duplicated by Facter - Feature #7642: Windows architecture fact Duplicate 05/23/2011

History

#1 Updated by James Turnbull over 2 years ago

  • Category set to library
  • Status changed from Unreviewed to Accepted
  • Assignee set to Adrien Thebo

#2 Updated by Josh Cooper over 2 years ago

The behavior you are seeing on Windows was actually done intentionally, because we wanted to have the same parity as was done on other platforms. For example, here are the values returned by a Windows VM running on Mac, i.e. identical hardware.

Windows

architecture => i386
...
hardwaremodel => i686

Mac

architecture => i386
...
hardwaremodel => i386

If the desired behavior on Windows really is to return the “system type”, then this information can be obtained using WMI from the systemtype property of the Win32_ComputerSystem class (for me this is ‘x64-based PC’). See http://msdn.microsoft.com/en-us/library/windows/desktop/aa394102(v=vs.85).aspx

#3 Updated by Adrien Thebo over 2 years ago

  • Status changed from Accepted to Needs Decision

I would argue that the roles of architecture need to be more exactingly defined so that we can decide if this is a bug or not. This might need to go to someone that’s wiser than I.

#4 Updated by Corey Osman over 2 years ago

What about using the following command to get the OS Arch:

wmic OS get OSArchitecture

So this would equate to something like the following. https://github.com/puppetlabs/facter/blob/master/lib/facter/hardwaremodel.rb#L28

Facter.add(:hardwaremodel) do
  confine :operatingsystem => :windows
  setcode do
    model = Facter::Util::Resolution.exec('wmic OS get OSArchitecture')
  end
end

#5 Updated by Adrien Thebo about 2 years ago

  • Assignee deleted (Adrien Thebo)

#6 Updated by Josh Cooper about 2 years ago

  • Category changed from library to windows

#7 Updated by Michael Smith about 2 years ago

I checked on Windows XP SP3 and “wmic OS” doesn’t have an OSArchitecture key.

But there’s a PROCESSOR_ARCHITECTURE environment variable – at least on Windows XP SP3, Windows 7, and Windows Server 2008 R2.

Windows XP SP3 32-bit: PROCESSOR_ARCHITECTURE=x86
Windows 7 64-bit: PROCESSOR_ARCHITECTURE=AMD64
Windows Server 2008 R2 32-bit: PROCESSOR_ARCHITECTURE=AMD64

#8 Updated by Josh Cooper about 2 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee set to Josh Cooper
  • Target version set to 144
  • Affected Facter version set to 1.6.6

Thanks Michael. Sadly PROCESSOR_ARCHITECTURE == x86 for 32-bit executables on a 64-bit OS. But something like this would work: http://blogs.msdn.com/b/david.wang/archive/2006/03/26/howto-detect-process-bitness.aspx Or calling GetNativeSystemInfo directly http://msdn.microsoft.com/en-us/library/ms724340(v=vs.85).aspx

#9 Updated by Josh Cooper about 2 years ago

Josh Cooper wrote:

The behavior you are seeing on Windows was actually done intentionally, because we wanted to have the same parity as was done on other platforms. For example, here are the values returned by a Windows VM running on Mac, i.e. identical hardware.

It turns out uname -m on Mac 10.6.8 returns the wrong value (i386), but 10.7 does the right thing.

#10 Updated by Josh Cooper almost 2 years ago

  • Branch deleted (2.7.x)
  • Affected Facter version changed from 1.6.6 to 1.5.8

Windows has different names for what constitutes a 64-bit OS. There’s amd64, x86_64, and x64. I think x64 is the preferred name currently:

Windows Server x64 splunk-4.2.4-110225-x64-release.msi java_ee_sdk-6u4-jdk7-windows-x64.exe

However, amd64 is also in use, e.g. PROCESSOR_ARCHITEW6432=AMD64, as is x86_64.

I think the primary use of the architecture fact is to select the appropriate package, e.g. java_ee_sdk-6u4-jdk7-windows-x64.exe, in which case I am planning on using that. If anyone thinks it should be something else, let me know.

#11 Updated by Josh Cooper almost 2 years ago

  • Status changed from Accepted to In Topic Branch Pending Review
  • Branch set to https://github.com/puppetlabs/facter/pull/217

#12 Updated by Jeff Weiss almost 2 years ago

  • Status changed from In Topic Branch Pending Review to Merged - Pending Release
  • Target version changed from 144 to 1.6.10

#13 Updated by Stas Alekseev almost 2 years ago

Is there any information on when the fix for bitness will make its way into the Enterprise version of Puppet?

#14 Updated by Moses Mendoza over 1 year ago

  • Status changed from Merged - Pending Release to Closed

This was released in Facter 1.6.10. The PE facter patch is being explored directly with Stas via email.

#15 Updated by Charlie Sharpsteen about 1 year ago

  • Keywords changed from windows, facter to windows, facter customer

Also available in: Atom PDF