How to determine bitness of hardware and OS?

Question

Output of uname -a on my RHEL 5.4 machine is:

Linux <machine name> 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

Does it mean that hardware is 64 bit (going by perhaps first x86_64) and OS is also 64-bit going by last x86_64?

Also, what are these so many instances of x86_64?
Can I install 64-bit vm over 32-bit OS and vice versa?

Answer 1

The hardware, the kernel and the user space programs may have different word sizes¹.

• You can see whether the CPU is 64-bit, 32-bit, or capable of both by checking the flags line in /proc/cpuinfo. You have to know the possible flags on your architecture family. For example, on i386/amd64 platforms, the lm flag identifies amd64-capable CPUs (CPUs that don't have that flag are i386-only).

  grep -q '^flags *:.*\blm\b' /proc/cpuinfo    # Assuming a PC
  

• You can see whether the kernel is 32-bit or 64-bit by querying the architecture with uname -m. For example, i[3456]86 are 32-bit while x86_64 is 64-bit. Note that on several architectures, a 64-bit kernel can run 32-bit userland programs, so even if the uname -m shows a 64-bit kernel, there is no guarantee that 64-bit libraries will be available.

  [ "$(uname -m)" = "x86_64" ]    # Assuming a PC
  

• You can see what is available in userland by querying the LSB support with the lsb_release command. More precisely, lsb-release -s prints a :-separated list of supported LSB features. Each feature has the form module-version-architecture. For example, availability of an ix86 C library is indicated by core-2.0-ia32, while core-2.0-amd64 is the analog for amd64. Not every distribution declares all the available LSB modules though, so more may be available than is detectable in this way.

• You can see what architecture programs on the system are built for with a command like file /bin/ls. Note that it's possible to have a mixed system; even if ls is a 64-bit program, your system may have libraries installed to run 32-bit programs, and (less commonly) vice versa.

• You can find out the preferred word size for development (assuming a C compiler is available) by compiling a 5-line C program that prints sizeof(void*) or sizeof(size_t). You can obtain the same information in a slightly less reliable way² by running the command getconf LONG_BIT.

  #include <stdio.h>
  int main() {
      printf("%d\n", (int)sizeof(void*));
      return 0;
  }
  

As for virtual machines, whether you can run a 64-bit VM on a 32-bit system or vice versa depends on your virtual machine technology. See in particular How can I install a 64bit Linux virtual machine on a 32bit Linux?

¹ _{“Word size” is the usual name for what you call bitness.}
² _{It can be unreliable if someone installed an alternate C compiler with a different target architecture but kept the system default getconf.}

Answer 2

Have a look at man uname.

You can compile and run 32-bit programs on a 64-bit machine (though this requires a special setup), but can't run 64-bit binaries on a 32-bit system. Same applies to many Virtual Machines, but not all^*. So if you have a 64bit kernel, there's no way that your hardware is 32-bit-only.

If you want to test for what bitness a binary program is made, run file /path/to/the/program.

^{* This depends on the level, on which a given Virtual Machine operates: Those that execute binary code (almost) directly on the host CPU, will not be able to run 64-bit code on a 32-bit host. Those that emulate a certain CPU can do it, but they are less efficient because of the emulation level.}

Answer 3

You wondered about uname's multiple x86_64 occurrences:

x86_64 x86_64 x86_64

That's those three values ("omit -p and -i if unknown")

    -m, --machine 
          print the machine hardware name
    -p, --processor
          print the processor type or "unknown"
    -i, --hardware-platform
          print the hardware platform or "unknown"

Note that -p and -i are not part of POSIX standard. The values are unknown on Debian, so uname would print x86_64 only once. Red Hat/CentOS defines the value.

Also read: How does Linux uname -m get its information? and Why do uname -p and uname -m and arch output different architectures?.