If you want to run Linux on ARM64-based machines, Debian GNU/Linux is an excellent distribution choice. Due to its universal concept, it works great on laptops, workstations and servers alike. Unfortunately, Debian officially supports only a small number of ARM64-based machines. Yet, you can run Debian unmodified on a lot more ARM64-based machines - if you manage to install it. After discussing some basics and showing how to check the support status for a particular machine, this article describes my recommended way for performing the actual installation using a concrete example.

NOTE: This article is a major rewrite of my previous articles covering similar topics.

Why use the official Debian distribution?

Before we dwelve into details, let’s first discuss some basics. I often hear the argument that people want to solve basic tasks like installing the OS as quickly as possible and focus on the more interesting activities in the layers above. Usually, these people end up downloading and flashing one of the countless unofficial OS images from the Internet. What’s wrong with that?

Choosing a good base OS for your setup is the foundation for running a trustworthy and secure system. While this might be irrelevant for a quick and dirty test setup, in case you want to run your system for years and put personal data on it, this aspect can be important.

Personally, I discourage using unofficial images for a number of reasons:

• Some unofficial images bundle additional software that is not packaged in the official repositores. Therefore, you never get updates for them. This is bad, especially for security-critical components such as the kernel.
• In addition to trusting the upstream project (such as Debian), you also have to trust the projects and individuals that built the images.
• Apart from trusting these third parties, you also have to trust their build infrastructure.
• Setting up the system yourself, you can optimize the setup to your needs from the very beginning.
• Upstream updates from Debian are more likely to break the system because Debian does not test new packages with the unofficial modifications applied.

On the other side, running an official distribution, you can be sure to get the best “vanilla” experience. In addition, all the base software for your system comes from official sources and was build on their official infrastructure.

However, not all boards are supported well in mainline linux. Hence, many unofficial Debian distributions (such as Armbian) provide patches that fix issues or add functionality. While this might seem nice to get a new board working, the patches require regular maintenance if they are not upstreamed. Hence, it can happen that certain boards will stop receiving kernel upgrades at some time. On the other hand, when using the official debian kernel, this is unlikely to happen.

Why use this tutorial instead of the official documentation?

You may wonder why I recommend following this tutorial instead of installing Debian on your machine using Debian’s official documentation. Here are the arguments:

• My approach makes it possible to run the official and unmodified Debian versions on machines for which Debian does not provide official installation instructions (I refer to them using the term “unofficially supported machines”).
• My approach uses the flash-friendly f2fs filesystem that greatly reduces wear of your flash memory and improves its performance while the official installer does not support f2fs.
• My approach replaces most parts of systemd with sysvinit (Devuan is still a better choice if you want to avoid systemd completely).
• My approach produces nice universal tar archives that can be used for installing Debian to more ARM64-based machines within minutes instead of going through the time-consuming installer process each time.
• My approach uses a modern extlinux configuration of the u-boot bootloader.

Unofficially supported machines

The Linux kernel supports a variety of ARM64-based machines. Unlike x86 machines, ARM64-based machines require a machine-specific device tree binary (dtb) that is built from source. As Debian aims to be an universal OS, it ships a generic ARM64 kernel that enables support for as many of these machines as possible by shipping dozens of dtbs.

The current Debian GNU/Linux 13 (trixie) release ships version 6.12 of the Linux kernel. To look up the machines it theoretically supports, do the following:

• visit to packages.debian.org.
• use “search package directories” with “only show exact matches” and search for the package linux-image-arm64 in the stable distribution.
• hit the search button and click on the result.
• since linux-image-arm64 is a metapackage that depends on the current kernel, check which version it is (as of now, it is linux-image-5.10.0-7-arm64). Click on this package to show more details.
• click on “list of files” to see all files contained in this actual kernel package and check the dtb files listed there.

If your machine is listed there, it is worth trying to run the official distribution of Debian on it.

If your machine is not listed, don’t give up yet - it might still be supported by a newer Linux kernel. Later in this tutorial, I will show how you can install a newer kernel in the current stable release and get regular updates for it. However, this only works if your machine is supported at least in the “unstable” release.

Don’t worry too much about the name “unstable” - the kernels in Debian unstable are based on well-tested kernels from stable releases by upstream and usually work well. They are updated frequently and, thus, receive security updates. While I consider them okay as a daily driver, they might not be as stable as the kernels from the stable distribution. Also, you will be switched to newer kernels over time instead of receiving critical updates only. Hence, I recommend only using the unstable kernels if your machine is not supported or does not work well with the stable kernel.

To check if your machine has support in the unstable kernel, repeat the previous steps but choose “unstable” instead of “stable” for the distribution. If your machine is still not listed, then you are out of luck for now as your machine is currently not supported (but it might get official support in the future).

Here is a small list of machines I tried this approach on using the current 6.12 kernel and U-Boot 2025.10:

Installation

In the following, I will assume you want to install Debian GNU/Linux 13 on a Rock64 by Pine64.

Concept

My installation concept covers the following stepts:

• Installing a device-independent base system using the official installer
• Customizing the base system
• Adapting the base system for the target
• creating tar archives for boot and root
• building the bootloader (device-specific)
• assembling a device-specific image
• flashing the assembled image

This might seem a lot of work, but note that the firsttwo steps are device-independent. Thus, you won’t have to redo them when installing other devices in the future.

Requirements and assumptions

Apart from having an unofficially supported machine, I assume you have basic knowledge about the following:

• creating and operating virtual machines with KVM/QEMU using virt-manager
• operating your ARM64 machine over the serial console

In addition, you will need:

• a dedicated physical x86 machine with a fresh installation of Debian GNU/Linux 13 with at least 2 GiB of RAM and 20 GiB of storage
• a user account with a user named youruser
• an empty microSD card with a capacity at least 4 GiB
• a working internet connection

Of course, the tutorial should also work with other systems, distributions and environments but some steps may differ. Also, note that using a VM is only possible if you enable nesting as we will exercise the ability to run ARM64-VMs ourselves. Using very old hardware (e. g. a single-core 32bit machine) is theoretically possible but practically infeasible.

Disclaimer

All data and information provided in this tutorial is for informational purposes only. The author makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this tutorial and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.

In no event, the author will be liable for any loss or damage including without limitation, indirect or consequential loss or damage, or any loss or damage whatsoever arising from loss of data or profits arising out of, or in connection with, the use of this tutorial.

Step 1: Installing the base system

First of all, let’s create a directory where we will store all the assets produced in this tutorial:

mkdir -p /home/youruser/assets

Then, download the netinst ISO for arm64 and verify its integrity, see here:

https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/

Make sure you also have qemu and virt-manager installed:

apt install qemu-efi-aarch64 qemu-system-arm virt-manager

Next, create a new virtual machine using the aarch64 architecture as shown here:

In the next step, choose the netinst image you downloaded previously as ISO and select “Debian 13” as OS. Give the VM the 768 MiB of RAM (the installer crashed for me with just 512 MiB) and as many cores as you have. Next, create a disk image with at least 5 GiB (or stick with the default) and leave the default network settings (using NAT). Finally, fire up your new VM. You should get a screen like mine:

After selecting the first option, the “oldschool” text installer should boot and give you the following screen:

Now run through the installer but follow these guidelines:

• choose a generic hostname and domain name (we want to build a generic, reuseable image)
• choose simple passwords for root and the user you create (again, we want to build a generic image)
• use deb.debian.org as pkg mirror
• partition the disk to have the following layout (watch my old Debian 11 video for more details):
  • Partition #1: Size 100M, type ESP (EFI Firmware), no mountpoint, bootable, name efi
  • Partition #2: Size 500M, type ext4, mountpoint /boot, name boot, label boot, not bootable
  • Partition #3: Size maximum, Type physical volume for encryption, name rootencrypted no mountpoint, not bootable
  • Inside the encrypted volume, create a single ext4 partition spanning the whole outside partition with type ext4 and mountpoint /, name root, label root, passphrase abcd (this will ease further setup)
  • no swap
• when installing packages, unselect all packages for installation in tasksel (our aim is to get a minimal image, we will install specific packages later as we need them).

NOTE: Don’t be confused that the installer will display the crypto device being named vda3_crypt or similar - that’s just the name of crypto device but not the partition label!

Apart from the security benefit, an additional advantage of using encryption is that we do not risk data loss from accidentally powering on one of our real devices later as no filesystem is mounted r/w before the password was entered correctly.

After installing, the system should starting booting up but get stuck with “Display output is not active”. Due to a regression, the password prompt is not shown in the graphical console, and also entering the password blindly is broken (it used to work Debian 11). Hence, switch to the serial console (View -> Consoles -> Serial 1) to enter it. We will do the rest of the setup from here. Afterwards, a login shell should be presented. Login as root with the password you have set previously.

Step 2: Customizing the base system

sysvinit

First, install sysvinit package and reboot (ignore the warning and error messages):

apt install --allow-remove-essential systemd-sysv- sysvinit-core

Enable the serial console (the virt target uses ttyAMA0, later at install time we will switch this to the device of your real hardware):

cat <<'EOF' >> /etc/inittab
T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
EOF

Then reboot:

reboot

After the reboot, system bootup should look as follows:

Now, we can remove more systemd bits by installing libpam-elogind:

apt install libpam-elogind 

ACPI

Install the acpi package for handling events such as button presses and sleep modes:

apt install acpid

f2fs

While the installer does not support installing to f2fs filesystems, f2fs is the filesystem I recommend for flash media. Add the module to /etc/initramfs-tools/modules:

echo "f2fs" >> /etc/initramfs-tools/modules
echo "crc32" >> /etc/initramfs-tools/modules

Install this package to get support for it:

apt install f2fs-tools

Time synchronization

WARNING: This part works but the daemon fails to synchronize the clock on boot and needs to be run manually. Any suggestions how to fix this are welcome.

Most arm64 machine don’t have a backup battery for their realtime clock (RTC). This results in the date and time being wrong each time you disconnect power. In general, even if your machine has a backup battery, it is a good idea to setup time synchronization.

Synchronizing date and time can be done using the NTP protocol. Debian ships several NTP clients you can choose from. Personally, I like OpenBSD’s openntpd as it is very lightweight and has been developed with security in mind. To install it:

apt install openntpd

As we want to set the date and time on each boot, change the following in /etc/default/openntpd:

#DAEMON_OPTS="-f /etc/openntpd/ntpd.conf"
DAEMON_OPTS="-s -f /etc/openntpd/ntpd.conf"

It should start and also run on the next boot. As we want to set the current time also now, restart it:

service openntpd restart

DTB file handling

Since we want to use a separate /boot partition later, we need to make sure the dtb files for the current kernel are there. Therefore, we create a dtb directory there first:

mkdir -p /boot/dtbs

And add the following script that copies the dtb files automatically each time a new kernel is installed or upgraded:

cat <<'EOF' >> /etc/kernel/postinst.d/copy-dtbs
#!/bin/sh

set -e
version="$1"

echo Copying current dtb files to /boot/dtbs....
cp -a /usr/lib/linux-image-${version}/. /boot/dtbs/
EOF

Let’s make this script executable:

chmod +x /etc/kernel/postinst.d/copy-dtbs

And run it once manually to copy the dtb files for the currently installed kernel:

/etc/kernel/postinst.d/copy-dtbs `uname -r`

Bootloader configuration

Create a directory to hold the bootloader configuration:

mkdir -p /boot/extlinux

And create an extlinux boot configuration file (the bootloader u-boot looks them up):

cat <<'EOF' >> /boot/extlinux/extlinux.conf
TIMEOUT 2
PROMPT 1
DEFAULT debian

LABEL debian
MENU LABEL Linux debian
KERNEL /vmlinuz
INITRD /initrd.img
DEVICETREEDIR /dtbs
APPEND net.ifnames=0 root=LABEL=root cryptopts=source=LABEL=rootencrypted,target=root_crypt,luks
EOF

Kernel from unstable (optional)

As discussed previously, it might be necessary to run the kernel from the unstable distribution for certain machines to work better at all. In addition, some board features might work better with kernels from unstable. At the time of writing, kernel 6.17 is available in unstable while kernel 6.12 is in stable.

Some people recommend installing kernels from backports instead of from unstable. I discourage taking this approach as the kernels in backports often receive security updates quite late.

So, which kernel should you choose if your board is supported in stable as well? It depends. The only advice I can give is: If all features of your board that are relevant to you work with the stable kernel, stick with it. If not, try the unstable kernel.

To install the unstable kernel, we need to first add the unstable distribution to apt:

cat <<'EOF'>>/etc/apt/sources.list.d/unstable.list
deb http://deb.debian.org/debian unstable main
EOF

And specify that we only want to install the kernel from unstable (and no other packages):

cat <<'EOF'>>/etc/apt/preferences.d/99unstable
# Never prefer packages from unstable
Package: *
Pin: release a=unstable
Pin-Priority: 100

# Allow upgrading kernel from unstable
Package: linux-image-arm64
Pin: release a=unstable
Pin-Priority: 500
EOF

Finally, we can safely upgrade the kernel:

apt update
apt install -t unstable linux-image-arm64

Reboot

Before we continue to the next step, let’s reboot the system:

reboot

Step 3: Adapting the base system for the target

The following changes are “devastating” and will make the VM unbootable or “less unique”. Therefore, I recommend backing up its disk image before applying them (a snapshot would be even better, but KVM on Devuan3 does not seem to support them on aarch64).

Remove GRUB

Remove the grub bootloader (we will not use it - and yes you need to do it in this obscure way):

apt install --allow-remove-essential grub-efi-arm64-signed- grub-common- libpam-elogind

SSH servers (openssh and dropbear)

Install the regular OpenSSH server together with dropbear for unlocking the machine remotely during boot:

apt install --no-install-recommends openssh-server dropbear-initramfs

Change the dropbear port so we don’t run into conflicts with the main server (I recommend using different SSH keys for the main and auxiliary SSH server) and add a timeout:

cat <<'EOF' >> /etc/dropbear/initramfs/dropbear.conf
DROPBEAR_OPTIONS="-p 4748 -I 60"
EOF

Create an authorized-keys file that limits access to running the cryptsetup binary in dropbear (put your actual SSH public key here):

cat <<'EOF' > /etc/dropbear/initramfs/authorized_keys
no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command="/usr/bin/cryptroot-unlock" ssh- ...
EOF

To set a static IP address that usually works more reliable than DHCP (replace the placeholders):

cat <<'EOF' > /etc/initramfs-tools/conf.d/staticip
IP="<client-ip>::<gw-ip>:<netmask>::eth0:off"
EOF

Finally, renegerate the initramfs:

update-initramfs -u

Configure the network

Since my setup is using the “old-style” interface names, you need to change the interface names in /etc/network/interfaces like this:

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

If you don’t want to use DHCP for the regular system either (recommended), make sure you edit /etc/network/interfaces accordingly. For instance, to have a static IP:

# The primary network interface
allow-hotplug eth0
#iface eth0 inet dhcp
iface eth0 inet static
        address 192.168.2.11
        netmask 255.255.255.0
        gateway 192.168.2.1
        nameservers 192.168.2.1

Restrict access to the system

Delete the default user:

userdel -r user

Use the keys authorized for dropbear for system access as well:

mkdir /root/.ssh
chmod 700 /root/.ssh
cp /etc/dropbear/initramfs/authorized_keys /root/.ssh/
chmod 600 /root/.ssh/authorized_keys

Afterwards make sure you edit the /root/.ssh/authorized_keys file to remove the restrictions (each line should start with ssh-.

Replace fstab and crypttab

Replacing crypttab and fstab should be done as the last steps, otherwise regenerating initramfs might cause troubles. Replace the fstab as follows:

cat <<'EOF' > /etc/fstab
# <file system>        <mount point>  <type>  <options>                   <dump>  <pass>
/dev/mapper/root_crypt /              f2fs    noatime,background_gc=off   0       1
LABEL=boot             /boot          ext4    errors=remount-ro           0       2
EOF

To replace the crypttab file:

cat <<'EOF' > /etc/crypttab
root_crypt LABEL="rootencrypted" none luks,initramfs
EOF

Finally, power down your VM:

poweroff

Step 4: Creating tar archives

After tweaking the system to our needs, we want to create tar archives that will contain the contents that will be used for the boot and root partitions later. To do this, we will mount the disk images of the VM directly on the host and extract the files from there.

To extract the files from the VM, load the nbd module on your host.

modprobe nbd max_part=8

Mount the VM’s disk image (replace the path according to where you stored your virtual disk):

qemu-nbd --connect=/dev/nbd0 /var/lib/libvirt/images/debian-aarch64.qcow2

Create mount points, decrypt and mount the partitions:

mkdir /mnt/rootfs
mkdir /mnt/bootfs
mount /dev/nbd0p2 /mnt/bootfs
cryptsetup luksOpen /dev/nbd0p3 someroot
mount /dev/mapper/someroot /mnt/rootfs

Create tar archives and store them as our assets

tar cfvzp /home/youruser/assets/debian13-aarch64-bootfs.tar.gz -C /mnt/bootfs .
tar cfvzp /home/youruser/assets/debian13-aarch64-rootfs.tar.gz -C /mnt/rootfs .

Finally, clean up:

umount /mnt/bootfs
umount /mnt/rootfs
cryptsetup luksClose /dev/mapper/someroot
qemu-nbd -d /dev/nbd0

Step 5: Building the bootloader

We build u-boot on the host machine.

The process of building u-boot is machine-specific! This is just an example!

Install dependencies:

apt install device-tree-compiler build-essential gcc make git libssl-dev python3-dev bison flex bc libssl-dev make gcc gcc-arm-linux-gnueabihf binutils-arm-linux-gnueabihf swig gnutls-dev gcc-aarch64-linux-gnu gcc-arm-none-eabi python3-setuptools python3-pyelftools

Check the tags listed on this website to find out what the latest lts version of trusted-firmware-a is:

https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/

Clone the trusted-firmware-a source repository with that tag (in our case: `lts-v2.12.8):

git clone --depth=1 -b lts-v2.12.8  https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
cd trusted-firmware-a

Compile the firmware:

make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3328 bl31

Set a variable pointing to the build artifact:

export BL31=${PWD}/build/rk3328/release/bl31/bl31.elf

Leave the build directory:

cd ..

Find the latest stable release of u-boot by inspecting their Git tags here:

https://source.denx.de/u-boot/u-boot/-/tags

Next, clone this tag (in our case: `v2025.10) of the u-boot repository:

git clone --depth=1  -b v2025.10 git://git.denx.de/u-boot.git

Change into its directory:

cd u-boot

Create the configuration from the default config (again, adapt it if you have a different board):

make CROSS_COMPILE=aarch64-linux-gnu- rock64-rk3328_defconfig

Start the build (change -j16 to match the number of your actual cpu threads):

make -j4 CROSS_COMPILE=aarch64-linux-gnu-

Save the assets:

cp idbloader.img /home/youruser/assets/
cp u-boot.itb /home/youruser/assets/

Step 6: Installation / Flashing

With all goodies in place, we can now flash the contents to the storage of your machine. In the following we assume that your machine uses a microSD card for storage (such as the Rock64).

Partitioning

As a friend of the KISS principle I recommend using a dead-simple MBR partitioning scheme instead of using GPT.

First, change to our assets directory:

cd /home/youruser/assets

Now, insert your microSD card and check that is has been recognized:

dmesg

In the following, we assume that your device is recognized as /dev/sdX (replace /dev/sdX with the actual name of your device).

Now, overwrite the first megabytes of the card with zeroes:

dd if=/dev/zero of=/dev/sdX bs=1M count=256

Next, remove the microSD card and re-insert it so its partitioning information will be updated in your OS and check its assigned device name (could be the same as before, but could also be different):

dmesg

Then, create a template to hold our partition table (adjust the size of the boot partition if you have a bigger microSD card, but don’t make it too big):

cat <<'EOF'>>sfdisk.template
label: mbr
unit: sectors
first-lba: 64

start=        2048, size=       16384
start=       18432, size=      614400, bootable
start=      632832
EOF

Now, apply the template to your microSD card:

/sbin/sfdisk /dev/sdX < sfdisk.template

Now check dmesg again and make sure the three new partitions have been recognized (e. g. as /dev/sdX1, /dev/sdX2 and /dev/sdX3):

dmesg

Filesystem creation

Now, create an ext4 filesystem to hold our boot partition (flash wear should not be an issue as normally no writes occur on /boot during normal operation):

mkfs.ext4 -m0 -L boot /dev/sdX2

For the root partition, we create an encrypted partition, unlock it, and format it using the f2fs filesystem with filesystem options recommended in the ArchLinux Wiki. To make encryption more secure, calculate the value for --pbkdf-memory by subtracting 64 MiB from the physical memory available on your target device. In our example, we would use 1984 for our Rock64 that has 2 GiB of RAM.

cryptsetup luksFormat /dev/sdX3 --label=rootencrypted --pbkdf-memory 1948
cryptsetup luksOpen /dev/sdX3 somename
mkfs.f2fs -O extra_attr,inode_checksum,sb_checksum -l root /dev/mapper/somename

Mounting filesystems and copying files

Mount the partitions:

mkdir -p /mnt/targetbootfs
mkdir -p /mnt/targetrootfs
mount /dev/sdX2 /mnt/targetbootfs
mount /dev/mapper/somename /mnt/targetrootfs

Extract the archives:

tar xzvpf /home/youruser/assets/debian13-aarch64-bootfs.tar.gz -C /mnt/targetbootfs/.
tar xzvpf /home/youruser/assets/debian13-aarch64-rootfs.tar.gz -C /mnt/targetrootfs/.

Device-specific adjustments

Next, adjust the settings for the serial console. To do that, edit the file /mnt/etc/inittab and adjust the following line:

T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100

This setting is not machine-specific but chipset-specific. Below are some examples for common SoCs:

Hence, for the Rock64, the serial device is ttyS2 (not ttyAMA0) and it uses a baud rate of 15000000 (not 115200). Again, other boards may need different settings.

So, in our case, change the line as follows:

T0:23:respawn:/sbin/getty -L ttyS2 1500000 vt100

Some devices (e. g. the A64-OLinuXino) require a different DTB file than the one included in the Debian kernel package. In this case, overwrite the existing dtb file in the bootfs partition (replace <platform> by your actual platform). Make sure you prevent your dtb file from being overwritten by kernel upgrades. Thus, once you booted the final system, adapt the file /etc/kernel/postinst.d/copy-dtbs accordingly. To copy the dtb file once:

cp /path/to/your/special/dtb-file /mnt/dtbs/<platform>/

Unmounting and cleanup

Sync and unmount the filesystems:

sync
umount /mnt/targetbootfs
umount /mnt/targetrootfs

Close the crypto device:

cryptsetup luksClose /dev/mapper/somename

Flash bootloader

As the last step, we need to write the bootloader to the device.

Warning: This procedure is SoC-specific! Other SoCs require different commands!

For our Rock64. do the following:

dd if=idbloader.img of=/dev/sdX seek=64 conv=notrunc
dd if=u-boot.itb of=/dev/sdX seek=16384 conv=notrunc
sync

Step 7: First boot

Bootup and first changes

That’s it! Hook up the serial console to your board, put in the microSD card and enjoy.

After bootup, I recommend to renegerate the SSH keys as follows:

rm -v /etc/ssh/ssh_host_*
dpkg-reconfigure openssh-server
rm /etc/dropbear/initramfs/*_key
dpkg-reconfigure dropbear-initramfs

Device-specific notes

Pinebook Pro

(under construction)

Other devices

(under construction)

Troubleshooting

(under construction)

External References

(The providers of these resources are solely responsible for them - see legal notice).

(none yet)

Credits

I would like to thank all the helpful minds that shared feedback on previous versions of this concept for prior Debian/Devuan versions.

History / Changelog

• [2025-12-29] Initial major rewrite for Debian 13 (based on earlier articles, see its changelog for details on past changes)

Comments

(Comment features are provided by external parties and are not monitored by me.)

Coming soon