I want to install a package manager on an embedded system that does not currently have one.

I know that the best way to do this is to use bitbake to simply bake a new image which includes a package manager and then flash that image to the board, but unfortunately I don't currently have access to all of the necessary pieces to build a full operating system image, so I need to hack it somehow.

The embedded system is running Automotive Grade Linux (Halibut 8.0.0).

sa8155:/etc# cat os-release 
VERSION="8.0.0 (halibut)"
PRETTY_NAME="auto 8.0.0 (halibut)"

Linux kernel 4.14.146

 😈   >adb shell
sa8155:~# uname -srm
Linux 4.14.146 aarch64

I'm not sure which version of glibc is installed as the system currently has no development tools:

sa8155:~# ldd --version
-sh: ldd: not found

sa8155:~# lsof -p $$ | grep libc | awk ' { print $NF" --version"; } ' | sh
-sh: lsof: not found

If I can get the package manager installed, the first thing I will do is install the development tools.

Also, I'm not sure about any other dependencies that the debian package manager may have.

  • Are you saying that the distro doesn't have apt or doesn't even have dpkg. dpkg installs / uninstalls packages but doesn't know how to download them or find their dependencies. apt downloads packages and their dependencies and then asks dpkg to install them. May 15, 2020 at 6:52
  • @PhilipCouling: Yes. My understanding is that it is common in embedded programming not to install these essentials but instead to rely upon an external tool like bitbake to bake an operating system image and then flash that image to the board.
    – Alex Ryan
    May 15, 2020 at 18:47
  • 1
    If your system has enough space, then your best bet is to go with the answer by guillem jover (the dpkg developer) below. If your system doesn't have enough space, then you indeed need to just create a new image. It is not a good idea to install a package manager with certain expectations onto a system that is not meeting these expectations.
    – josch
    May 17, 2020 at 7:28

1 Answer 1


Installing dpkg built for something else on a different distribution to manage software built also elsewhere does not sound like a great idea. This is going to be fraught with binary compatibility problems and subtle errors, as this would be the equivalent of using dpkg with --force-all and disregarding any dependency information.

Even projects that use dpkg as an overlay on top of a pre-existing binary "distribution" such as Fink on macOS, do build all the overlayed packages on the macOS system they are targeting, and inject phantom dependencies to represent the base system software.

Probably what you should do instead is create a foreign arm64 chroot with «debootstrap --arch=arm64 --foreign», tar that up and unpack and finalize the second stage debootstrapping on that device to get an actual and proper Debian chroot in that system, with a functional dependency system.

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.