I installed Raspbian 32 bit. But 'arch' writes aarch64

Question

I have a Raspberry Pi 4 B. I have tried burning multiple systems on a 32 GB SD card using Raspberry Pi Imager v.1.7.4: Raspbian 10 lite 32 bit, then Raspbian 11 lite 32 bit, and then booted manually from the Raspberry Pi OS Lite (Legacy) (Buster) website. When I write the arch command in the console, I get aarch64. But when I used another old SD card (16GB) with Buster the console response was armv71 i.e. 32bit. Why did this happen? How can I write a 32bit system to an SD card?

Answer 1

https://github.com/raspberrypi/firmware/issues/1795

From my comment link:

The switch to running a 64-bit kernel by default on Pi 4 is intentional. We believe it gives a better experience with few drawbacks. As you've found, you can revert to the 32-bit kernel by adding arm_64bit=0 to config.txt. See https://forums.raspberrypi.com/viewtopic.php?p=2088935#p2088935 for more details.

Answer 2

On pretty much all Linux systems, arch with no options is a synonym for uname -m, which in turn prints the CPU architecture the kernel thinks it’s running on. This does not necessarily match what CPU architecture the kernel was built for (it’s usually a superset of that) or what CPU architecture the userspace components running on that kernel were built for.

This is significant because some CPUs support a kind of ‘mixed’ mode, where some of the system is one bit width and some of the system is a different bit width. This has historically been very common on 64-bit x86, 64-bit MIPS, and older 64-bit POWER CPUs to allow backwards compatibility with code written for 32-bit versions of those systems, and 64-bit ARM processors generally also support it for essentially the same reason.

In particular, 64-bit-capable Raspberry Pi systems default to using a 64-bit kernel irrespective of what bit width the associated userspace is, as this allows some security and performance improvements and enables a handful of usecases (such as multi-monitor 4k setups) that were not realistically possible with a 32-bit kernel.

Because of this, arch is not a reliable way to determine the bit-width of userspace. The most reliable portable option I have found is to install the file command and run file $(command -v file), which will give you output vaguely similar to this (this example is from my 64-bit x86 home server):

/usr/bin/file: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, stripped

It should always say near the beginning whether the executable is 64-bit or 32-bit.

Alternatively, on Debian-derived systems (including Raspbian and Ubuntu), you can instead run dpkg --print-architecture, which will give output similar to arch but tell you what architecture the package manager thinks the system is using, which should always match up with the bit-width of your userspace.