Alpine Linux first steps

Here’s a short primer to Alpine Linux, specifically for the Raspberry Pi platform

Why Alpine Linux?

  • it’s small
  • it can be installed by copying files on the FAT partition of the SD
  • it can run from RAM, the filesystem will remain read-only (persisting changes is of course possible)
    • this is very good for embedded systems where power can be cut unpredictably!
  • it’s a bare-bones system – no clutter, better security
  • therefore it’s a good choice for embedded development

Alpine Linux is often used for Docker containers. And it is also supported on the Raspberry Pi platform.

Why not Alpine Linux?

  • it’s not recommended to start with Alpine for beginners – they should definitely use NOOBS or Raspbian
    • Alpine assumes some level of Linux knowledge, and adds it’s own tools to manage the installation
  • Alpine uses musl instead of glibc as libc (standard C library) – this is good for embedded & resource constrained systems;
    • “big distributions” use glibc however – software compatiblity might be an issue.
  • Less pre-compiled packages are available than for Raspbian – meaning you might be on your own actually building packages you need.
  • You will have to take care of many things, e.g. setting the correct CRDA – this can be very time-consuming (we have written a blog post previously about this)

Highly recommended reading


We recommend to use the armhf build, not the aarch64 one. As of writing this the most recent Alpine release is 3.8.1.

I have tested Alpine on the Pi 3 B+, and the Zero W, and am confident that it will run on Pi 1, 2 and 3.

  • To ensure data integrity verify the SHA256 hash. On Windows this can be done using VisualHash
  • extract the tar.gz file. On windows, this can be done using 7-zip
  • extract the tar file as well (into it’s own directory)

Extracting the tar file will give you the contents which need to be copied to the FAT32 partition of the SD card.

No other partitions are needed to start Alpine.

Remember, the Raspberry Pi needs a FAT partition as the first partition to boot properly.

Bonus tip: if you need formatting, the SD Card Association’s SD Formatter will do the trick on Windows.

  • copy the contents of the directory to the SD card’s FAT partition


The screenshot shows a freshly installed Alpine Linux.

noteworthy directories:

  • apks – contains Alpine packages

Diskless mode

The default installation mode for the Raspberry Pi is diskless mode.

In diskless mode, the SD card is only used initially to load the system (and your apkovl changes, see below) into a RAM filesystem.

You have to preserve modifications in between sessions using Alpine’s  lbu (local backup) utility.

Default Login for Alpine on Raspberry Pi

Boot up the Raspberry Pi with the Alpine SD card inserted.

  • user: root
  • password: <leave empty>

The password is not necessary, after entering root and pressing enter, you will be logged in.

Setup procedure

Once logged in, type


hint: on the German keyboard layout the dash “-“ is on the “?” key.

  • Alpine will suggest to set up a keyboard layout as the first step
    • and then ask for the keyboard variant

I used “de” and “de-nodeadkeys”

  • Alpine will ask for the system’s hostname
  • Then you can set up networking
    • you can set up networking for wired and wireless devices
  • set up the IP, dhcp is supported
  • if you do not want to set up further networking devices you can type done and press enter; alternatively you can setup wlan0 (on Pi 3B+)
  • Alpine will ask if you want to do additional manual network configuration. Press enter to select the default (no)

Additional settings

  • After this Alpine will ask you to set a new root password
  • time zone
    • e.g. Europe
    • e.g. Berlin as sub-timezone
    • Europe/Berlin will work as well.
  • HTTP/FTP proxy URL (none if you are in a “normal” networking environment)


  • due to clock skew you might run into issues setting up a package mirror (no mirror can be added)
  • to fix this problem run setup-alpine a second time once you have gone through it completely the first time
    • you will get some warnings, as some services will already have been started.
  • the default option f will test for the fastest mirror

SSH Server

  • openssh is the default, but you can also install dropbear

Dropbear will save some RAM, but it has less features. We recommend OpenSSH.

Alpine will now generate SSH host keys for you.

NTP Client

  • busybox
  • openntpd
  • chrony (default)

Storing Configs

An important step in the setup procedure is to set where configuration changes are going to be saved.

mmcblk0p1 is the pre-selected default

This is the first partition (FAT32 partition) of the Raspberry Pi’s SD card.

After that, Alpine will suggest a local cache directory for apk packages, also on the SD card: /media/mmcblk01p/cache

Important note: Alpine will not save any changes in the diskless mode, even the setup which you just completed. You need to use the lbk utility to persist these changes!

Updating the system

apk update

apk ugrade

Quite similar to Debian derivatives, really.

Installing packages

apk add htop

Adds the htop package. (Allowing you to monitor resource usage in a more graphic way).

Remember, Alpine will not persist the package installation if you do not use the lbk utility!

Persisting changes

The lbk utility (local backup) is used to persist changes in diskless mode. Run it after you are satisfied with your setup:

lbu commit –d

This will create a file called <hostname>.apkovl.tar.gz in your FAT32 partition. In this file lbu will save the changes respective to the base configuration.

Useful flags:

-d: will remove old apk overlay files.

-n: don’t commit, show what would have been committed.

This is also a great place to be patching these configurations dynamically while creating SD cards en masse, and thus injecting them into the system (e.g. modified settings / IP addresses / …).


in my case I called the system “mir”, that is why the apkovl is called mir.apkovl.tar.gz


Note that only the single folder “etc” is contained in the apkovl.

That is because lbu, by default, will only persist changes in the /etc directory! (except /etc/init.d)

Adding other directories to lbu’s list of persisted directories:

To add a directory or file besides /etc to monitor for changes and commit (when you run lbu commit), use lbu include:

lbu include /home/miaucat

and then commit the file system.

You will only need to include the directory once, and commit. Future commits will preserve the included directory as well.

Showing the current changes:

lbu status

will show the files changed since the last commit.

use the –a flag to show all files compared to the fresh installation.

Note that on the reboot, Alpine will extract the contents of the apkovl, which will take a bit of additional time (and RAM).

Interesting things to know

  • To bring the size down, Alpine uses busybox. Busybox is a single executable which is symlinked to different utilities (like tar, and so on.) This is a frequently used technique in embedded systems, e.g. the Fritz!Box.
  • Alpine mounts the FAT32 partition read-only as /media/mmcblk0p1. It will be briefly remounted writable for persisting changes.
  • Alpine will create a cache directory in the FAT32 partition for caching the apk’s downloaded from the online mirrors.
  • By default only vi is installed as text-editor. vi is included in the busybox executable (/usr/bin/vi is a symlink to /bin/busybox).
  • lbu can keep multiple backups, and you can revert to an older backup. This only affects which apkovl is considered active.
  • Alpine does not have udev, it has mdev.
  • As Alpine uses a RAM based file system, you can simply remove the SD card after Alpine has booted, and boot the next Pi with it. Very cool!
    • note simply plugging it back in will not allow you to commit – you’ll get an I/O error.