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?

3 Answers 3


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.

  • 1
    Hi Gilles, "file which init " may be a hack worth adding to the list. ( An off-topic: did you ever write any books on Unix ? I'd buy one ) ) Mar 20, 2015 at 15:47
  • While we are at finding out the real size of an integer type in C: An ages old trick is assigning a constant "1" to a variable, then counting how many times you can left shift it before anything untoward happens. Mar 24, 2018 at 21:36
  • Thank you for the reminder of getconf LONG_BIT, looks like inxi lacks this particular test. Oct 26, 2019 at 21:02
  • ` lsb-release -s` didn't work for me, it said: Command 'lsb-release' not found, did you mean: command 'lsb_release' from deb lsb-release. So I guess it should be ` lsb_release -s`
    – tolache
    Dec 7, 2020 at 8:52

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?.


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.

  • 3
    You can compile 64bit binaries on 32bit systems, just not run them. And 32bit VM could emulate a 64bit CPU.
    – Mat
    Nov 16, 2011 at 13:30
  • Good point about compiling - my bad. The second part depends on the VM software, IIRC. Nov 16, 2011 at 13:38
  • 2
    Some VM packages can run 64-bit guest OSes (and 64-bit software within them) natively on a 64-bit CPU, even if the host OS is 32-bits. Nov 16, 2011 at 20:30
  • 1
    @DavidS Good point as well... Still, no way that could be done on a 32-bit CPU. Nov 16, 2011 at 20:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.