Issue #16948 has been updated by Josh Cooper. Target version set to 1.6.14 Keywords set to windows hardwaremodel architecture x64 x86 i386 i686 Affected Facter version set to 1.6.10
Thanks Matt. I think you're right about this. The fact name `hardwaremodel` is a bit misleading, and the docs aren't really clear about whether it's the OS or CPU <http://docs.puppetlabs.com/facter/1.6/core_facts.html#hardwaremodel>. It's really reporting on the OS (in the sense that that's how people use the fact, e.g. to select the appropriate package). On Centos 6 32-bit on 64-bit CPU, I get the following: <pre> $ uname -m i686 $ cat /proc/cpuinfo | grep ^flags 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 nx rdtscp lm constant_tsc up arch_perfmon pebs bts xtopology tsc_reliable nonstop_tsc aperfmperf unfair_spinlock pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm ida arat </pre> Note the `lm` flag, which indicates the cpu supports the long mode extensions (64-bit) <http://boincfaq.mundayweb.com/index.php?language=1&view=176>. So on Linux `hardwaremodel` and its derived `architecture` facts report on the OS, but Windows does not (it reports on the underlying CPU). Changing Windows would affect anyone running 32-bit Windows OS on 64-bit CPU. But even though it would be a breaking change in the next 1.6.x release, it's actually fixing a bug that prevents puppet from selecting the appropriate package for your OS. ---------------------------------------- Bug #16948: Facter hardwaremodel windows issue https://projects.puppetlabs.com/issues/16948#change-73430 Author: Matt Parry Status: Accepted Priority: Normal Assignee: Category: Target version: 1.6.14 Keywords: windows hardwaremodel architecture x64 x86 i386 i686 Branch: Affected Facter version: 1.6.10 Hi, Firstly I am ware of this fix https://github.com/puppetlabs/facter/commit/478386d24bb0d5c8494724d44f2e72c26ab4d4ff for windows to detect x64 architecture. This is tested on Facter ver:1.6.10 I found on one of my VMWare machines that it was setting Win32_Processor.Architecture = 9 (AMD64) when in fact it was Windows 2008 32Bit. From what I understand this value shows how the operating system interrupts the processor architecture but this should still show Win32_Processor.Architecture = 0 (INTEL) when a 32Bit OS is running on a 64Bit CPU. If this is true, then it leads me to believe it maybe a bug with VMWare and how it interprets the CPU? My question is, has this been highlighted previously and also I have been looking into the Win32_Processor class and see that AddressWidth could be a better candidate to detect 32/64 Bit OS's in facter? AddressWidth Data type: uint16 Access type: Read-only On a 32-bit operating system, the value is 32 and on a 64-bit operating system it is 64. This property is inherited from CIM_Processor. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
