I'm running Debian Buster (Not Raspbian / RaspberryPiOS) and need to install the rpi userland in order to get access to vcgencmd.

I've tried the following:

cd /tmp
git clone https://github.com/raspberrypi/userland.git
sudo apt-get install cmake
cd userland

This ends around the 5% mark, with many error lines and ultimately the following output:

/tmp/userland/interface/khronos/common/khrn_int_hash_asm.s: Assembler messages:
/tmp/userland/interface/khronos/common/khrn_int_hash_asm.s:36: Error: unknown architecture `armv6'
make[2]: *** [interface/khronos/CMakeFiles/khrn_client.dir/build.make:102: interface/khronos/CMakeFiles/khrn_client.dir/common/khrn_int_hash_asm.s.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:439: interface/khronos/CMakeFiles/khrn_client.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

I'm not sure what the solution to this problem is. The 'unknown architecture' seems like a good tarting point. But, I've no idea what the next move is.

Any suggestions / help would be greatly appreciated.

  • 1
    Thank you for making it clear ("Not Raspbian / RaspberryPiOS").
    – goldilocks
    Commented Dec 29, 2020 at 20:02

3 Answers 3


That github page does refer to the fact that you can specify an architecture as an option to buildme, eg. the 64-bit build would be --aarch64, if you are running 64-bit Debian. Otherwise you would want --arm7l (these are listed at the top of that buildme script as the native, ie. on the Pi, builds).

There are pre-compiled versions in https://github.com/raspberrypi/firmware/tree/master/hardfp/opt/vc -- they may or may not work but worth a try if you can't get the build to fly.

Minor nitpick that /tmp is not a great place to build stuff if it is a tmpfs system (it usually is), because that is actually in RAM. Compiling often requires a fair bit of memory (though the vc lib stuff is I think not that much), so by writing the output to RAM, you are directly reducing the amount of memory available for the ongoing compile processes. Not such a big deal if you have a 4+ GB model, but something to be aware of if you are not already.

It looks like the following is needed to be able to get it to run: LD_LIBRARY_PATH=/opt/vc/lib /opt/vc/bin/vcgencmd

That makes sense. Executables are usually linked to libraries that are separate entities in the file system. There is a default set of paths that are searched for them, much like $PATH works for commands, but the linker (which finds the library components) uses a binary cache which is created from configuration files in /etc. The primary one is ld.so.conf, which sources stuff in /etc/ld.so.conf.d.

I notice in the current64-bit version of RpiOS the VideoCore libs are in conventional places, but in the 32-bit version there is still the /opt/vc, and to inform the linker, there's an /etc/ld.so.conf.d/00-vmcs.conf with one line:


If that's where you've installed stuff, just duplicate this. It doesn't matter what the file is called, as long as it is in /etc/ld.so.conf.d/ and it contains that line. Also make sure it is only writable by root as this is potentially a very nasty security hole (so owned root.root and with 644 permissions, as non-privileged process do need to read it). Then:

sudo ldconfig

This reads those files and updates the linker cache, so that the VC libs will now be found without explicitly having to set LIBRARY_PATH.

  • Grest thanks. I can't actually find a readme etc that mentions the different build options / flags. As for the /tmp I only used that because it was given as a step over on the raspberry pi forums (possibly by Dougie Lawson). Commented Dec 29, 2020 at 20:24
  • Ok, I just saw the bit about --aarch6 Commented Dec 29, 2020 at 20:27
  • SO now I get this when trying to run vcgencmd: error while loading shared libraries: libvchiq_arm.so: cannot open shared object file: No such file or directory Any idea what this is about? Commented Dec 29, 2020 at 21:17
  • It looks like the following is needed to be able to get it to run: LD_LIBRARY_PATH=/opt/vc/lib /opt/vc/bin/vcgencmd <command> Commented Dec 29, 2020 at 21:28
  • 1
    That makes sense. You don't have to do that all the time if you don't want though -- I've added a few paragraphs at the end above about that. I'm impressed you are setting out to do this (run a generic distro) without much prior linux nuts and bolts knowledge. It isn't that hard (I am sure you can do it), but it does mean sitting down and putting some time in to learn relevant parts of the big picture.
    – goldilocks
    Commented Dec 29, 2020 at 22:07

Short answer:

Copying from raspberry pi arm64 image works:

root@rpi4:/home/user# apt-get install wget unzip
root@rpi4:/home/user# wget https://downloads.raspberrypi.org/raspios_lite_arm64/images/raspios_lite_arm64-2021-04-09/2021-03-04-raspios-buster-arm64-lite.zip
root@rpi4:/home/user# unzip 2021-03-04-raspios-buster-arm64-lite.zip
root@rpi4:/home/user# mount -o offset=272629760 2021-03-04-raspios-buster-arm64-lite.img /mnt/
root@rpi4:/home/user# cp /mnt/lib/aarch64-linux-gnu/libvchiq_arm.so.0 /lib/aarch64-linux-gnu/
root@rpi4:/home/user# cp /mnt/lib/aarch64-linux-gnu/libvcos.so.0 /lib/aarch64-linux-gnu/
root@rpi4:/home/user# cp /mnt/usr/bin/vcgencmd /usr/bin/
root@rpi4:/home/user# umount /mnt/
root@rpi4:/home/user# rm 2021-03-04-raspios-buster-arm64-lite.*

Long answer:

After downloading and unpacking the image, the offset of the partition 2 has been determined with fdisk (done on different machine, fdisk on rpi did not worked):

someone@somemachine:~/$ fdisk -l 2021-03-04-raspios-buster-arm64-lite.img 
Disk 2021-03-04-raspios-buster-arm64-lite.img: 1.68 GiB, 1807745024 bytes, 3530752 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb941691e

Device                                    Boot  Start     End Sectors  Size Id Type
2021-03-04-raspios-buster-arm64-lite.img1        8192  532479  524288  256M  c W95 FAT32 (LBA)
2021-03-04-raspios-buster-arm64-lite.img2      532480 3530751 2998272  1.4G 83 Linux

532480 (offset of the partition 2) * 512 (units) = 272629760.

After mounting the image, libraries needed by vcgencmd were traced using ldd:

root@rpi4:/home/user# ldd /mnt/usr/bin/vcgencmd
linux-vdso.so.1 (0x0000ffff8125e000)
libvchiq_arm.so.0 => not found
libvcos.so.0 => not found
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff811eb000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff811d7000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffff811bf000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff8104d000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff81230000)

Thanks to user130167 for his initial idea.


My solution to the problem copy it over from the 64 bit image of the Raspian, now Rasberry Pi OS I used the 2020-05-27-raspios-buster-arm64.img to do this a simple straight forward copy of the files required for it to work.

root@zeus-H370M-DS3H:~#  mkdir /tmp/cardroot
root@zeus-H370M-DS3H:~# mount /dev/sde2 /tmp/cardroot

After seeing this I was almost certain it would work.

zeus@zeus-H370M-DS3H:~$ file /tmp/cardroot/opt/vc/bin/vcgencmd
vcgencmd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=a22f9bd0844d3be74cd9dbd74dd86b6dd3196f7e, stripped
root@buster-raspi:~# file /usr/bin/dd 
/usr/bin/dd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=aa90bcf288d1293ca8980145095ba1dfba8e9b16, stripped

So I copied it over with rsync to my Pi and tried it.

root@buster-raspi:~# rsync -avP [email protected]:/tmp/cardroot/usr/bin/vcgencmd .
root@buster-raspi:~# ./vcgencmd temp
./vcgencmd: error while loading shared libraries: libvchiq_arm.so.0: cannot open shared object file: No such file or directory

To find the missing files.

root@buster-raspi:~# ldd vcgencmd
linux-vdso.so.1 (0x0000ffff8125e000)
libvchiq_arm.so.0 => not found
libvcos.so.0 => not found
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff811eb000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff811d7000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffff811bf000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff8104d000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff81230000)

root@zeus-H370M-DS3H:/home/zeus/qemu_vms# find /tmp/cardroot/ -name libvcos.so.0
root@zeus-H370M-DS3H:/home/zeus/qemu_vms# find /tmp/cardroot/ -name libvchiq_arm.so.0 

To copy them over into the proper places.

root@buster-raspi:~# rsync -avP [email protected]:/tmp/cardroot/usr/lib/aarch64-linux-gnu/libvcos.so.0 /usr/lib/aarch64-linux-gnu/
root@buster-raspi:~# rsync -avP [email protected]:/tmp/cardroot/usr/lib/aarch64-linux-gnu/libvchiq_arm.so.0 /usr/lib/aarch64-linux-gnu/

Test again to see if it worked.

root@buster-raspi:~# ./vcgencmd measure_temp

Success so copy it to the place it was on the Raspian.

root@buster-raspi:~# mv vcgencmd /usr/bin/
root@buster-raspi:~# which vcgencmd

root@buster-raspi:~# cat /etc/debian_version 
root@buster-raspi:~# uname -a
Linux buster-raspi 5.9.0-0.bpo.5-arm64 #1 SMP Debian 5.9.15-1~bpo10+1 (2020-12-31) aarch64 GNU/Linux

I spent hours more time searching to find this solution and this page. Than the five minutes it actually took once I clued in and had the thought, hey it is based on Buster, perhaps it will work with a copy of it from their system. Sure enough it did, so for anyone finding this is the future who want to know how to do it give it a try.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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