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?

Solution 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.}

Solution 2

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

Comments

[Mat]

You can compile 64bit binaries on 32bit systems, just not run them. And 32bit VM could emulate a 64bit CPU.

[rozcietrzewiacz]

Good point about compiling - my bad. The second part depends on the VM software, IIRC.

[ChrisCornwall]

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.

[ジョージ]

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 ) )

[rackandboneman]

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.

[Michael Shigorin]

Thank you for the reminder of getconf LONG_BIT, looks like inxi lacks this particular test.

[tolache]

` 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`