kulesz.me

Recommended procedure for installing Debian GNU/Linux 13 (trixie) on ARM64-based machines

Mon, 29 Dec 2025 01:43:02 +0000

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:

Manufacturer	Make/model	Remarks
FriendlyElec	NanoPi R2S	to be tested, worked partially in the past, not tested on Debian 13 yet (observed in Debian 11: incompatible with certain microSD cards, shutdown issues, only one NIC recognized ootb)
Pine64	A64 Plus	to be tested, worked great in the past, not tested on Debian 13 yet
Pine64	A64 LTS (v1)	to be tested, worked great in the past, not tested on Debian 13 yet
Pine64	Rock64	Works very well
Pine64	RockPro64	to be tested, worked mostly in the past, not tested on Debian 13 yet
Pine64	Pinebook Pro	to be tested, Worked partially in the past, not tested on Debian 13 yet (observed in Debian 11: booting off microSD cards fails, reboot issues, manual extra work needed)
Pine64	H64 Model B	Works well (entering disk encryption password does not work over serial)
Olimex	A64-OLinuXino	Works well (entering disk encryption password does not work over serial)
Xunlong	OrangePi Zero Plus	Worked partially in the past, not tested on Debian 13 yet (observed in Debian 11: NIC does not work, external USB NIC works fine)

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:

SoC	serial device	Baud rate
Rockchip RK3328, RK3399	/dev/ttyS2	1500000
Allwinner A64, H5, H6	/dev/ttyS0	115200

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-20] 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

OsmAnd via Android Auto - a practical and privacy-friendly offline navigation solution?

Mon, 15 Aug 2022 15:40:02 +0000

Modern cars are equipped with headunits that support Android Auto or Apple Carplay. With the recently added support for Android Auto in OsmAnd - an established open source offline maps and navigation app - my hope for a privacy-friendly solution was reawaken. Hence, I investigated whether it was practically possible to use use this combination in a data-literate way. I stumbled over several caveats and irritating privacy-invasive issues but also found a semi-satifactionary workaround for the time being.

Targeted audience

If you are a person that has a stock Android smartphone with the preinstalled Google Apps and services running and is comfortable with this setup this article is NOT for you. On the other hand, if you use a custom Android Distribution such as LineageOS, GrapheneOS or Replicant or even a “true” Linux Mobile system such as postmarketOS, Mobian or Ubuntu Touch you are part of the targeted audience. Generally, I assume that readers of this article are data-literate, care about their privacy and want to effectively stay in control with whom they share which data.

Disclaimer

All data and information provided in this article is for informational purposes only. The author makes no representations as to accuracy, completeness, currentness, suitability, or validity of any information on this article 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.

Caveat #1: Google Apps (“gapps”) required

The first surprise for newcomers is that you can’t use Android Auto with a “free” Android distribution that was built from the components of the Android Open Source Project (“AOSP”) such as LineageOS, GrapheneOS or Replicant. Instead, Android Auto is part of the proprietary “gapps” framework and requires the installation of these proprietary components. This is sad since the major motivation for many users of “free” Android distributions is to avoid the installation of proprietary components.

The resulting practical consequence for a privacy-friendly setup is that a dedicated Android device solely for Android Auto needs to be used. While not ideal, plugging in a second device and using it for navigation via the headunit is still much more convenient than using an external device.

The additional Android device could be any stock Android device or a device running LineageOS plus “gapps”. However, unless you don’t already own a device with an outdated Android version that does not support Android Auto at all, I don’t see many benefits of such an setup. I rather find it legally and ethically problematic to install proprietary software from questionable sources on such a device.

Another noteworthy issue is that not only Android Auto’s implementation but even the protocol is not open. However, the protocol has been recently reverse-engineered by BlueWave Studio’s OpenAuto project [1].

Caveat #2: Additional “Playstore-only” apps required

In addition to the basic “gapps” framework, the installation of additional apps that are only available from the Google Play Store is required. These are:

Android Auto
Google App
Google Speech Services
Google Maps (what an irony…)

While “Google App” is already part of gapps, it will likely need to be updated to match the version of Android Auto. Unless you install all these apps before connecting your device with your car, the Android device will tell you that it can’t work with your car until these dependencies are satisfied. For privacy reasons, you better don’t want to ever go online with your Android device after your device was in touch with your car so better install these requirements beforehand.

So, the even bigger caveat here is that in order to use OsmAnd with Android Auto and need to have a Google Account to install these required apps.

And yes - in theory, you probably could also download these apps from “alternative” stores such as those that use the API of the Google’s Playstore to fetch the apk files using fake accounts. However, you will very likely violate Google’s terms and conditions and, in addition, you will eventually even commit a copyright infringement by doing so. See [2] for a more detailed discussion about using such stores.

Caveat #3: No hands-free phone calls while navigating

Maybe you already have a headunit in your car that allows you for hands-free calling using the built-in microphone and speakers over bluetooth? Unless you do not give permission to your smartphone for syncing your contacts list and calling history with the headunit in your car, such a solution might seem privacy-wise acceptable. Of course, you can never technically rule out that a head unit running proprietary software will not record the calling history or even your phone calls without your consent anyways. However, this would be certainly illegal in the EU and, hance, it depends on your personal level of paranoia whether you consider this a viable threat.

The more interesting question for me was whether you could navigate using OsmAnd via Android Auto and simultenously use hands-free calling to place or answer calls. The very bad news here is - you can’t - at least for the head unit I tried with! This is because Android Auto seems to use Bluetooth for Audio and assumes that you use the same device for calling as for phone calls. You need to first disconnect the additional (dedicated) Android Auto device in order to be able to use hands-free phone calls again.

Caveat #4: Tricky initial setup

In order to replicate my setup you need to do the following steps:

Get an Android device with gapps (I tested this using a device running Android 10 - be warned that Android 12 is known to have issues with OsmAnd and Android Auto at the time of writing).
Install adb on your computer.
Get access to the play store (create a Google Account).
Download the required apps mentioned in the section “Caveat #2”.
Optional: Unassociate the Google Account from your device and close the account.
Download the apk file for OsmAnd from the F-Droid store (from the F-Droid website directly, not using the F-Droid App!)
Enable developer mode and activate adb on your Android device
Install the OsmAnd app using the adb workaround described below (otherwise the OsmAnd icon will be missing in Android Auto and you won’t be able to use it!).
Start OsmAnd and download any maps and additional content (such as POIs) you require.
Disable wifi on your device (ideally with kill switches or another effective airgap method)

Due to an issue discussed in [3], the OsmAnd app needs to be installed using the following commands:

adb push net.osmand.plus_424.apk /data/local/tmp
adb shell pm install -i "com.android.vending" -r /data/local/tmp/net.osmand.plus_424.apk

Yes, this initial setup requires some work. But believe me that finding out what needs to be done here was even more work. ;-)

Caveat #5: Uncomfortable updates

So far so good for the initial setup. But what to do for updating maps or adding POIs without the risk of data leaks? Here are three suggestions:

download the updated content on another device (e. g. your main smartphone) and transfer the files manually over a wired connection (adb, rsync or friends)
setup a firewall that only allows connections to map and POI providers and download the content with the Android device sitting behind this firewall.
if you don’t update content frequently wipe the Android device and redo the initial setup (eventually in some scripted/automated way)

Please let me know if you have any better suggestions!

Conclusion and future perspectives

I find it highly irritating that car drivers are virtually forced into signing a contract with Google just to be able to use a car’s head unit via Android Auto for a 3rd party navigation app that does not need any Google service at all.

The described setup might seem like a messy and complicated workaround at first. Yet it is the best privacy-friendly solution I am aware of for the time being. I find this approach more convenient than attaching a second dedicated navigation system or using OsmAnd via some smartphone holder in the car instead of using the headunit which is actually there for this purpose.

Of course, the described setup has several drawbacks, the biggest one proabably being the bluetooth issue. To workaround the bluetooth issue, my recommendedation is to use the built-in hands-free calling when not navigating and to use an external bluetooth headset to cover the remaining situations.

I looked for better alternatives and found the AACS project by by Tomasz [4] that reimplements Android Auto for native Linux. AACS allows you to display the output of a Linux machine on the headunit and process input from the headunit’s touchscreen. I haven’t tested this approach yet but it sounds very promising. I hope true Linux Mobile apps will provide such a facility ootb in the near future. Even though I am not aware of any equivalent alternative to OsmAnd for Linux mobile systems yet, running OsmAnd via anbox using AACS instead of proprietary Android Auto client on a native Android device sounds like a great step in the right direction.

External References

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

[1] https://github.com/opencardev/openauto

[2] https://mrdatenschutz.de/aurora-store-datenschutz-google-play-client-legal/

[3] https://github.com/osmandapp/OsmAnd/issues/13514#issuecomment-1086203926

[4] https://opensource.com/article/20/12/android-auto-open-source

Credits

(none yet)

History / Changelog

[2022-08-15] Initial version

Comments

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

Recommended procedure for installing Debian GNU/Linux 11 (bullseye) on ARM64-based machines

Sat, 21 Aug 2021 16:30:02 +0000

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 (12 at the time of writing). 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. Apart from updating it for Debian GNU/Linux 11, I removed instructions for Devuan GNU+Linux to reduce the number of IFs and make the article simpler to follow (not because I discourage using Devuan GNU+Linux).

Why use official distributions?

Before we dwelve into details, let’s first discuss some basics. I often hear the argument that people want to solve basic stuff like installing the OS as quickly as possible and focus on the more interesting stuff 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. Sure, this might be irrelevant for a quick and dirty test setup. However, if 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:

Many 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.

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 the modern extlinux configuration of the u-boot bootloader (instead of the outdated binary format that is difficult to edit).

Unofficially supported machines

The current Debian GNU/Linux 11 (bullseye) release ships version 5.10 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, you might be able to run the official distribution of Debian on it.

Don’t worry too much about the name “unstable” - the kernels in Debian unstable are based on well-tested kernels from upstream and usually work well. They are updated frequently and, thus, receive security updates. While I consider them okay as a daily driver, they are not as stable as the kernels from the stable distribution.

Here is a small list of machines I tried this approach on using the current 5.10 kernel and U-Boot 2021.XX:

Manufacturer	Make/model	Remarks
Olimex	A64-OLinuXino	Works partially (entering disk encryption password does not work over serial)
Xunlong	OrangePi Zero Plus	Works partially (NIC does not work, external USB NIC works fine)
FriendlyElec	NanoPi R2S	Works partially (incompatible with certain microSD cards, shutdown issues, only one NIC recognized ootb)
Pine64	A64 Plus	Works great
Pine64	A64 LTS	Works great
Pine64	Rock64	not tested yet with Debian 11
Pine64	RockPro64	not tested yet with Debian 11
Pine64	Pinebook Pro	Works partially (booting off microSD cards fails, reboot issues, manual extra work needed)

Installation

You have a board that is at least unofficially supported by the unstable kernel (see previous section)? Great - let’s get our hands dirty!

In the following, I will assume you want to install Debian GNU/Linux 11 on a NanoPi R2S by FriendlyElec.

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 11 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

Disclaimer

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 mini ISO for arm64 from the following location:

https://deb.debian.org/debian/dists/bullseye/main/installer-arm64/current/images/netboot/mini.iso

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 mini.iso you downloaded previously as ISO and select “Debian Testing” as OS. Give the VM the default of 1.5 GiB of RAM 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 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
- Unside 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 sda3_crypt or similar - that’s just the name of crypto device but not the partition label!

After installing, the system should boot up fine and present you with a login shell. In case the installed system does not boot but you get stuck in the Tianocore EFI shell instead, see the troubleshooting section.

Step 2: Customizing the base system

sysvinit

First, install sysvinit package and reboot (you could see some errors, ignore them):

apt install 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, you can remove most of the systemd bits by installing install 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.

Some 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 recommend OpenBSD’s openntpd as it is very lightweight and has been developed with security in mind. To install it:

apt install openntpd

It should start and also run on the next boot. To initially update the clock (openntpd takes a lot of time otherwise):

ntpd -s -d

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)

Note: At the time of writing, the unstable distribution does not provide a newer kernel yet. Hence, you will have to wait a few days/weeks before following this approach would make much sense.

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

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

Remove GRUB

Remove the grub bootloader (we will not use it):

apt autoremove grub-efi-arm64 grub-common

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/config
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

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

Step 4: Creating tar archives

First, power down your VM:

poweroff

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

Mount the boot partition (the guided installation installs to the second partition by default) and create a tar archive with our bootfs and store it in our assets:

mount /dev/nbd0p2 /mnt
cd /mnt
tar cfvzp /home/youruser/assets/debian11-aarch64-bootfs.tar.gz .
cd
umount /mnt

Do the same for the rootfs as well:

cryptsetup luksOpen /dev/nbd0p3 someroot
mount /dev/mapper/someroot /mnt
cd /mnt
tar cfvzp /home/youruser/assets/debian11-aarch64-rootfs.tar.gz .
cd
umount /mnt
cryptsetup luksClose /dev/mapper/someroot

Finally, clean up:

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 swig gcc-aarch64-linux-gnu gcc-arm-none-eabi

Clone ARM’s Trusted-Firmware source repository:

git clone https://github.com/ARM-software/arm-trusted-firmware
cd arm-trusted-firmware

Checkout the latest stable tag (check with git tag, it was v2.5 at the time of writing):

git checkout v2.5

Compile the firmware:

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

Leave the build directory:

cd ..

Next, clone the u-boot repository:

git clone git://git.denx.de/u-boot.git

Change into its directory:

cd u-boot

Checkout the latest stable tag (again, check with git tag):

git checkout v2021.07

Create a symlink to the previously produced arm trusted firmware build (if you built for a different board, adapt the link):

ln -s ../arm-trusted-firmware/build/rk3328/release/bl31/bl31.elf bl31.elf

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

make CROSS_COMPILE=aarch64-linux-gnu- BL31=bl31.elf nanopi-r2s-rk3328_defconfig

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

make -j16 CROSS_COMPILE=aarch64-linux-gnu- BL31=bl31.elf all u-boot.itb

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 NanoPI R2s).

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

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

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:

NOTE: To make encryption more secure, set the value for --pbkdf-memory 256 64 MiB lower than the physical memory available on your target device.

cryptsetup luksFormat /dev/sdX3 --label=rootencrypted --pbkdf-memory 384
cryptsetup luksOpen /dev/sdX3 somename
mkfs.f2fs -l root /dev/mapper/somename

Mount the boot partition, extract the tar archive :

mount /dev/sdX2 /mnt
cd /mnt
tar xzvpf /home/youruser/assets/debian11-aarch64-bootfs.tar.gz .

cp /path/to/your/special/dtb-file /mnt/dtbs/<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.

Unmount the bootfs:

sync
cd
umount /mnt

Do the same for the rootfs:

mount /dev/mapper/somename /mnt
cd /mnt
tar xzvpf /home/youruser/assets/debian11-aarch64-rootfs.tar.gz .

Before we unmount it, take the chance to 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:

SoC	serial device	Baud rate
Rockchip RK3328, RK3399	/dev/ttyS2	1500000
Allwinner A64, H5, H6	/dev/ttyS0	115200

Hence, for the NanoPI R2s, 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

With that last change done, unmount the new rootfs

sync
cd /home/youruser/assets
umount /mnt
cryptsetup luksClose /dev/mapper/somename

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 NanoPI R2s. 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

I found that booting from sdcard did not work properly. Using eMMC instead works fine. Also, there are issues with u-boot and the display that have to be worked around.

u-boot

At the time of writing, there are three issues with u-boot that have to be kept in mind:

version v2021.10-rc4 is broken (does not recognize eMMC). Version v2021.07 works.
Debian does not work with preboot enabled (see below).

When compiling u-boot, comment out PREBOOT like this in pinebook-pro_defconfig:

# PREBOOT=y`

Display

In order to get the display working properly, you have to work with the device using the serial console. Add the following modules to initramfs:

cat <<'EOF'>>/etc/initramfs-tools/modules
analogix_dp
drm
drm_kms_helper
panel-simple
pwm_bl
pwm_rockchip
pwm_regulator
rockchipdrm
EOF

Afterwards, run the following:

update-initramfs -u -k all

In order to enter the LUKS password using your keyboard, add the following to the kernel APPEND line in /boot/extlinux/extlinux.conf:

console=tty0

Known issues

When rebooting the device, the screen output is garbeled.

Other devices

(under construction)

Troubleshooting

Boot stuck in UEFI shell

As of 2021-01-12, installations can become stuck in the Tianocore UEFI shell after the installation or when boot parameters of the VM are changed. The actual fault seems to be caused by nvram (the nvram file is written by libvirtd).

To fix this issue:

start the VM
When bumped into the EFI shell, type “exit” to get to the boot manager
Choose “Boot Maintenance Manager”
Choose “Boot Options”
Choose “Add Boot Option”
Select the presented boot option “No volume label …”
Select <EFI>
Select <debian>
Select grubaa64.efi
Press Enter to input the description
Enter some name (e.g. debian)
Select Save and commit changes
Select Change Boot order
Hit Enter
use the +/- keys to move the new entry up.
Select Commit changes and exit
Select Go back to main page
Use “F10” to save the changes
Select continue

External References

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

(none yet)

Credits

Last but not least, I would like to thank all the helpful minds in the official Devuan forums who helped me resolve various small issues I encountered when building up this concept.

History / Changelog

[2021-09-19] Added device-specific notes for the Pinebook Pro
[2021-08-21] Initial major rewrite for Debian 11 (based on earlier article, see its changelog for details on past changes)

Comments

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

Coming soon

HowTo: PINEBOOK Pro with Debian GNU/Linux 10 or Devuan GNU+Linux 3 using mainline kernel and u-boot

Tue, 05 Jan 2021 04:10:02 +0000

I have written this guide to outline how I finally managed to get the official version of Devuan GNU+Linux 3 or Debian GNU/Linux 10 installed on a PINEBOOK Pro. It shows how to achieve this using official mainline u-boot and kernel from upstream (no unofficial patches) and without using third-party repositories. However, it does use self-compiled (unpackaged) versions of u-boot and kernel as tweaking their default build configuration files is currently still required.

This is how the result looks like on my device:

Status

As of 2021-01-05:

Most basic functionality is there.
The display works but requires the official Debian kernel to be recompiled with one configuration parameter changed (covered in this guide).
Adjusting the display brightness using hotkeys does not work out-of-the-box (at least in LXQt).
The disk encryption password has to be entered either blindly on-device or using the serial console as the display turns on too late (during init instead of initramfs). If you you decide to enter the password on-device, boot messages will still be displayed on the serial console (but no password prompt).
The microSD functionality is broken (several kernel errors).
Using external video-out and wifi requires loading non-free blobs (the ones for wifi can be installed using official Debian packages from the non-free section). I am not sure whether this applies to bluetooth as well.
Reboots often result in garbled screen output. Therefore, to perform a reboot, it is advised to turn the device off and on again.
Using further deblobbed sources (e.g. Linux/Libre or cleaned trusted firmware) has not been tried.

Covered topics and goals

This guide builds upon my general guide for building Devuan GNU+Linux 3 or Debian GNU/Linux 10 for various ARM64 boards [1]. It basically adds steps which are specific for the PINEBOOK Pro. The goal is to supplement my general guide instead of copying it.

As the display does not work directly after installation, a working serial console connection to your PINEBOOK Pro is required. Alternatively, you could log in remotely using a USB-ethernet adapter or include the steps in the preparation, but these alternatives are not covered in this guide.

Caution: This guide is WORK-IN-PROGRESS (WIP) and has not been fully tested.

Disclaimer

Prepare the assets

Follow my general guide for installing Debian/Devuan on arm64 [1] but with the following deviations:

Step 2: Install the unstable kernel (it is marked as optional in the guide, however, the PINEBOOK Pro requires it).
Step 3: Do not install the ssh server and dropbear (unless you really want to).
Step 3: Do not delete your regular user (you don’t want to have just root on a laptop).
Step 5: This guide has been written using version tags v2.4 for the trusted firmware and v2020.10 for u-boot.
Step 5: When building u-boot, use the configuration file pinebook-pro_defconfig, but comment the line (PREBOOT=y) in it before building (obtained this hint from [2]). The configuration file resides in the configs subdirectory of u-boot.
Step 6 and 7: Skip these steps, as they differ substantially (this is what this guide is for).

Initial installation / flashing

As of now, the Linux kernel 5.10 shipped in Debian unstable has severe issues with microSD cards. Therefore, it is required to install a different OS on the PINEBOOK Pro first and flash our Debian/Devuan files from there.

Grabbing artifacts

First of all, copy the following artifacts from step 5 to a USB drive:

devuan-aarch64-bootfs.tar.gz
devuan-aarch64-rootfs.tar.gz
idbloader.img
u-boot.itb

Preparing Armbian

This guide assumes that the installation on the PINEBOOK Pro is done using Armbian. Therefore, download and flash Armbian as described on their website to a microSD card. Once you have Armbian running, connect to the internet (e. g. using wifi or an USB-Ethernet adapter).

Next, install additional packages:

apt install cryptsetup f2fs-tools sfdisk

Now, insert the USB drive with the files from step 5, mount it (if not done automatically) and change to the directory where it is mounted. We will refer to this path as /path/to/your/mounted/usb/drive/ in the rest of this guide.

Verifying disks (IMPORTANT)

Before we start flashing, verify using fdisk that mmcblk2 is your internal eMMC flash and mmcblk1 is the microSD card from where your Armbian is running:

fdisk -l

IMPORTANT: Do not execute the following steps if this is not the case!

Flashing

Wipe out the first sectors of the internal eMMC:

dd if=/dev/zero of=/dev/mmcblk2 bs=1M count=100
sync

Create a sfdisk template:

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

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

Partition the internal eMMC flash:

/sbin/sfdisk devuan3-rockpro64.img < sfdisk.template

Format the boot partition:

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

For the root partition, create an encrypted partition (choose a strong passphrase), unlock it, and format it using the f2fs filesystem:

cryptsetup luksFormat /dev/mmcblk2p3 --label=rootencrypted
cryptsetup luksOpen /dev/mmcblk2p3 somename
mkfs.f2fs -l root /dev/mmcblk2p3

Flash the boot partition:

mount /dev/mmcblk2p2 /mnt
cd /mnt
tar xzvpf /path/to/your/mounted/usb/drive/devuan-aarch64-bootfs.tar.gz .
sync
cd
umount /mnt

Flash the root partition:

mount /dev/mapper/somename /mnt
cd /mnt
tar xzvpf /path/to/your/mounted/usb/drive/devuan-aarch64-rootfs.tar.gz .

Change the following line in /mnt/etc/inittab (only required for Devuan, not for Debian):

#T0:23:respawn:/sbin/getty -L ttyAMA0 115200 screen
T0:23:respawn:/sbin/getty -L ttyS2 1500000 screen

In addition, uncomment the following lines in order to activate the regular consoles in /mnt/etc/inittab as well (again, this only applies to Devuan):

1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

Unmount the stuff:

cd /path/to/your/mounted/usb/drive/
umount /mnt
cryptsetup luksClose /dev/mapper/somename

Flash the bootloader and sync the contents:

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

Powering down

Shutdown down Armbian.
Remove the microSD card.

Intermediate test

Connect your serial console to the PINEBOOK Pro and another computer. Start your serial emulator and connect it. If you are using picocom and have only one USB-Serial device connected, the following should do:

picocom -b 1500000 /dev/ttyUSB0

Now, power on your PINEBOOK Pro and watch it boot. You should see u-boot and the kernel booting, then it should stop in initrd asking for the disk encryption password. Enter the password, let the boot finish and log in.

Getting the display to work

There are basically two reasons why the display does not work out-of-the-box:

Additional kernel modules need to be loaded (see [3]).
The configuration used by Debian to compile the Linux kernel sets a parameter that needs to be changed (see [4]).

Loading additional kernel modules

Add the required modules to the initramfs configuration:

cat <<'EOF'>>/etc/initramfs-tools/modules
analogix_dp
drm
drm_kms_helper
panel-simple
pwm_bl
rockchipdrm
EOF

And rebuild the initramfs:

update-initramfs -u

Recompiling the kernel

You can recompile the kernel either on the PINEBOOK Pro directly or on another machine running Debian/Devuan. I recommend the latter as it takes quite long on the device itself at heats it up which is not ideal for the battery.

No matter where you build, install the following packages:

apt install build-essential gcc-aarch64-linux-gnu git unzip bison flex libssl-dev bc pigz

Then grab the official Linux kernel source (use the current version and verify the download as described on kernel.org):

wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.4.tar.xz

Unpack the sources:

tar xvf linux-5.10.4.tar.xz

Copy the default Debian kernel config (if you are building externally, copy it to the machine where you are doing it):

cd linux-5.10.4
cp /boot/config-`uname-r` .

Edit the .config file and change the following line so its value is an empty string:

CONFIG_SYSTEM_TRUSTED_KEYS=""

Also change the setting CONFIG_ROCKCHIP_CDN_DP as follows:

# CONFIG_ROCKCHIP_CDN_DP is not set

In addition, I recommend adding some string to your kernel to make it better recognizable:

CONFIG_LOCALVERSION=".my01"

Also, change the following entry in the Makefile to significantly speed up packing when compilation ends:

#XGZIP = gzip
XGZIP = pigz

Start the build (on-device):

make -j6 bindeb-pkg

Or if you are building on a different device (change -j16 to match the number of the CPU threads you want to use, typically the maximum you have):

make -j16 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bindeb-pkg

After the build finishes, you should get the following Debian packages in the parent of the directory where you unpacked the kernel source (names will differ if you used a different kernel):

linux-headers-5.10.4.my01_5.10.4.my01-1_arm64.deb
linux-image-5.10.4.my01_5.10.4.my01-1_arm64.deb
linux-image-5.10.4.my01-dbg_5.10.4.my01-1_arm64.deb
linux-libc-dev_5.10.4.my01-1_arm64.deb

If you built the kernel externally, copy these files to your PINEBOOK Pro (otherwise you can use them directly). Install the kernel package (the other debs are only required for debugging and compiling additional modules):

dpkg -i linux-image-5.10.4.my01_5.10.4.my01-1_arm64.deb

Remove the currently installed kernel and the metapackage (otherwise updates could break your display again):

apt autoremove linux-image-`uname-r`

Check the symlinks in /boot/vmlinuz and /boot/initrd.img point to the newly installed kernel:

ls -l /boot

That’s it! Power down the PINEBOOK Pro (do not just reboot as this might cause garbled display output). Power the device back on, wait a bit and enter your drive encryption password using the serial console. After entering the password, your screen should finally turn on.

Remember: You are now running your device with a self-compiled kernel that gets no automatic updates. Make sure you download, build and install new kernel versions regularly so you don’t miss out on security updates!

Enter drive encryption password on-device

I did not succeed to persuade the display to turn on before the password prompt is shown. However, you can choose to enter the password “blindly” on-device. You will get boot messages on the serial console but the password will need to be entered on-device. To do this, add the following parameter in the append line to your /boot/extlinux/extlinux.conf line:

console=ttyS2,1500000 console=tty0

Power down the laptop, power it on, wait aprox 30 seconds and enter the password blindly to continue booting.

Increasing backlight brightness

Changing the brightness via hotkeys does not work ootb on the LXQt desktop. However, the brightness of the display’s backlight can be set to maximum via the following command as root:

echo 4095 > /sys/devices/platforms/edp-backlight/backlight/edp-backlight

The value 4095 is the maximum, you can also set a lower value of course.

Additional blobs for wifi and video-out

I discourage the use of non-free blobs and recommend using the PINEBOOK Pro with a ath9k-based USB wifi dongle instead. However, if there is interest I will update this section and add the necessary steps.

Credits

I would like to thank all the helpful minds in the official PINE64 forums (especially the users “toons”, “as400” and “schwarzwieweiss”) who pointed me to the principal solutions for some of the steps covered in this guide.

External References

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

History / Changelog

[2021-01-09] Added missing kernel config parameter (ROCKCHIP_CDN_DP)
[2021-01-07] Added photo, refined information about non-free blobs
[2021-01-05] Changed info about not being able to enter password on-device, added section how to achieve this, added section about display brightness
[2021-01-05] Posted in forums (PINE64 and dev1galaxy) and updated status, fixed mmcblk1 mention in section “Verifying disks”, fixed various small glitches
[2021-01-05] First publication

Comments

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

Please use the discussion forum thread in [4]. I will consider adding further options once this guide gets more mature.

Installing Devuan GNU+Linux or Debian GNU/Linux on ARM64-based SbCs that are not officially supported

Sun, 21 Jun 2020 21:30:02 +0000

If you want to self-host stuff at home using an ARM64-based board running Linux, both Debian GNU/Linux and Devuan GNU+Linux are excellent distribution choices. Unfortunately, they officially support only very few ARM64-based boards. Yet, you can run them unmodified on a lot more boards - if you manage to install them. After discussing some basics and showing how to check the support status for a particular board, this article describes my recommended way for performing the actual installation by a concrete example.

Why use official distributions?

Before we dwelve into details, let’s discuss some basic things first. I often hear the argument that people want to solve basic stuff like installing the OS as quickly as possible and focus on the more interesting stuff 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?

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

Many 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 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.

Unofficially supported boards

The Linux kernel supports a variety of ARM64-based boards. Unlike x86 machines, ARM64-based boards require a board-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 boards as possible by shipping dozens of dtbs. This is also true for Devuan since it uses Debian’s unmodified kernel.

The current OS versions (Debian 10 and Devuan 3) ship version 4.19 of the Linux kernel. To look them up the boards they theoretically support, 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-4.19.0-9-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 board is listed here, chances are good you will be able to run the official distribution of Debian or Devuan on it.

If your board 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 board is supported at least in the “unstable” release.

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

Here is a small list of boards I tried this approach on using the current 5.7 kernel and U-Boot 2020.07:

Manufacturer	Make/model	Remarks
Olimex	A64-OLinuXino	works (only kernel 4.9 works reliably, needs dtb from 5.4, see ¹)
Pine64	Rock64	works mostly (issues with USB 3)
Pine64	RockPro64	works partially, usable only from eMMC (issues with sdcard and USB 3)
Pine64	Pinebook Pro	works but requires extra steps as discussed in [4]
Xunlong	OrangePi Zero Plus	works

1: Use the stable kernel (4.9) but replace the DTB file with the one from 5.4 (otherwise ethernet is broken) and add the kernel commandline parameter console=ttyS0,115200 to disable the HDMI output. With HDMI output enabled and running newer kernels, the device hangs up as soon as the HDMI output turns the display off (after aprox one minute). Also, since Kernel 5.7, LUKS password prompts go to HDMI on this board and are not displayed on the serial console.

Installation

You have a board that is at least unofficially supported by the unstable kernel (see previous section)? Great - let’s get our hands dirty!

In the following, I will assume you want to install Devuan 3 on a RockPro64 by Pine64 [1]. You can also use this guide with small variations if you want to install Debian instead of Devuan or use a different hardware.

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, won’t have to redo them when installing other devices in the future.

Note: This concept borrows and enhances some ideas from my previous debootstrap-based approach.

Requirements and assumptions

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

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

In addition, you will need:

a dedicated physical x86 machine with a fresh installation of Debian GNU/Linux 10 or Devuan GNU+Linux 3 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

Disclaimer

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 mini ISO for arm64 from the following location:

https://pkgmaster.devuan.org/devuan/dists/beowulf/main/installer-arm64/current/images/netboot/mini.iso

IMPORTANT: Make sure you use a current mini.iso. Using an outdated one you downloaded in the past can lead to issues like the disk not being recognized in the installer.

If you want to have Debian instead of Devuan, use the following:

http://deb.debian.org/debian/dists/stable/main/installer-arm64/current/images/netboot/mini.iso

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 mini.iso you downloaded previously as ISO and select “Debian 10” as OS. Give the VM the default of 1 GiB of RAM 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.devuan.org as pkg mirror
partition the disk to have the following layout (watch my 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
- Unside 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).
regarding init, the approach should work with both sysvinit and openrc (choose what you prefer).

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

After installing, the system should boot up as shown here:

In case the installed system does not boot but you get stuck in the Tianocore EFI shell instead, see the troubleshooting section.

Step 2: Customizing the base system

Fix slow shutdowns

(only needed in Devuan)

Due to a bug in Devuan 3 you need to replace the cryptsetup-functions script as follows:

apt install --no-install-recommends wget ca-certificates
cd /lib/cryptsetup
mv cryptdisks-functions cryptdisks-functions.ORIG
wget https://git.devuan.org/devuan/cryptsetup-modified-functions/raw/branch/master/cryptdisks-functions

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 SbCs 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 board has a backup battery, it is a good idea to setup time synchronization.

apt install openntpd

It should start and also run on the next boot. In case you want to test it or sync manually, you can invoke it as follows:

ntpd -s -d

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 devuan

LABEL devuan
MENU LABEL Linux devuan
KERNEL /vmlinuz
INITRD /initrd.img
DEVICETREEDIR /dtbs
APPEND 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 in order for your board to work. In addition, some board features might work better with kernels from unstable.

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

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.devuan.org/merged 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

Remove GRUB

Remove the grub bootloader (we will not use it):

apt autoremove grub-efi-arm64 grub-common

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/config
DROPBEAR_OPTIONS="-p 4748 -I 60"
EOF

Remove the insecure dss certificate key automatically created by dropbear:

rm /etc/dropbear-initramfs/dropbear_dss_host_key

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

(only for Devuan) For a reason I yet have to investigate, the cryptroot-unlock scripts does not find the crypttab file in the initramfs and bails out with the message “Try again later”. As an ugly hotfix, edit the file /usr/share/cryptsetup/initramfs/bin/cryptroot-unlock and comment out the line that does the exit 1 command so it looks as follows:

# Too early, init-top/cryptroot hasn't finished yet
echo "Try again later" >&2
#exit 1

Finally, renegerate the initramfs:

update-initramfs -u

Configure the network

If you don’t want to use DHCP for the regular system either (recommended), make sure you edit /etc/network/interfaces accordingly.

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

Step 4: Creating tar archives

First, power down your VM:

poweroff

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/devuan-aarch64.qcow2

Mount the boot partition (the guided installation installs to the second partition by default) and create a tar archive with our bootfs and store it in our assets:

mount /dev/nbd0p2 /mnt
cd /mnt
tar cfvzp /home/youruser/assets/devuan-aarch64-bootfs.tar.gz .
cd
umount /mnt

Do the same for the rootfs as well:

cryptsetup luksOpen /dev/nbd0p3 someroot
mount /dev/mapper/someroot /mnt
cd /mnt
tar cfvzp /home/youruser/assets/devuan-aarch64-rootfs.tar.gz .
cd
umount /mnt
cryptsetup luksClose /dev/mapper/someroot

Finally, clean up:

qemu-nbd -d /dev/nbd0

Step 5: Building the bootloader

We build u-boot on the host machine.

Install dependencies:

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

Clone ARM’s Trusted-Firmware source repository:

git clone https://github.com/ARM-software/arm-trusted-firmware
cd arm-trusted-firmware

Checkout the latest stable tag (check with git tag, it was v2.3 at the time of writing):

git checkout v2.3

Compile the firmware (for other platforms, replace rk3399 - e. g. by rk3288 if you build for a Rock64 board):

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

Leave the build directory:

cd ..

Next, clone the u-boot repository:

git clone git://git.denx.de/u-boot.git

Change into its directory:

cd u-boot

Checkout the latest stable tag (again, check with git tag):

git checkout v2020.07

Create a symlink to the previously produced arm trusted firmware build (if you built for a different board, adapt the link):

ln -s ../arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf bl31.elf

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

make CROSS_COMPILE=aarch64-linux-gnu- BL31=bl31.elf rockpro64-rk3399_defconfig

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

make -j16 CROSS_COMPILE=aarch64-linux-gnu- BL31=bl31.elf all u-boot.itb

Save the assets:

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

Step 6: Assembling a device-specific image

With all goodies in place, we can now create a flashable image for your board. Unless you need more than four partitions I recommend sticking with a dead-simple MBR partition scheme instead of using GPT.

Alternatively, you can also write the installation to your flash media directly instead of creating an image as described here.

Before we start, let’s install kpartx:

apt install kpartx

First, change to our assets directory:

cd /home/youruser/assets

Create an image file for your device:

dd if=/dev/zero of=devuan3-rockpro64.img bs=1M count=4096

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 the disk image:

/sbin/sfdisk devuan3-rockpro64.img < sfdisk.template

Refresh the partition information:

kpartx -v -a devuan3-rockpro64.img

This should result in three devices (loop0p1 to loop0p3) showing up.

WARNING: Double-check this! If you have other active loop devices already, the following command might destroy your data!

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/mapper/loop0p2

For the root partition, we create an encrypted partition, unlock it, and format it using the f2fs filesystem:

cryptsetup luksFormat /dev/mapper/loop0p3 --label=rootencrypted
cryptsetup luksOpen /dev/mapper/loop0p3 somename
mkfs.f2fs -l root /dev/mapper/somename

Mount the boot partition, extract the tar archive :

mount /dev/mapper/loop0p2 /mnt
cd /mnt
tar xzvpf /home/youruser/assets/devuan-aarch64-bootfs.tar.gz .

cp /path/to/your/special/dtb-file /mnt/dtbs/<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.

Unmount the bootfs:

sync
cd
umount /mnt

Do the same for the rootfs:

mount /dev/mapper/somename /mnt
cd /mnt
tar xzvpf /home/youruser/assets/devuan-aarch64-rootfs.tar.gz .

Before we unmount it, take the chance to adjust the settings for the serial console (only needed for Devuan, in Debian systemd automatically figures out the serial device). To do that, edit the file /mnt/etc/inittab and adjust the following line:

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

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

In our case, change the line as follows:

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

With that last change done, unmount the new rootfs

sync
cd /home/youruser/assets
umount /mnt
cryptsetup luksClose /dev/mapper/somename

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 RockPro64. do the following:

dd if=idbloader.img of=devuan3-rockpro64.img seek=64 conv=notrunc
dd if=u-boot.itb of=devuan3-rockpro64.img seek=16384 conv=notrunc

Your image is now ready to be flashed.

Step 7: Flashing and final modifications

Flashing

To flash it to an microSD card (replace /dev/sdX by the actual device):

dd if=devuan3-rockpro64.img of=/dev/sdX bs=1M
sync

Bootup and first changes

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

WARNING: the next part was not tested!

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

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

And to regenerate the keys used by dropbear-initramfs (deleting the dss key again):

rm /etc/dropbear-initramfs/*_key
dpkg-reconfigure dropbear-initramfs
rm /etc/dropbear-initramfs/dropbear_dss_host_key
update-initramfs -u

Troubleshooting and device-specific workarounds

Generic

Boot stuck in UEFI shell

To fix this issue:

start the VM
When bumped into the EFI shell, type “exit” to get to the boot manager
Choose “Boot Maintenance Manager”
Choose “Boot Options”
Choose “Add Boot Option”
Select the presented boot option “No volume label …”
Select <EFI>
Select <debian>
Select grubaa64.efi
Press Enter to input the description
Enter some name (e.g. debian)
Select Save and commit changes
Select Change Boot order
Hit Enter
use the +/- keys to move the new entry up.
Select Commit changes and exit
Select Go back to main page
Use “F10” to save the changes
Select continue

PINEBOOK Pro

I published a separate article on that [4].

ROCKPro 64

Boot issues

When building u-boot in step 5, use the configuration file for the ROCKPro 64, but comment the line (PREBOOT=y) in it before building . There is more detail on this in the separate article about the PINEBOOK Pro as they share the same chipset. [4].

Dropbear timing issue

On this device there is a timing issue which leads to dropbear starting before the network is available. This can be worked around by editing the file /usr/share/initramfs-tools/scripts/init-premount/dropbear and adding the following line in the run_dropbear() method:

 sleep 10

Afterwards, rebuild the initramfs:

update-initramfs -u

Broken ethernet

Another issue on this device is that ethernet often does not work in the regular system although it worked in dropbear. This seems to be an issue with the driver. It can be worked around by creating a small script:

cat <<'EOF' > /root/fix-network.sh
#!/bin/bash
sleep 5
/sbin/rmmod dwmac_rk
sleep 1
/sbin/modprobe dwmac_rk
EOF

Then, make it executable:

chmod +x /root/fix-network.sh

And add the following line to cron:

@reboot /root/fix-network.sh

System fan not running

The system fan is not running while the system is waiting in dropbear to be decrypted. This can become a thermal issue if you are using the NAS case and have power-hungry hard drives installed.

TODO: Add instructions here

Broken PCIe

Due to various faults the ROCKPro 64 works unreliable with many PCIe cards/modules. In these cases, failures can be observed as SMP errors and kernel crashes. In addition, the link speed remains limited to PCIe gen1.

If you encounter these issues, you can try to recompile the dts file to enable gen2 support. However, some users report that this might work only on boards with revision 2.1 (although not all boards with this revision seem to be the same).

To do this, install the device tree compiler and wget:

apt install build-essential bison flex libssl-dev gcc-arm-linux-gnueabihf bc

Then, download the necessary bits:

wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.19.tar.xz
tar xvf linux-5.10.19.tar.xz
cd linux-5.10.19.tar.xz
make olddefconfig

Then, edit the file arch/arm64/boot/dts/rockchip/rk3399.dtsi and change the following line as described in the corresponding patch [5]:

max-link-speed = <2>;

Then recompile the dtbs:

make dtbs

And replace the dtb file (after backing up the original ones):

cp /boot/dtbs/rockchip/rk3399-rockpro64-v2.dtb /boot/dtbs/rockchip/rk3399-rockpro64-v2.dtb.ORIG
cp /boot/dtbs/rockchip/rk3399-rockpro64.dtb /boot/dtbs/rockchip/rk3399-rockpro64.dtb.ORIG
cp arch/arm64/boot/dts/rockchip/rk3399-rockpro64-v2.dtb /boot/dtbs/rockchip/
cp arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtb /boot/dtbs/rockchip/

Reboot the kernel and check if this works for you. If it does, copy the file to root’s home directory:

cd /root
mkdir dtbs-rockpro64
cp /boot/dtbs/rockchip/rk3399-rockpro64* .

Finally, add a corresponding line to your /etc/kernel/postinst.d/copy-dtbs script:

TODO: describe the line

Pine 64-LTS

Boot regression

A DTB change merged in March 2021 into the Linux kernel makes the Pine A64-LTS non-bootable (the non-LTS PINE A64 and A64+ are not affected). If you encounter this issue, use a static copy of the DTB files from the previous kernels.

Alternatively, you can download the kernel’s source code and change the following line in arch/arm64/boot/dts/allwinner/sun50i-a64-sopine.dtsi:

cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */

cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */

Then, recompile the dtbs and adapt your /etc/kernel/postinst.d/copy-dtbs script accordingly.

Credit for this fix goes to Andre Przywara who is maintaing the DTS files in the Linux kernel. I am in contact with him to get the fix upstreamed, so the A64-LTS will boot fine in the future again without the need for manual fixes.

External References

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

Credits

Last but not least, I would like to thank all the helpful minds in the official Devuan forums who helped me resolve various small issues I encountered when building up this concept.

Also, I would like to thank “n4tter4ngell” from the PINE64 forums who contributed the workaround for the dropbear issue on the ROCKPro 64.

History / Changelog

[2021-04-04] Add workaround for boot regression on A64-LTS boards
[2021-03-06] Added device-specific note regarding the fan and broken PCIe in rockpro64 boards
[2021-02-20] Marked cryptroot-unlock modifications as Devuan-only
[2021-01-28] Supplemented some labels in partitioning section
[2021-01-13] Added hint about uboot-issue in ROCKPro64, fixed @cron issue, removed “Disable the password for the root account”, add missing cd command
[2021-01-12] Replaced the previous workaround for the qemu/efi issue by a better solution
[2021-01-12] Added workaround for qemu/efi regression in Debian stable
[2021-01-09] Add section about device-specific workarounds, split credits and external references
[2020-10-31] Add partitioning video, fix misleading OS type and add hint about crypto device naming (all in step 1) and add warning about partially broken openntpd (in step 2)
[2020-07-30] Remove package grub-common as well (this saves around 18 MiB)
[2020-07-23] Disable instead of delete the root password; fix instructions for ssh key regeneration
[2020-07-18] Rework step 3 with several details, update OLinuxino-A64 status and tweaks
[2020-07-15] Major rewrite, now uses FDE with unencrypted boot
[2020-06-21] Initial writeup

Comments

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

Join the discussion on Mastadon (external resource)

Building a freedom-friendly wifi pocket-router

Sun, 19 Apr 2020 14:35:02 +0000

Installing and configuring operating systems on single-board computers can be painful when there is no nearby ethernet connection available. A pocket-router that provides wired internet access over an existing wireless network can help here. In this article, I discuss why I decided to build one myself and describe the particular steps conducted. Moreover, I also present measures regarding performance and power consumption.

Motivation

Reinventing the wheel is usually a bad idea. Therefore, I first looked for a ready-made wifi router that would meet my expectations:

the device should be as small as possible
the device should run only free firmware and software that is actively supported
it should be easy to configure the device on-the-go
the device should require low power and no dedicated wall plug (ideally it should be powered from an USB port of the “device-under-installation” or from a small power bank)
powering off the device should be safely possible by just pulling the power connector

With such high expectations set, it might not come as a big surprise that it was hard to find such a device. The closest match I came across was the “Free Software Wireless-N Mini VPN Router” from Thinkpenguin [1]. Unfortunately, I did not find a local retailer for this device. In addition, with just 16 megs of MTD flash and 64 megs of RAM this device is rather limited in terms of resources (but luckily not endangered in losing upstream support at the moment).

Since I had plenty leftover parts from other projects anyways, I decided against buying more stuff and for taking the self-building path. Another argument pro building such device yourself is that are a later free to easily switch hardware if you find that you require more performance.

Hardware

I selected the following hard- and software from my home inventory:

Xunlong OrangePi Zero [2] with small plastic case
old microSD card (even ancient cards with just 512 MB of storage would suffice)
Atheros-based USB-Wifi dongle with ath9k chipset such as [3]
OpenWRT [4] - this article is based on version 19.07.2

Please note that while the OrangePi Zero already provides on-board wifi, I decided against using it because (1) it requires non-free firmware, (2) it is not officially by OpenWRT, and, (3) performance and driver support seemed quite poor to me.

Ignoring the OrangePi Zero’s onboard-wifi, I am not aware of any non-free firmware or other binary blobs that would be required to operate the selected hardware. Therefore, it should also be possible to use LibreCMC instead of OpenWRT. Since LibreCMC does not provide any binary builds for this platform, I decided to stick with OpenWRT.

I would like to stress that there is absolutely no need to use the described hardware. If you already have an arbitrary single-board computer that is supported by OpenWRT and a compatible wifi dongle you should be perfectly fine. However, depending on the particular hardware, you might need to slightly adapt some of the described steps.

For the installation itself, you need some additional equipment:

a serial console (USB-TTL)
a computer capable of using the serial console to connect to the pocker-router
a terminal emulation program such as picocom [5]
a web browser
a LAN port in your router/firewall that serves IP addresses via DHCP and provides internet access

Disclaimer

Step 1: Installing OpenWRT

First of all, locate the OpenWRT image for your hardware using their website. Make sure to use the squashfs image and not the ext4 variant because otherwise your device will later lack the ability to be safely unplugged without additional steps.

The next step is to retrieve the particular OpenWRT image, check its hashsum and unpacked it. This is how it looked like on my OrangePi Zero:

wget https://downloads.openwrt.org/releases/19.07.2/targets/sunxi/cortexa7/openwrt-19.07.2-sunxi-cortexa7-sun8i-h2-plus-orangepi-zero-squashfs-sdcard.img.gz
sha256sum openwrt-19.07.2-sunxi-cortexa7-sun8i-h2-plus-orangepi-zero-squashfs-sdcard.img.gz
gunzip openwrt-19.07.2-sunxi-cortexa7-sun8i-h2-plus-orangepi-zero-squashfs-sdcard.img.gz

Now, the image can be written to an sdcard that is is connected to your computer (replace /dev/sdX by the actual device):

dd if=openwrt-19.07.2-sunxi-cortexa7-sun8i-h2-plus-orangepi-zero-squashfs-sdcard.img of=/dev/sdX bs=1M

Finally, take out the sdcard and you you should be ready for the next step.

Step 2: Adding USB wifi support

With the microSD card inserted, hook up the serial console to your pocket-router, start the terminal emulation program on the connected computer and attach the power connector to the pocket-router. You should see OpenWRT boot up. This is how it looked like in my case:

OpenWRT is optimized for size. Therefore, support for USB wifi devices is not enabled by default and requires the installation of additional packages. This is where things get a little tricky if your device device has only one ethernet port like mine. In this case, OpenWRT will configure the only ethernet port to be the LAN side of the network - leaving you without a WAN connection in the first place. Adding hardware such as USB ethernet adapters does not help since drivers for such devices are also missing from the default installation.

To install additional packages, we need to reconfigure the ethernet port temporarily to be used as WAN port via the serial console. Therefore, edit /etc/config/network and uncomment the whole LAN section. The resulting LAN section should look like this:

#config interface 'lan'
#        option ifname 'eth0'
#        option proto 'static'
#        option ipaddr '192.168.1.1'
#        option netmask '255.255.255.0'
#        option delegate '0'

With the LAN section neutralized, add a WAN configuration:

config interface 'wan'
       option ifname 'eth0'
       option proto 'dhcp'

And restart the network:

service network restart

Connect the ethernet port of your pocket-router to a any LAN port that provides internet access (typically the “normal” router you already use). Inspect the output of ip a and make sure you have internet access e. g. by using the ping command. With internet access established, we can update the package lists and download the modules required for our usb wifi dongle.

opkg update
opkg install kmod-ath9k-htc
opkg install wpa-supplicant

(If you want to use a wifi dongle with a different chipset, please replace the kmod-ath9k-htc package in the previous step acoordingly.)

Finally, revert the configuration changes (remove or comment the added wan section and uncomment the lan section) and restart the network once more:

service network restart

Step 3: Configuring the WAN side

The remaining steps are easy and should be self-explanatory for anyone who has setup OpenWRT to use the wifi as WAN connection before:

Connect your computer to the pocket-router and open OpenWRT’s web-based configuration page in your browser by pointing it to the URL of the administration page (http://192.168.1.1).
Log in using the empty password and make sure you set a new, strong password.
Navigate to “Network” -> “Wireless”. You should see at least one radio device here.
Click on the topmost “radio0” device and hit “Scan” to search for wireless networks.
Click on the button “Join netwoprk” next to the network you want to use.
Check the box “replace wireless configuration” and provide the connection parameters (typically your WPA passphrase).
hit “Submit” and then “Save” in the following screen.
Hit “Save & Apply”.

That’s it! You can now unplug the your pocket-router from its power line and disconnect the serial console. Plug your new pocket-router to the LAN port of your “computer-to-be-installed”, connect power (a USB port should be sufficient) and enjoy internet access!

Measurements

To check whether the pocket-router behaves as expected I conducted a few basic measurements.

Performance

The pocket-router is fully operational in less than 34 seconds (measured: from plugging in to getting the first ping response from a system on the WAN side).

To measure performance, I ran a speedtest using the service provided by nPerf [6] from a Lenovo Thinkpad X200 connected to the pocket-router. The “real” wifi router that provides 802.11n wireless service was located about 10 meters away in a different room with one wall inbetween. The speedtest reported a transfer speed of 46 MBit/s and a latency of 15 ms.

Power consumption

The pocket-router takes a little less than 1.5 Watts in idle mode (WAN and LAN connected but no traffic):

Under full load (when running a speed test) the power consumption did not increase when measuring downstream traffic. However, when uploading data, power consumption increased to around 2.5 Watts:

Final thoughts

A self-built pocket-router like the device described in this article can be quite handy - not only for my original use case. Building one yourself with OpenWRT is easy except for downloading the required packages when using a device that has just one LAN port. I hope that this article provided some help with that. Feedback is highly appreciated!

References

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

Comments

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

Join the discussion on Mastadon (external resource)

HowTo: Install Devuan 3 GNU+Linux (beowulf) base system on ARM via Debootstrap

Mon, 15 Jul 2019 02:37:00 +0200

This tutorial describes a method I developed to prepare and install a Devuan 3 (beowulf) base system for the armhf architecture. I should also work for arm64 and others with small modifications. Instead of building machine-specific images, I debootstrap a single unified build that can be used across numerous ARMv7 boards without rebuilding.

Of course, the build is still architecture-specific, so if you use arm64 or another architecture instead of armhf you will need to build a separate image.

Requirements and assumptions

To apply this tutorial you will need the following:

ARM board supported by the Linux Kernel 4.19. This tutorial assumes you have a 32bit (armhf) board. If your board has a different architecture (e.g. arm64) it should also work with slight modifications (not covered in this tutorial). Check the dtb files shipped by default with Debian in [1] and [2] to see if your board is supported. If your board is not listed there but supported by the Linux Kernel 4.19, it should still work, but you will have to obtain and add the dtb files yourself (not covered in this tutorial).
working u-boot image (preferably mainline) for your device that is not ancient (ability to boot kernels directly from ext4 partitions, support for extlinux.conf)
working serial console attached to your ARM board

Why not use the provided images on the Devuan mirrors?

there are no images for beowulf yet (installing ascii and upgrading is not what I wanted)
the images for ascii use a hard-coded, unmaintained kernel without any working concept for security updates
the images for ascii are shipped with proprietary blobs and the sources.list file includes non-free sources as well.
the images for ascii include packages not installed in the base setup that everybody might want (e.g. screen, openssh-server)
the images use ext4 for the root filesystem but I prefer using f2fs in order to reduce wear of my flash media.
the images for ascii use the old-style u-boot configuration (boot.scr and boot.cmd) that is hard to maintain.

Disclaimer

In no event, the author or this forum 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: Prepare environment

I strongly recommend to use a virtual machine with a live environment for preparation because this significantly lowers the risk of data loss in case of errors (e.g. if you specify the wrong device name in some command). In principle, you can use any environment that supports Debootstrap (even Alpine Linux).

I used a Debian 10 GNU/Linux Live CD. Using a Devuan GNU+Linux Live CD would make some things simpler, however, the current ascii Live CD has a severe unpatched apt vulnerability and thus, was not considered as an viable option.

Refresh the package index and install wget:

sudo apt update
sudo apt install wget

Download the Devuan keyring (check http://deb.devuan.org/devuan/pool/main/d/devuan-keyring/ for the latest version):

wget http://deb.devuan.org/devuan/pool/main/d/devuan-keyring/devuan-keyring_2017.10.03_all.deb

And install it:

sudo dpkg -i devuan-keyring_2017.10.03_all.deb

Install the necessary dependencies:

sudo apt install binfmt-support qemu qemu-user-static

Download devuan’s debootstrap (again, check for the latest version of it):

wget http://deb.devuan.org/devuan/pool/main/d/debootstrap/debootstrap_1.0.114%2Bdevuan1_all.deb

Install devuan’s debootstrap:

sudo dpkg -i debootstrap_1.0.114+devuan1_all.deb

Step 2: Create chroot

We will be doing the rest as root, so become root first:

sudo su -l

Create a directory for your chroot:

mkdir devuan_armhf_beowulf

Run debootstrap (might take a while):

qemu-debootstrap --arch armhf beowulf devuan_armhf_beowulf http://deb.devuan.org/merged/

After it finished, chroot into the environment:

chroot devuan_armhf_beowulf

Step 3: Customize chroot

Install the base locales:

apt install locales

Enable the default locale:

echo "en_US.UTF-8 UTF-8" >> /etc/locale.gen

And generate it:

locale-gen

Install the generic packaged kernel for armv7 systems:

apt install linux-image-armmp-lpae

Create a directory inside /boot to hold the device tree binary (dtb) files:

mkdir -p /boot/dtbs

Create a hook script that will copy over the dtb files each time a new kernel is installed:

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

set -e
version="$1"

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

And make it executable:

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

Call the script once to make sure it works and to initially copy over the current dtb files (replace 4.19.0-5-armmp-lpae by the current version at the time of installation):

/etc/kernel/postinst.d/copy-dtbs 4.19.0-5-armmp-lpae

Create extlinux dir (it will hold the configuration files the u-boot bootloader will use):

mkdir -p /extlinux

Create an initial extlinux config file (can be customized in the next step):

cat <<'EOF' >> /extlinux/extlinux.conf
TIMEOUT 20
PROMPT 1
DEFAULT devuan

LABEL devuan
MENU LABEL Linux devuan
KERNEL /vmlinuz
INITRD /initrd.img
DEVICETREEDIR /dtbs
APPEND root=/dev/mmcblk0p1
EOF

Activate the serial console (if your target machine has a console other than ttyS0 such as AMA0 adapt it):

echo "T1:12345:respawn:/sbin/agetty -L ttyS0 115200 vt100" >> /etc/inittab

Set the root password (use some generic default password, you will want to change it later anyways):

passwd

Remove the /data directory created by apt:

rm -rf /data

Step 3b (optional): Add f2fs support

Install the f2fs tools:

apt install f2fs-tools

Add the module to /etc/initramfs-tools/modules:

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

And regerate the initrd:

update-initramfs -u

Step 3c (optional): Add firmware

Depending on the devices you want to operate in your system it can be a good idea to install additional firmware. For instance, I am using ath9k-based USB devices so let’s add the open source firmware for it:

apt install firmware-ath9k-htc

Step 4: Pack

Exit the chroot:

exit

Change to the directory of the chroot and pack it:

cd devuan_armhf_beowulf
tar cfvzp /root/beowulf_armhf.tar.gz .

Now we have a nice tar.gz archive that can be used for deploying on the target machines. Fetch this archive from your live environment and put it in a safe place.

Step 5: Partition and flash

The system as we prepared it is suitable for flashing on a (micro) sdcard that contains everything in one partition with a ext4 filesystem. This is the most simple setup but has some disadvantages.

Having a separate boot partition is good if you want to sign and verify your boot chain (kernel, initrd, dtb) later. It also helps if your device has another storage (e.g. eMMC) that is not supported by the boot-loader - you can have /boot on your sdcard and use other devices for the root filesystem and the rest.

In the following, we will cover both variants.

WARNING: Make sure to change /dev/sdX in the following examples to match the actual device name of your sdcard!

But before we get to that, I suggest you first erase your sdcard so that you are sure there are no leftovers:

dd if=/dev/zero of=/dev/sdX

Furhermore, make sure /mnt/ is not mounted by inspecting the output of the following command (ideally, it would give no output):

mount|grep /mnt

(this tutorial will assume you can use /mnt as mount point in the following)

Variant 1: Single “all-in-one” ext4 partition

Create a MBR partition table and a single ext4 partition on your sdcard:

echo "o
n
p
1


w
" | fdisk /dev/sdX

Create an ext4 filesystem:

mkfs.ext4 -m0 /dev/sdX1

Mount it:

mount /dev/sdX1 /mnt

Change there:

cd /mnt

Unpack the rootfs:

tar xzvpf /path/to/your/beowulf_armhf.tar.gz

Add an fstab entry:

cat <<'EOF' >> etc/fstab
/dev/mmcblk0p1 / ext4 errors=remount-ro 0 0
EOF

Exit, sync and unmount:

cd /
sync
umount /mnt

Variant 2: Separate boot and root partitions

In this variant, we will use a small bootable ext4 partition to hold /boot and a bigger f2fs partition for the root filesystem on the rest of the sdcard. Create such a MBR partition table:

echo "o
n
p
1

+1G
n
p
2


a
1
w
" | fdisk /dev/sdX

Format the first filesystem as ext4 and the second one as f2fs:

mkfs.ext4 -m0 /dev/sdX1
mkfs.f2fs /dev/sdX2

Create directories for the mount points:

mkdir -p /tmp/mnt-boot
mkdir -p /tmp/mnt-root

Mount the filesystems:

mount /dev/sdX1 /tmp/mnt-boot
mount /dev/sdX2 /tmp/mnt-root

Extract the image to the root first:

cd /tmp/mnt-root
tar xzvpf /path/to/your/beowulf_armhf.tar.gz

Create the fstab file:

cat <<'EOF' >> etc/fstab
/dev/mmcblk0p1 /boot ext4 errors=remount-ro 0 0
/dev/mmcblk0p2 / f2fs defaults 0 0
EOF

Move contents that belong to boot contents and remove symlinks:

mv boot/* /tmp/mnt-boot/
rm -rf boot
mkdir boot
mv extlinux /tmp/mnt-boot/
rm initrd*
rm vmlinuz*

Recreate the symlinks (replace 4.19.0-5-armmp-lpae by the actual version):

cd /tmp/mnt-boot
ln -s vmlinuz-4.19.0-5-armmp-lpae vmlinuz
ln -s initrd.img-4.19.0-5-armmp-lpae initrd.img

Finally, change the entires in the extlinux configuration file:

sed -i "/DEVICETREEDIR/c\DEVICETREEDIR /dtbs" extlinux/extlinux.conf
sed -i "/APPEND/c\APPEND root=/dev/mmcblk0p2" extlinux/extlinux.conf

Exit, sync and unmount:

cd /
sync
umount /tmp/mnt-root
umount /tmp/mnt-boot

Step 6: Flash bootloader and boot

Finally, install your bootloader. This is board-specific, e.g. for an Allwinner-A20-based Cubietruck board you would do it as follows:

dd if=/path/to/your/u-boot-sunxi-with-spl-cubietruck.bin of=/dev/sdX bs=1k seek=8
sync

And that’s already it! Put the prepared sdcard in your device, hooks up your serial console and give it a try!

Step 7: Post-Installation

Now that you got your system booted, you probably want to do further configuration (specific for this installation) after booting:

change the root password
add additional user accounts
configure network
configure sources.list to include security-updates etc.
configure timezone settings
reconfigure locale
configure fstab, so filesystem is remounted read-only in case of a boot after a crash
install an ssh server
install your favorite packages

This tutorial does not cover these steps, however, I plan to create one that tackles these steps for any Debootstrap-based installations, soon.

External References

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

History / Changelog

[2019-07-15] Major rewrite, published on this site
[2019-04-14] Initial writeup posted in the Devuan forums

Comments

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

Join the discussion on Mastadon (external resource)

Looking for a functional and secure smartphone that runs only free software? Be patient!

Sun, 12 May 2019 08:30:10 +0000

Motivation

On many occasions, I have seen myself and other free software enthusiasts being asked which smartphones and mobile operating systems they can recommend to users who are looking for a free (owner-controlled) and secure smartphone that respects their freedom and privacy.

I would like to share some of my thoughts about this complex topic. However, please be warned, that it might be disappointing for those who might expect to get clear recommendations in the conclusion.

I have written an article on this topic back in spring 2018, but many things have changed since then. Therefore, I decided to conduct a major revision of said article here.

General freedom and security concerns

Before I’ll dive into specific operating systems and devices I would like to discuss some general issues with today’s mobile devices first.

Firmware vulnerabilities

If you run closed-source firmware (this is required to operate most smartphones today) you are the mercy of the vendor to provide you with updates. If you look at the Android Security bulletin, almost every month severe critical vulnerabilities in these firmwares need to be patched.

Unfortunately, many vendors refuse to provide updated firmware if they consider the affected devices are EOL. This is even true for extreme cases such as the “Broadpwn” exploit (affects BCM43xx wifi chipsets found on more than a billion of devices). This makes these devices de-facto eletronic waste and further worsens the environmental issues that pose a severe threat to our planet already today.

Bootloader freedom

Before an operating system can be booted, the hardware has to be initialized. This is usually done by one (or more) bootloaders. As far as I know, there are no modern smartphones (yet) that come preinstalled with a free bootloader or where the proprietary bootloader can be replaced. Few exceptions may be some (quite dated) devices such as the Nokia N900. Also, some partially successful attempts to install the free uboot bootloader on older devices such as the Samsung Galaxy S3 have been reported.

Hardware-backed security requires closed-source firmware

Modern SoCs come with a TEE (Trusted Execution Environment) as part of their chip design. These separate systems promise to securely process/store credentials such as fingerprints or (parts of) device encryption keys. I am not aware of any such subsystem that would be open source. Thus, the proper operation of such subsystems is near-impossible to audit for mere mortals (although the main developer of GrapheneOS claimed to have successfully done this in the past [1]).

Apart from trust and verifiability, using TEEs to store disk encryption keys usually comes at the price of not having separate PINs/passwords for the lockscreen and disk encryption key (like on newer Android devices). Therefore, you have to enter your most valuable credentials in “train conditions”. This is highly problematic since these credentials allow attackers to gain full access to the storage of your device once they get hold of it - even if it was at rest (completely powered off).

Modem isolation

Many modern SoCs do not have a clear separation between the baseband processor (that runs the non-free radio firmware) and the SoC. This means, that you actually have to trust the firmware of the baseband firmware vendor.

There is at least one known case of a backdoor built into the layer above that was detected on older Samsung devices and mitigated by Replicant developers [2].

Other partitions with non-free binaries and data

Some people may think that by re-flashing a ROM or factory image they return their device its “original state”. However, almost all modern smartphones contain a bunch of partitions that remain untouched during flashing. For instance, here is a listing of partition names and corresponding flash partitions from a Nexus 5:

It is hard to find documentation on what the purpose of these partitions is and, depending on the device, there are many different partitions. Also, for partitions that usually don’t change I haven’t seen any lists of hashes from OEMs. Therefore, if you buy a used phone you have to be aware that there is (1) no official way to reset these partitions to their factory state and (2) it’s hard to tell if any of these partitions have been modified. Most of these partitions can be modified if you have root access, therefore, if you ever executed something with root rights it could have tampered with one of those.

Inclusion Criteria and Covered Aspects

In the next section, I want to briefly discusses pros and cons of a few (partially) free mobile operating systems (skipping completely proprietary systems like iOS or Windows Phone). Both Android and non-Android-based systems will be discussed. However, near-dead projects like B2G/FirefoxOS will not be covered. Also, I excluded systems that require to pay license fees and extend free platforms by closed-source components (such as SailfishOS).

In the following, I’d like to focus on the following aspects:

choice and availability of supported devices
functionality
security hardening
verified boot with owner-supplied keys and free bootloader possible?
Modem isolation
inclusion of the non-free Google Apps
support period (both OS and firmware) and ease of updates
necessity for non-free components running with root privileges
availability of “first hand” factory images from the vendor
necessity to run non-free software on your computer in order to flash factory images

Android-based Operating Systems

Stock Android

This is the binary Android distribution from Google and comes pre-installed on Google Pixel devices (and Google Nexus devices).

Only available for quite pricey Pixel devices (available for older Nexus devices as well, but even the latest ones are EOL since January 2019)
Fully functional
Standard Android Security (not hardened), no root privileges for the user
Verified boot with locked closed-source bootloaders, owner-supplied keys not supported
Modem and SoC glued together on all supported devices (no proper modem isolation, if at all)
Google Apps and Services are pre-installed and not removable
Short support period (3 years from beginning of sales for each model), but clearly communicated; covers firmware updates as well (Google gets them from the firmware vendors and publishes them); Updates delivered once per month and easy to install
All supported devices require vast amounts of closed-source firmware
Factory images available directly from Google
No non-free software required on your computer in order to flash the system to a device

Vendor-modified Android

This is the Android distribution you will find on typical phones manufactured by OEMs like Samsung, HTC, LG, Sony, Huawei etc. These Android distributions are based on Stock Android but customized by the OEM and in case of “branded” devices also by the network operator.

Ultimate choice of devices in all price ranges
Fully functional
Standard Android Security (not hardened), no root privileges for the user (but can be easily obtained on many devices thanks to unpatched security holes)
Verified boot with locked closed-source bootloaders; security varies among bootloaders (many have severe issues so it is possible to unlock the bootloader without wiping user data, rendering this feature completely useless); I am not aware of any devices that allow to use owner-supplied keys
Modem and SoC glued together on most devices
Google Apps and Services are pre-installed and not removable.
Often very short and unclear support periods (depending on the vendor) and no formal EOL declaration (highly dependant on the OEM); often irregular, delayed or incomplete updates (e. g. do not include updated firmware, sometimes no updates at all: additional customizations by network operators often lead to further delay of updates; situation got slightly better for newer devices due to Google’s Trello project
I am not aware of any devices that do not require closed-source firmware (a few devices require “only a few megabytes” of non-free firmware, others require often around 100-200 MB)
Usually no factory images available from the vendor (depends on the vendor, but most of them do not provide them to end-users)
Flashing factory images (if available) usually requires non-free software by the OEM that in turn only runs only on non-free operating Systems such as Windows or OS X.

Android One

Meanwhile, several vendors also offer devices with “Android One” that promises to deliver a stock Android experience on non-Pixel devices coming from third-party vendors. These devices are mostly free from customizations (but may contain pre-installed apps).

Fair choice of devices, many are quite affordable
Standard Android Security (not hardened), no root privileges for the user
Verified boot with locked closed-source bootloaders, owner-supplied keys not supported
Modem and SoC glued together on all supported devices I know about (no proper modem isolation, if at all)
Google Apps and Services are pre-installed and not removable
Short support period (3 years from beginning of sales for each model) and usually hard to find for a specific device; Android updates and some firmware updates from Google (Google gets firmware updates for certain platforms from the vendors and publishes them each month); updates are easy to apply
I am not aware of any devices that do not require closed-source firmware (a few devices require “only a few megabytes” of firmware, others require often around 100-200 MB)
Factory images offered only by some vendors
Flashing factory images (if available) usually requires non-free software by the OEM that in turn only runs only on non-free operating Systems such as Windows or OS X.

Android Open Source Project (AOSP)

The source distribution of Stock Android

In theory, most devices that run vendor-modified Android or Android One should be able to run it — in practice, it is only feasible to use AOSP on Pixel and Nexus devices from Google as well as very few other devices (e.g. some devices from Sony’s “Open Devices Program”)
Fully functional for Google Nexus and Pixel devices (unfortunately not so for devices from vendors like Sony where functionality is often reported to be broken)
Verified boot with locked closed-source bootloaders and user-supplied keys (complicated to set up and very poorly documented, only possible on Pixel devices and two outdated Nexus devices)
Standard Android Security (not hardened), no root privileges for the user (option to build userdebug variant that allows for root but weakens security even worse)
Google Apps and Services are not included
Support period and updates are the same as for stock Android for Google devices; updates for other devices vary and often lack firmware updates; no binary builds available — has to be self-compiled by the user (very cumbersome, official instructions highly incomplete and error-prone — sometimes even require yet undocumented procedures due to changes in the build system)
All supported devices require vast amounts of closed-source firmware
No non-free software required on your computer in order to flash the system to a device

GrapheneOS

Security-oriented AOSP variant, recently relaunched as community project by the former CTO of CopperheadOS

Very limited device support (only Google Pixel devices supported at the moment)
Fully functional
Tightly hardened for security (includes kernel patches, a hardened browser and much more)
Verified boot with locked closed-source bootloaders and vendor-supplied keys; user-supplied keys are supported (complicated to set up but well-documented, requires recompilation)
Modem and SoC glued together on all supported devices (no proper modem isolation, if at all)
Google Apps and Services are not included
Support period and updates are the same as for stock Android; if you trust the project you can use the binary builds from their update site, making updates as easy as on stock Android
All supported devices require vast amounts of closed-source firmware
No non-free software required on your computer in order to flash the system to a device

Fairphone Open

Fairphone is an OEM that tries to build ethical and long-lasting devices. They have a great, vendor-friendly and forgiving “fanboy-style” community addicted to the honorable idea of the venture. With “Fairphone Open”, they also offer an AOSP-based system as alternative to their normal Vendor-modified Android distribution.

Only supported on the Fairphone 2
Fully functional (but releases sometimes introduce regressions)
Standard Android Security (not hardened), no root privileges for the user
Verified boot not supported; using Fairphone Open requires unlocked bootloader, bootloader itself is closed-source
Modem and SoC glued together on all supported devices (no proper modem isolation, if at all)
Google Apps and Services are not included
Support period and updates used to be regular but are lacking behind meanwhile; seems like the OEM does not receive firmware updates from the SoC vendor either, as firmware is from April 2018 and not updated anymore; installing updates is easy for end-users
around 180 MB of closed-source firmware required
No non-free software required on your computer in order to flash the system to a device

LineageOS

A custom Android distribution based on AOSP but with heavy modifications. Developed by a large community of volunteers. LineageOS also backports security patches to Android versions that are not supported by Google anymore (but only for a limited time)

broad device support, many devices that were EOL’d by their original vendors years ago are still supported
mostly functional (functional support varies strongly among devices)
includes some “privacy enhancements”, however, overall lower security than on standard Android due to userdebug builds
no verified boot supported (can be done manually for some Nexus/Pixel devices but quite hard and not documented at all)
Modem isolation varies among devices but typically non-existent
Google Apps and Services are not included by default
Support period and updates highly vary between devices; updates are frequent (even daily) but often delayed due to long review processes; updates often do not cover firmware and EOL periods are not announced beforehand (e .g.: I have one device from 2012 that still receives LineageOS updates, yet, its flawed firmware didn’t receive updates since 2014); updates are easy to apply for end-users
I am not aware of any devices that do not require closed-source firmware (a few devices require “only a few megabytes” of non-free firmware, others require often around 100-200 MB)
Usually, no non-free software required on your computer in order to flash the system to a device (there are exceptions though)

OmniROM

A custom Android distribution based on AOSP with moderate modifications. Developed by a community of volunteers. Similar to Lineage OS with respect to the discussed properties

limited device support (about half as good as in LineageOS)
mostly functional (functional support varies strongly among devices)
not hardened for security but slightly more secure than LineageOS due to “eng” builds by default
no verified boot supported (can be done manually for some Nexus/Pixel devices but quite hard and not documented at all)
Modem isolation varies among devices but typically non-existent
Google Apps and Services are not included by default
Support period and updates comparable to LineageOS in theory, however, many devices are EOL’d much sooner as only the most recent Android branch receives updates
I am not aware of any devices that do not require closed-source firmware (a few devices require “only a few megabytes” of non-free firmware, others require often around 100-200 MB)
Usually, no non-free software required on your computer in order to flash the system to a device (there are exceptions though)

Replicant

A custom Android distribution based on LineageOS 13. Developed by a tiny number of developers but strongly backed by many friendly and helpful free software enthusiasts. Progressing slowly due to lack of active developers.

only few very old devices are supported; the newest ones were popular six to seven years ago and can be easily obtained second-hand (well, rather third-hand or worse I suppose)
significantly degraded functionality; Features such as GPS, Bluetooth, GPU acceleration and Wifi are not available on any of the supported devices as no free drivers for them are available (wifi, bluetooth and gps can be used with the help of external devices via USB-OTG)
not hardened for security, provides insecure userdebug-builds with full root access
None of the supported devices support verified boot (all require an unlocked bootloader); Even with a locked bootloader, many of the supported devices have severe security issues (e.g. storage is directly accessible via the insecure odin protocol)
all devices have good signs of proper modem isolation (the project defined this aspect as important device evaluation criteria)
Google Apps and Services are not included
Irregular updates, security patches are often heavily delayed; firmware updates are irrelevant; if available, updates can be easily installed by end-users
All supported devices run completely without closed-source firmware on the main processor; non-free firmware that runs on auxiliary baseband processors is required for cellular connectivity (present in the flash of the devices already, not shipped as part of the distribution)
Factory-style images available but incomplete (they rely on closed-source bootloaders and firmware already present on the devices)
no non-free software required on your computer in order to flash the system to a device

UBPorts

Shortly after Canonical announced to discontinue their effort to port Ubuntu and its Unity desktop to their mobile OS named Ubuntu Phone, a community of volunteers emerged and created UBPorts to continue the project. The project uses only the lower layers of Android and builts a completely different UI on top (same approach as FirefoxOS has tried earlier).

supports around 13 devices, most of them rather dated (but a bit newer than those supported by Replicant)
slightly degraded functionality, most stuff seems to work
not hardened for security but probably still better than Android since many of its components known for never-ending security nightmares (such as the media framework) are not included
None of the supported devices supports verified boot (all require an unlocked bootloader)
Modem and SoC glued together on all supported devices (no proper modem isolation, if at all)
Google Apps and Services are not included (and not even supported)
Updates are frequent and continuously provided, but firmware updates are lacking; easy to install for end-users
I am not aware of any devices that do not require closed-source firmware (a few devices require less non-free firmware than others)
No non-free software required on your computer in order to flash the system to a device

Truly alternative, non-Android Operating Systems

There are at least three operating systems being developed that are true alternatives to Android because they are not based on Android. This is very promising, as these systems do not suffer from many of Android’s horrible design decisions and UNIX principle violations.

postmarketOS

A classic Linux distribution initially targeted at legacy smartphones that are considered obsolete by its vendors. Developed by volunteeers. Based on Alpine Linux (very lightweight). Tries to focus on devices with mainline Linux support instead of running badly outdated stock Android kernels.

nice and clear architectural design
classic distro packages instead of app store, daily updates
not really useable yet, under heavy development (but meanwhile a few devices have already limited support for calls and text messages)
emerging “support” for a large number of devices
choice between several UIs (most promising to me: Plasma Mobile), however, none of them seems Production-ready yet
verified boot with locked closed-source bootloaders and user-supplied keys theoretically possible (only on Nexus/Pixel devices) but not implemented yet.
all software available in the regular Alpine Linux repositories is available on postmarketOS as well.
free from systemd

Maemo Leste

Maemo Leste is another classic Linux distro for smartphones. It is based on Devuan GNU/Linux, targets also devices with Linux mainline support and works best on devices with keyboards.

supports only very old but still expensive devices such as the Nokia N900
already quite useable, mostly limited due to the low specs of the outdated hardware it supports
supports huge amounts of software because it is based on Devuan GNU/Linux which itself is based on Debian GNU/Linux (however, most of the available software was not designed for the tiny screens of the devices supported by Maemo Leste)
free from systemd

pureOS

Another “classic” Linux distribution, obviously targeted at “Librem” devices by Purism. Afaik based on a mix between Debian stable and Debian testing.

Convergence approach
Under heavy development (no real existing phone on which it can run)
Uses a homebrew app store named “PureOS Store”
No information about planned support period available yet
I haven’t read anything concrete about security features such as verified boot yet
based on GNOME, requires systemd

Promising devices announced for 2019

I know at least of three vendors that are trying to build devices that would offer great support for running non-Android mobile operating systems on them.

Librem 5

Back in mid-2018, a US-based company named Purism launched a crowdfunding campaign in order to manufacture a mobile device that would run their pureOS system. Meanwhile they shipped a few devkits, but the project is heavily delayed by several months. Here are some quick facts:

rather expensive (around 600 US dollars)
medium to high-end specs, fairly up-to-date i.MX 8 chipset
tries to use only libre-friendly hardware with good Linux mainline support (Vivante GPU, Atheros Wifi etc.)
isolated modem, implemented as add-on card (but not clear if it is also properly separated on the bus via IOMMU or similar isolation techniques)

It must be said that there are many critical voices towards Purism out there. Personally, I really appreciate that they stepped up to make the Librem 5. However, I wish their marketing would be more honest and - given the delay of their Librem 5 project - they would invest all of their energy in this thing instead of developing questionable stuff such as the Librem.One service platform. Sure, they want to deliver a product with a good usability, but I think that building the device itself is hard enough and should be accomplished first before spending resources on yet another app store or service platform.

Pinephone

Shortly before FOSDEM 2019, the chinese company named Pine64 (known for their SbCs and entry-level ARM laptops) announced to build a cheap low-end mobile phone. Their CEO showed off an impressive devkit at the booth and attracted a lot of developers. Meanwhile, the postmarketOS folks seem to have made great progress towards running their system on the devkit already.

rather expensive (around 150 US dollars)
well-known, mainlined Allwinner-SoC
isolated modem (but not sure yet)
uses Mali GPU (free driver for mainline is making good progress over the last months)
freedom-friendlieness of wifi (Realtek chip on devkit) and bluetooth devices unclear

Necunos

A company named “Necunos Solutions” from Finland aims to build a no-compromises freedom-friendly mobile device. Their philisophy seems to be perfectly aligned with other die-hard FOSS enthusiasts like those driving the Replicant project. They made a pre-order campaign for a device named Necunos NC1 that promises to deliver a hardened device for journalists and activists.

extremely pricey (> 1000 US dollars)
medium-level specs, based on rather old i.MX 6 chipset
no modem at all (yes - seriously!)
promise to make no compromises in terms of freedom-friendlieness

They recently posted an update regarding delivery delays of their device due to one of their partners backing down from providing them with the source code of some component (they didn’t name the component). Yet they hope to ship the device in summer 2019 to the people who pre-ordered them. Regarding the OS, they take a similar approach as Pine64, trying to convince one of the free projects (such as Replicant, postmarketOS or Maemo Leste) to support their device instead of reinventing the wheel.

Conclusion and recommendations

Given the current situation, providing clear recommendations is hard as it highly depends on a number of factors:

your willingness to run non-free software (esp. firmware)
your trust in particular SoC vendors
your threat perceptions (e.g. do you see more threats from local or from remote attackers?)
your willingness to wait (2019 could be the breakthrough of truly free Linux phones!)

My general recommendation is to find a temporary solution for now and to wait for one of the promising devices to become available instead of “inwasting” money in a recent Android device. Vote with your wallet and stop buying new Android devices full of non-free firmware that threatens your freedom and leads to an utterly low expected lifetime!

So, what could be your options for the meantime (in random order)?

get a used device supported by Replicant (Samsung Galaxy S2, Galaxy S3 or Galaxy Note 1), live with the degraded functionality and the devices’ trivial local exploitability. If you can, support development towards newer LineageOS versions to get OS-level security updates with less delays in the future.
get a used Pixel device and either build AOSP yourself every month for it or give GrapheneOS a try and donate money to the developer. You will be adequately secured from local and OS-level remote attacks by regular thieves etc. and you will get OS and firmware updates every month. However, you have to fully trust the SoC platform and its (non-isolated) baseband firmware. Hopefully, a real alternative will become available soon so you will not have to pollute the environment by switching to newer devices once your device runs out of support.
get one of the devices that is supported best by either postmarketOS, Maemo Leste or UBPorts and try to live with the limitations.
Recycle an old device and support postmarketOS and other free software projects to help growing a free alternative to Android.

I am really thrilled to see if 2019 will be finally the year of security and freedom on smartphones and other mobiles devices!

References

[1] Not available anymore, was: https://github.com/copperhead/bugtracker/issues/451
[2] https://www.fsf.org/blogs/community/replicant-developers-find-and-close-samsung-galaxy-backdoor

Comments

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

Join the discussion on Mastadon (external resource)

Site relaunch

Tue, 30 Apr 2019 21:15:00 +0000

Around three years ago, I started a blog using the FSFE’s member services. Last year in May, I took it down for various reasons. I am happy to announce that large parts of its content are now back online - in a fresh format!

Joined IndieWeb

One of the reasons to shut down my blog was my discontent with Wordpress, the technology used to enable FSFE’s supporters to share their thoughts. I evaluated various alternatives, and, finally, decided to turn the blog into a website using hugo. Apart from using different technology, a major goal for my new online presence was to become more independent by joining the IndieWeb [1] movement.

I support the awesome IndieWeb idea because I think that it is utterly needed these days. This phenomenon we used to know as “the web” was such a great achievement before it was ruined by the so-called walled gardens in the course of the last years. Luckily, each one of us can work towards restoring it to its old glory.

Some content still missing due to outstanding updates

Several articles are meanwhile outdated. Instead of reposting the archived versions of these articles, I decided to create major-updated versions for some of them and to re-post them as new articles (coming soon - stay tuned). This affects the following articles

“KVM virtualization with Allwinner A20 on Debian: libre, low-power, low-cost”
“KVM-virtualization on ARM using the virt machine type”
“Further securing Nexus devices running CopperheadOS by using separate Encryption/Lockscreen passphrases”
“Looking for a secure smartphone running only free software? Good luck!”

Ongoing styling

I am still in the progress of fine-tuning the visuals. Some content (like tables) are not rendered nicely yet, but I hope to improve that soon.

External References

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

[1] https://indieweb.org

Comments

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

Join the discussion on Mastadon (external resource)

How a single unprivileged app can brick the whole Android system

Tue, 10 Oct 2017 01:00:00 +0000

This article is highly subjective and only states the author’s opinion based on actual observations and “wild” assumptions. Unlike stated in the title, it might apply only to LineageOS and not to the original AOSP. Better explanations and corrections are warmly welcome!

Motivation

After updating an App from the F-Droid store (OpenCamera), my Android device was completely unusable. In this state, the only feasible option for a typical end-user to recover the device (who does not know how to get to safe mode in order to remove or downgrade the app [5]) would have been to wipe data in recovery, loosing all data.

How can such a disaster happen? In this article, I argue why I have serious doubts about the memory management approach taken in Android.

The failure

After updating the OpenCamera app to the recently released version 1.42, my Android device ran into a bootloop that was hard to recover from. I was able to repeatingly reproduce the failure on a different device, namely the following:

Device: Samsung Galaxy S3 (i9300)
ROM: Lineage OS 13 (Android 6.0), freshly built from latest sources, commit 42f4b851c9b2d08709a065c3931f6370fd78b2b0 [1]

Steps to reproduce:

Expected:

The install completes and the app is available. If installation fails (for whatever reason), an error message is shown but the device is still working

Actual:

The install freezes, the LineageOS splash screen appears and re-initializes all apps; this happens several times and after aprox 10-15 minutes the device is back “working”; when trying to start apps they crash or even the launcher (“Trebuchet”) crashes. After rebooting the device, it is stuck in an infinite loop initializing apps.

The fault (what happens under the hood?)

When installing OpenCamera, the following is printed in the log:

12-10 14:48:30.915  4034  5483 I ActivityManager: START u0 {act=org.fdroid.fdroid.installer.DefaultInstaller.action.INSTALL_PACKAGE dat=file:///data/user/0/org.fdroid.fdroid/files/Open Camera-1.42.apk cmp=org.fdroid.fdroid/.installer.DefaultInstallerActivity (has extras)} from uid 10070 on display 0
12-10 14:48:30.915  4034  5483 W ActivityManager: startActivity called from non-Activity context; forcing Intent.FLAG_ACTIVITY_NEW_TASK for: Intent { act=org.fdroid.fdroid.installer.DefaultInstaller.action.INSTALL_PACKAGE dat=file:///data/user/0/org.fdroid.fdroid/files/Open Camera-1.42.apk cmp=org.fdroid.fdroid/.installer.DefaultInstallerActivity (has extras) }
12-10 14:48:30.925  4034  5483 D lights  : set_light_buttons: 2
12-10 14:48:30.955  4034  5649 I ActivityManager: START u0 {act=android.intent.action.INSTALL_PACKAGE dat=file:///data/user/0/org.fdroid.fdroid/files/Open Camera-1.42.apk cmp=com.android.packageinstaller/.PackageInstallerActivity (has extras)} from uid 10070 on display 0
12-10 14:48:31.085  6740  6740 W ResourceType: Failure getting entry for 0x7f0c0001 (t=11 e=1) (error -75)
12-10 14:48:31.700  4034  4093 I ActivityManager: Displayed com.android.packageinstaller/.PackageInstallerActivity: +724ms (total +758ms)
12-10 14:48:36.770  4034  4362 D lights  : set_light_buttons: 1
12-10 14:48:36.840  4034  4938 I ActivityManager: START u0 {dat=file:///data/user/0/org.fdroid.fdroid/files/Open Camera-1.42.apk flg=0x2000000 cmp=com.android.packageinstaller/.InstallAppProgress (has extras)} from uid 10018 on display 0
12-10 14:48:36.850  3499  3895 D audio_hw_primary: select_output_device: AUDIO_DEVICE_OUT_SPEAKER
12-10 14:48:36.955  6863  6874 D DefContainer: Copying /data/user/0/org.fdroid.fdroid/files/Open Camera-1.42.apk to base.apk
12-10 14:48:37.100  4034  4093 I ActivityManager: Displayed com.android.packageinstaller/.InstallAppProgress: +251ms
12-10 14:48:37.155  6740  6753 D OpenGLRenderer: endAllStagingAnimators on 0x486226f0 (RippleDrawable) with handle 0x48604d28
12-10 14:48:37.170  4034  4100 W ResourceType: Failure getting entry for 0x7f0c0001 (t=11 e=1) (error -75)
12-10 14:48:37.465  4034  4100 I PackageManager.DexOptimizer: Running dexopt (dex2oat) on: /data/app/vmdl872450731.tmp/base.apk pkg=net.sourceforge.opencamera isa=arm vmSafeMode=false debuggable=false oatDir = /data/app/vmdl872450731.tmp/oat bootComplete=true
12-10 14:48:37.585  7205  7205 I dex2oat : Starting dex2oat.
12-10 14:48:37.585  7205  7205 E cutils-trace: Error opening trace file: No such file or directory (2)
12-10 14:48:42.405  7205  7205 I dex2oat : dex2oat took 4.815s (threads: 4) arena alloc=5MB java alloc=2023KB native alloc=13MB free=1122KB
12-10 14:48:42.415  4034  4100 D lights  : set_light_buttons: 2
12-10 14:48:42.680  4034  4100 V BackupManagerService: restoreAtInstall pkg=net.sourceforge.opencamera token=3 restoreSet=0
12-10 14:48:42.680  4034  4100 W BackupManagerService: Requested unavailable transport: com.google.android.gms/.backup.BackupTransportService
12-10 14:48:42.680  4034  4100 W BackupManagerService: No transport
12-10 14:48:42.680  4034  4100 V BackupManagerService: Finishing install immediately
12-10 14:48:42.705  4034  4100 W Settings: Setting install_non_market_apps has moved from android.provider.Settings.Global to android.provider.Settings.Secure, returning read-only value.
12-10 14:48:42.705  4034  4100 I art     : Starting a blocking GC Explicit
12-10 14:48:42.805  4034  4100 I art     : Explicit concurrent mark sweep GC freed 52637(2MB) AllocSpace objects, 20(424KB) LOS objects, 33% free, 14MB/21MB, paused 2.239ms total 96.416ms
12-10 14:48:42.835  4034  4363 I InputReader: Reconfiguring input devices.  changes=0x00000010
12-10 14:48:42.935  5420  5420 D CarrierServiceBindHelper: Receive action: android.intent.action.PACKAGE_ADDED
12-10 14:48:42.940  5420  5420 D CarrierServiceBindHelper: mHandler: 3
12-10 14:48:42.940  5420  5420 D CarrierConfigLoader: mHandler: 9 phoneId: 0
12-10 14:48:42.945  4034  4034 F libc    : invalid address or address of corrupt block 0x120 passed to dlfree
12-10 14:48:42.945  4034  4034 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xdeadbaad in tid 4034 (system_server)
12-10 14:48:42.950  3496  3496 I DEBUG   : property debug.db.uid not set; NOT waiting for gdb.
12-10 14:48:42.950  3496  3496 I DEBUG   : HINT: adb shell setprop debug.db.uid 100000
12-10 14:48:42.950  3496  3496 I DEBUG   : HINT: adb forward tcp:5039 tcp:5039
12-10 14:48:42.975  3496  3496 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
12-10 14:48:42.975  3496  3496 F DEBUG   : LineageOS Version: '13.0-20171125-UNOFFICIAL-i9300'
12-10 14:48:42.975  3496  3496 F DEBUG   : Build fingerprint: 'samsung/m0xx/m0:4.3/JSS15J/I9300XXUGMJ9:user/release-keys'
12-10 14:48:42.975  3496  3496 F DEBUG   : Revision: '0'
12-10 14:48:42.975  3496  3496 F DEBUG   : ABI: 'arm'
12-10 14:48:42.975  3496  3496 F DEBUG   : pid: 4034, tid: 4034, name: system_server  &gt;&gt;&gt; system_server &lt;&lt;&lt;
12-10 14:48:42.975  3496  3496 F DEBUG   : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xdeadbaad
12-10 14:48:43.030  3496  3496 F DEBUG   : Abort message: 'invalid address or address of corrupt block 0x120 passed to dlfree'
12-10 14:48:43.030  3496  3496 F DEBUG   :     r0 00000000  r1 00000000  r2 00000000  r3 00000002
12-10 14:48:43.030  3496  3496 F DEBUG   :     r4 00000120  r5 deadbaad  r6 404e0f38  r7 40005000
12-10 14:48:43.030  3496  3496 F DEBUG   :     r8 00000128  r9 bee01b0c  sl 40358be3  fp 40358bec
12-10 14:48:43.030  3496  3496 F DEBUG   :     ip 404db5d8  sp bee019f8  lr 404abfab  pc 404abfaa  cpsr 60070030
12-10 14:48:43.045  3496  3496 F DEBUG   : 
12-10 14:48:43.045  3496  3496 F DEBUG   : backtrace:
12-10 14:48:43.045  3496  3496 F DEBUG   :     #00 pc 00030faa  /system/lib/libc.so (dlfree+1285)
12-10 14:48:43.045  3496  3496 F DEBUG   :     #01 pc 000158df  /system/lib/libandroidfw.so (_ZN7android13ResStringPool6uninitEv+38)
12-10 14:48:43.045  3496  3496 F DEBUG   :     #02 pc 0001662b  /system/lib/libandroidfw.so (_ZN7android10ResXMLTree6uninitEv+12)
12-10 14:48:43.045  3496  3496 F DEBUG   :     #03 pc 00016649  /system/lib/libandroidfw.so (_ZN7android10ResXMLTreeD1Ev+4)
12-10 14:48:43.045  3496  3496 F DEBUG   :     #04 pc 00013373  /system/lib/libandroidfw.so (_ZN7android12AssetManager10getPkgNameEPKc+258)
12-10 14:48:43.045  3496  3496 F DEBUG   :     #05 pc 000133cf  /system/lib/libandroidfw.so (_ZN7android12AssetManager18getBasePackageNameEj+62)
12-10 14:48:43.045  3496  3496 F DEBUG   :     #06 pc 00088b33  /system/lib/libandroid_runtime.so
12-10 14:48:43.045  3496  3496 F DEBUG   :     #07 pc 72cb9011  /data/dalvik-cache/arm/system@framework@boot.oat (offset 0x1f78000)
12-10 14:48:50.095  3496  3496 F DEBUG   : 
12-10 14:48:50.095  3496  3496 F DEBUG   : Tombstone written to: /data/tombstones/tombstone_00
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'statusbar' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'netstats' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'power' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'media_projection' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'network_management' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'window' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'consumer_ir' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'telecom' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'cmpartnerinterface' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'package' died
12-10 14:48:50.185  1912  1912 I ServiceManager: service 'user' died

Since Open Camera needs some background service and is started on bootup, I assume that after installation the system tries to restart this service. However, it appears that there is some memory issue with the app, as it requests so much memory that Android starts killing other apps to make this memory available. In case Android does not manage to provide this space, the device is rebooted. Since OpenCamera is started at bootup, it again tries to allocate (too much) memory and the device is stuck in an infinite loop.

Looking at Android’s memory management

I expected that the following excerpt from the log above might lead to some useful hints:

12-10 14:48:42.945  4034  4034 F libc    : invalid address or address of corrupt block 0x120 passed to dlfree
12-10 14:48:42.945  4034  4034 F libc    : Fatal signal 11 (SIGSEGV), code 1, fault addr 0xdeadbaad in tid 4034 (system_server)

After searching on the net, I found an interesting discussion [2] suggesting the following:

“A likely cause of this is that you have ran out of memory, maybe because a memory leak or simply used up all memory. This can be caused by a bug you are using in a plugin that uses native C/C++ code through NDK.”

To rule out hardware issues, I also exchanged the storage (I run /data from sdcard) and compiled memtester [3] to test the device’s RAM. When experimenting with memtester, I noticed a striking difference between running memtester on a regular GNU/Linux system and running it on Android/LineageOS. When giving memtester less memory than actually available, there is no difference. However, when giving memtester more RAM than acutally available, the following happens on GNU/Linux:

# free -h
            total        used        free      shared  buff/cache   available
Mem:            28G        124M         28G        8.5M        219M         28G
Swap:            0B          0B          0B
# memtester 40G
memtester version 4.3.0 (64-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffffffffffff000
want 40960MB (42949672960 bytes)
got  29075MB (30488387584 bytes), trying mlock ...Killed
# 
Killed
[1]+  Stopped                 sh

While on Android the device suddenly reboots after trying to mlock the memory:

root@i9300:/ # free -h
                total        used        free      shared     buffers
Mem:             828M        754M         74M           0        1.3M
-/+ buffers/cache:           752M         75M
Swap:            400M         18M        382M

root@i9300:/ # /sbin/memtester 2G                                              
memtester version 4.3.0 (32-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffff000
want 2048MB (2147483648 bytes)
got  2008MB (2105921536 bytes), trying mlock ...</pre>
This is what is printed to logcat:
<pre>01-01 01:10:29.485  4933  4933 D su      : su invoked.
01-01 01:10:29.485  4933  4933 E su      : SU from: shell
01-01 01:10:29.490  4933  4933 D su      : Allowing shell.
01-01 01:10:29.490  4933  4933 D su      : 2000 /system/bin/sh executing 0 /system/bin/sh using binary /system/bin/sh : sh
01-01 01:10:29.490  4933  4933 D su      : Waiting for pid 4934.
01-01 01:10:44.840  2478  3264 D LightsService: Excessive delay setting light: 81ms
01-01 01:10:44.925  2478  3264 D LightsService: Excessive delay setting light: 82ms
01-01 01:10:45.010  2478  3264 D LightsService: Excessive delay setting light: 82ms
01-01 01:10:45.090  2478  3264 D LightsService: Excessive delay setting light: 82ms
01-01 01:10:45.175  2478  3264 D LightsService: Excessive delay setting light: 82ms
01-01 01:10:45.260  2478  3264 D LightsService: Excessive delay setting light: 82ms
01-01 01:10:45.340  2478  3264 D LightsService: Excessive delay setting light: 82ms
01-01 01:10:50.735  2478  2538 I PowerManagerService: Going to sleep due to screen timeout (uid 1000)...
01-01 01:10:50.785  2478  2538 E         : Device driver API match
01-01 01:10:50.785  2478  2538 E         : Device driver API version: 29
01-01 01:10:50.785  2478  2538 E         : User space API version: 29 
01-01 01:10:50.785  2478  2538 E         : mali: REVISION=Linux-r3p2-01rel3 BUILD_DATE=Tue Aug 26 17:05:16 KST 2014 
01-01 01:10:52.000  2478  2538 V KeyguardServiceDelegate: onScreenTurnedOff()
01-01 01:10:52.040  2478  2538 E libEGL  : call to OpenGL ES API with no current context (logged once per thread)
01-01 01:10:52.045  2478  2536 I DisplayManagerService: Display device changed: DisplayDeviceInfo{"Integrierter Bildschirm": uniqueId="local:0", 720 x 1280, modeId 1, defaultModeId 1, supportedModes [{id=1, width=720, height=1280, fps=60.002}], colorTransformId 1, defaultColorTransformId 1, supportedColorTransforms [{id=1, colorTransform=0}], density 320, 304.8 x 306.71698 dpi, appVsyncOff 0, presDeadline 17666111, touch INTERNAL, rotation 0, type BUILT_IN, state OFF, FLAG_DEFAULT_DISPLAY, FLAG_ROTATES_WITH_CONTENT, FLAG_SECURE, FLAG_SUPPORTS_PROTECTED_BUFFERS}
01-01 01:10:52.060  1915  1915 D SurfaceFlinger: Set power mode=0, type=0 flinger=0x411dadf0
01-01 01:10:52.160  2478  2538 I PowerManagerService: Sleeping (uid 1000)...
01-01 01:10:52.165  2478  3231 D WifiConfigStore: Retrieve network priorities after PNO.
01-01 01:10:52.170  1938  3241 E bt_a2dp_hw: adev_set_parameters: ERROR: set param called even when stream out is null
01-01 01:10:52.170  2478  3231 E native  : do suspend false
01-01 01:10:52.175  2478  3231 D WifiConfigStore: No blacklist allowed without epno enabled
01-01 01:10:52.190  3846  4968 D NfcService: Discovery configuration equal, not updating.
01-01 01:10:52.435  2478  3231 D WifiConfigStore: Retrieve network priorities before PNO. Max priority: 0
01-01 01:10:52.435  1938  1938 E bt_a2dp_hw: adev_set_parameters: ERROR: set param called even when stream out is null
01-01 01:10:52.440  2478  3231 E WifiStateMachine:  Fail to set up pno, want true now false
01-01 01:10:52.440  2478  3231 E native  : do suspend true
01-01 01:10:52.670  2478  3231 D WifiStateMachine: Disconnected CMD_START_SCAN source -2 3, 4 -&gt; obsolete
01-01 01:10:54.160  2478  2538 W PowerManagerService: Sandman unresponsive, releasing suspend blocker
01-01 01:10:55.825  2478  3362 D CryptdConnector: SND -&gt; {3 cryptfs getpw}
01-01 01:10:55.825  1903  1999 D VoldCryptCmdListener: cryptfs getpw
01-01 01:10:55.825  1903  1999 I Ext4Crypt: ext4 crypto complete called on /data
01-01 01:10:55.825  1903  1999 I Ext4Crypt: No master key, so not ext4enc
01-01 01:10:55.830  1903  1999 I Ext4Crypt: ext4 crypto complete called on /data
01-01 01:10:55.830  1903  1999 I Ext4Crypt: No master key, so not ext4enc
01-01 01:10:55.830  2478  2798 D CryptdConnector: RCV  {4 cryptfs clearpw}
01-01 01:10:55.835  1903  1999 D VoldCryptCmdListener: cryptfs clearpw
01-01 01:10:55.835  1903  1999 I Ext4Crypt: ext4 crypto complete called on /data
01-01 01:10:55.835  1903  1999 I Ext4Crypt: No master key, so not ext4enc
01-01 01:10:55.835  2478  2798 D CryptdConnector: RCV &lt;- {200 4 0}
01-01 01:10:55.925  3417  3417 D PhoneStatusBar: disable: 
01-01 01:10:56.020  3417  3417 D PhoneStatusBar: disable: 
01-01 01:10:56.330  3417  3417 D PhoneStatusBar: disable: 
01-01 01:11:44.875  2478  4667 I ActivityManager: Process com.android.messaging (pid 4607) has died
01-01 01:11:44.920  2478  4667 D ActivityManager: cleanUpApplicationRecord -- 4607
01-01 01:11:45.860  2478  3356 W art     : Long monitor contention event with owner method=void com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied() from ActivityManagerService.java:1359 waiters=0 for 907ms
01-01 01:11:45.890  2478  3356 I ActivityManager: Process org.cyanogenmod.profiles (pid 4593) has died
01-01 01:11:45.900  2478  3356 D ActivityManager: cleanUpApplicationRecord -- 4593
01-01 01:11:45.955  2478  2529 W art     : Long monitor contention event with owner method=void com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied() from ActivityManagerService.java:1359 waiters=1 for 914ms
01-01 01:11:45.960  1913  1913 E lowmemorykiller: Error opening /proc/3662/oom_score_adj; errno=2
01-01 01:11:45.970  2478  2529 I ActivityManager: Process com.android.exchange (pid 3662) has died
01-01 01:11:45.970  2478  2529 D ActivityManager: cleanUpApplicationRecord -- 3662
01-01 01:11:45.985  2478  3943 W art     : Long monitor contention event with owner method=void com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied() from ActivityManagerService.java:1359 waiters=2 for 611ms
01-01 01:11:45.995  2478  3943 I ActivityManager: Process com.android.calendar (pid 4415) has died
01-01 01:11:45.995  2478  3943 D ActivityManager: cleanUpApplicationRecord -- 4415
01-01 01:11:46.000  2478  2532 W art     : Long monitor contention event with owner method=void com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied() from ActivityManagerService.java:1359 waiters=3 for 537ms
01-01 01:11:46.025  2478  3362 W art     : Long monitor contention event with owner method=void com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied() from ActivityManagerService.java:1359 waiters=4 for 378ms
01-01 01:11:46.045  2478  3362 I ActivityManager: Process org.lineageos.updater (pid 4449) has died
01-01 01:11:46.045  2478  3362 D ActivityManager: cleanUpApplicationRecord -- 4449
01-01 01:11:46.045  1913  1913 E lowmemorykiller: Error writing /proc/3938/oom_score_adj; errno=22
01-01 01:11:46.050  2478  3413 W art     : Long monitor contention event with owner method=void com.android.server.am.ActivityManagerService$AppDeathRecipient.binderDied() from ActivityManagerService.java:1359 waiters=5 for 372ms
01-01 01:11:46.505  2478  3232 D WifiService: Client connection lost with reason: 4
01-01 01:11:47.165  2478  4666 D GraphicsStats: Buffer count: 3
01-01 01:11:47.400  2478  2532 W art     : Long monitor contention event with owner method=int com.android.server.am.ActivityManagerService.broadcastIntent(android.app.IApplicationThread, android.content.Intent, java.lang.String, android.content.IIntentReceiver, int, java.lang.String, android.os.Bundle, java.lang.String[], int, android.os.Bundle, boolean, boolean, int) from ActivityManagerService.java:17497 waiters=0 for 667ms
01-01 01:11:47.465  2478  4664 W art     : Long monitor contention event with owner method=int com.android.server.am.ActivityManagerService.broadcastIntent(android.app.IApplicationThread, android.content.Intent, java.lang.String, android.content.IIntentReceiver, int, java.lang.String, android.os.Bundle, java.lang.String[], int, android.os.Bundle, boolean, boolean, int) from ActivityManagerService.java:17497 waiters=1 for 858ms
01-01 01:11:47.465  2478  3412 W art     : Long monitor contention event with owner method=int com.android.server.am.ActivityManagerService.broadcastIntent(android.app.IApplicationThread, android.content.Intent, java.lang.String, android.content.IIntentReceiver, int, java.lang.String, android.os.Bundle, java.lang.String[], int, android.os.Bundle, boolean, boolean, int) from ActivityManagerService.java:17497 waiters=2 for 859ms
01-01 01:11:47.475  2478  4665 I ActivityManager: Process com.android.providers.calendar (pid 4434) has died
01-01 01:11:47.480  2478  4665 D ActivityManager: cleanUpApplicationRecord -- 4434
01-01 01:11:47.545  1913  1913 E lowmemorykiller: Error opening /proc/3938/oom_score_adj; errno=2
01-01 01:11:47.545  1913  1913 E lowmemorykiller: Error opening /proc/4014/oom_score_adj; errno=2
01-01 01:11:47.550  1913  1913 E lowmemorykiller: Error opening /proc/4542/oom_score_adj; errno=2
01-01 01:11:47.550  2478  3943 W art     : Long monitor contention event with owner method=int com.android.server.am.ActivityManagerService.broadcastIntent(android.app.IApplicationThread, android.content.Intent, java.lang.String, android.content.IIntentReceiver, int, java.lang.String, android.os.Bundle, java.lang.String[], int, android.os.Bundle, boolean, boolean, int) from ActivityManagerService.java:17497 waiters=3 for 894ms
01-01 01:11:47.560  2478  3943 I ActivityManager: Process org.cyanogenmod.themes.provider (pid 3497) has died
01-01 01:11:47.560  2478  3943 D ActivityManager: cleanUpApplicationRecord -- 3497
01-01 01:11:47.560  2478  2529 W art     : Long monitor contention event with owner method=int com.android.server.am.ActivityManagerService.broadcastIntent(android.app.IApplicationThread, android.content.Intent, java.lang.String, android.content.IIntentReceiver, int, java.lang.String, android.os.Bundle, java.lang.String[], int, android.os.Bundle, boolean, boolean, int) from ActivityManagerService.java:17497 waiters=4 for 673ms
01-01 01:11:47.570  2478  2529 I ActivityManager: Process com.svox.pico (pid 4014) has died
01-01 01:11:47.570  2478  2529 D ActivityManager: cleanUpApplicationRecord -- 4014
01-01 01:11:48.325  2478  2529 W ActivityManager: Scheduling restart of crashed service com.svox.pico/.PicoService in 1000ms

Verdict

I wasted lots of time with this issue, but was finally able to reproduce it and to recover all of my data. At least, I have an explanation now for various random reboots I experienced in the past in similar low-memory conditions.

Overall, I am really shocked that a simple, unprivileged Android app that is scheduled to start on bootup can ruin a working system so badly. Further research indicates that there are more apps known to cause such behavior [4]. I hope that a device based on a GNU/Linux system instead of Android (such as the announced Librem5) will not suffer from such a severe flaw.

External References

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

Benchmarking microSD cards and more

Sat, 20 May 2017 01:00:00 +0000

Motivation

If you ever tried using a flash drive (such a SD, microSD, USB drive or CF) for your root or home filesystem on a small computing device or smartphone, you probably have noticed that flash cards are in most cases a lot slower than integreted eMMC flash. Since most filesystems use 4k blocks, the random write/read performance using 4k blocks is what matters most in such scenarios. And while flash cards don’t come close to internal flash in these disciplines, there are significant differences between the models.

Jeff Geerling [1] [2] has already benchmarked the performance of various microSD cards on different models of the “blobby” Raspberry Pi. I had a number of different microSD cards at hand and I tried to replicate his results on my sample. In addition, I extended the comparison to regular SD cards and USB drives.

It is worth re-visiting this page as I am going to do more benchmarks and add more results over time.

Disclaimer

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 article.

Environment and tools

I encourage every reader to replicate my benchmarks and share their results. Therefore, I first want to describe how the measures were taken.

General equipment

For the benchmarks, I used the following hardware on my workstation (listing only relevant parts):

Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
Logilink CR0034A USB 3.0 card reader [5], used for (m)SD cards
Apacer ? USB 2.0 card reader, used for CF cards
Debian 9 “Stretch”

In the past, I also did iozone benchmarks using a Logilink CR0015 USB 2.0 (m)SD card reader [4] which are provided at the end of the article for reference.

iozone Benchmarks

For the first tests, Just like Jeff, I used the open source (but non-free) tool “iozone” [3] in the current stable version that is available on Debian Stretch (3.429).

I disabled caches and benchmarked on raw devices to avoid measuring filesystem overhead. Therefore, I used the following call to iozone to run the benchmarks:

$ iozone -e -I -a -s 100M -r 4k -r 16M -i 0 -i 1 -i 2 -f /dev/sdX

(replacing sdX by the actual device name)

ddrescue benchmarks

I used GNU ddrescue (1.21) in synchronous mode to overwrite a device with zeroes and measured the performance there. For this purpose, I used the following call to do a write benchmark:

$ ddrescue -D --force /dev/zero /dev/sdX

(replacing sdX by the actual device name)

Similarly, to measure the read performance I used (for media > 50G the test was aborted when 50G were reached; tmp was mounted as tmpfs):

$ ddrescue -D --force /dev/sdX /tmp/foo

(replacing sdX by the actual device name)

Results

iozone

Here are the iozone results (new card reader):

Manufacturer	Make/model	Type	Speed Class	Capacity	16M seq. read (MB/s)	16M seq. write (MB/s)	4K rand. read (MB/s)	4K rand. write (MB/s)
Sandisk	Ultra	mSDXC	A1	200 GB	42.75	36.80	8.54	5.13
Sandisk	Extreme	mSDXC	A2	64 GB	92.58	64.01	4.97	3.05
Sandisk	Ultra	mSDXC	A1	64 GB	93.26	31.88	7.67	2.84
Samsung	Evo+	mSDHC	U1	32 GB	89.30	25.88	10.07	3.77
Sandisk	Ultra	mSDHC	C10	64 GB	45.75	17.34	5.26	0.94

Here are the iozone results (old card reader):

Here are the results using the USB 3.0 card reader or the device directly (for usb drives):

Previously, I ran the iozone benchmarks using the USB 2.0 card reader. They might be relevant, if you are looking for a storage device which you want to put in a computing device with a slow card reader:

I can confirm Jeff’s results about microSD cards and would also recommend the Evo+ (both the old and the 2017 model) which have the best 4K random write performance of the sample. On the other hand, I am very disappointed about the Toshiba Exceria card. Actually running a device on this card with a very sluggish performance was the reason why I took this benchmark initiative. And indeed, after switching to the Evo+, the device feels much snappier now.

Of course, it would be worthwhile to add more cards and drives to this benchmark. Also, using fio instead of the non-free iozone might be interesting. Furthermore, doing the benchmarks internally on the device or using a other USB 3.0 card readers might be also interesting.

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

Backing up and restoring data on Android devices directly via USB

Wed, 02 Nov 2016 01:00:00 +0000

Motivation

I was looking for a simple way to backup data on rooted Android devices directly to a device running GNU/Linux connected over a USB cable (in my case, a desktop computer). In the following, I describe two ways how this can be accomplished.

Is this really so unique that it’s worth writing a new article about it? Well, in my case, I did not want to buffer the data on any “intermediate” devices such as storage cards connected via microSD or USB-OTG. Also, I did not want to use any proprietary tools or formats. Instead, I wanted to store my backups in “oldschool” formats such as dd-images or tar archives. I did not find a comprehensive howto for that, so I decided to write this article.

Disclaimer

In no event the author we 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 article.

Overview

This article describes two different approaches. Both have their pros and cons:

Block-level: Doing 1:1 block-level backups (above the file system) is an imaging approach that corresponds to doing dd-style backups.
Filesystem-level: Doing filesystem-level backups (on the file system) corresponds to tar-style backups.

An important factor when doing backups is also performance. Filesystem-level backups are usually faster on block devices which are only filled up to a small degree. However, due to the file system overhead they have a lower “raw” throughput rate — especially when backing up data on flash media such as microSD cards. Here, typical filesystems such as ext4 or f2fs operating with a 4K block size are a major bottleneck as these media often have horrible 4k write/read performance.

The following instructions for applying these approaches assume that you already have a “liberated” Android device which can boot into TWRP (a free Android recovery) or CWM. I am using the example of a Nexus-S running Replicant 4.2.0004 and TWRP 2.8.7.0, but the approaches also work with most other Android distributions and recoveries.

Getting familiar with the block devices on your Android device

First of all, you should know which block device you actually want to backup. The internal flash on Android devices is usually partitioned in about 15-25 partitions, depending on the device. To get a first overview, you can try the following (I am using adb shell on the desktop):

$ adb shell cat /proc/partitions

Example output:

major minor  #blocks  name

  31        0       2048 mtdblock0
  31        1       1280 mtdblock1
  31        2       8192 mtdblock2
  31        3       8192 mtdblock3
  31        4     480768 mtdblock4
  31        5      13824 mtdblock5
  31        6       6912 mtdblock6
 179        0   15552512 mmcblk0
 179        1     524288 mmcblk0p1
 179        2    1048576 mmcblk0p2
 179        3   13978607 mmcblk0p3
 179       16       1024 mmcblk0boot1
 179        8       1024 mmcblk0boot0

To find out what the partitions are about you can inspect the directory /dev/block/platform//by-Name/ which contains symlinks to the actual partitions. In my case, the Nexus-S has two flash chips and I am listing the partitions of the one where the userdata-partition resides on:

$ adb shell ls -l /dev/block/platform/s3c-sdhci.0/by-name

Example output:

lrwxrwxrwx root     root              2016-11-02 19:51 media -> /dev/block/mmcblk0p3
lrwxrwxrwx root     root              2016-11-02 19:51 system -> /dev/block/mmcblk0p1
lrwxrwxrwx root     root              2016-11-02 19:51 userdata -> /dev/block/mmcblk0p2

Please note that unlike the Nexus-S, most newer Android devices only have a single eMMC flash chip and don’t use MTD devices anymore.

Block-level approach

Block-level backups take up a lot of space (without compression) and extracting single files is cumbersome (especially when talking about encrypted data partitions or backups of the whole flash). On the other hand, “just” restoring a full backup is easy.

Backing up a single partition

Now that you know which block devices you want to backup, you can directly create a 1:1 image via adb pull as you would normally do by using dd. In our case:

$ adb pull /dev/block/platform/s3c-sdhci.0/by-name/userdata

Example output:

7942 KB/s (1073741824 bytes in 132.027s)

On your workstation, you will obtain a file named userdata which contains the whole partition/filesystem as an image. If you didn’t enable encryption on your Android device, you can directly mount this file as loopback device and access its contents:

$ mount userdata /mnt

Restoring a single partition

To restore your backup, you can simply use adb push. In my case:

$ adb push userdata /dev/block/platform/s3c-sdhci.0/by-name/userdata

However, since adb seems to put the file in RAM first before writing it to the target this only works if your partition fits in RAM. Otherwise, you are likely to get a message such as:

failed to copy 'userdata' to '/dev/block/platform/s3c-sdhci.0/by-name/userdata': No space left on device

One way to fix this is by using netcat. First, run the following on the receiver side (the phone):

# busybox nc -lp 5555 > /dev/block/platform/s3c-sdhci.0/by-name/userdata

And on the machine where you have stored your backup:

$ adb forward tcp:4444 tcp:5555
$ cat userdata | nc -q 2 localhost 4444

Optionally, you can also pipe the nc command through pv if you have this installed to get a nice progress bar:

$ cat userdata | pv | nc -q 2 localhost 4444

Alternative: Operating on the whole block device

Instead of backing up just a single partition, it is also possible to backup the whole flash device including all partitions. Example:

$ adb pull /dev/block/mmcblk0

Remarks:

On some devices, not all partitions are readable and, thus, cannot be backed up.
Please be careful with restores!
Accessing files inside this image is not straight-forward (but doable).

Filesystem-level approach

Filesystem-level backups only work for single partitions, take up as much space as the files on the particular filesystem you backup and it is easy to access individual files in them. I am using a combination of adb, netcat and tar to create and restore these backups.

Backing up your data

First, connect to your device via an adb shell:

$ adb shell

Then, change to the directory from where you want to create your backup. If your device was not automatically mounted, you have to do it first:

# mount /dev/block/platform/s3c-sdhci.0/by-name /data

Now change to this directory:

# cd /data

Now, start the netcat process:

# tar -cvp . | busybox nc -lp 5555

On the receiver side (desktop), set up adb port forwarding:

$ adb forward tcp:4444 tcp:5555

Then, start the process to receive the tar file:

$ nc -w 10 localhost 4444 > userdata.tar

You should see your files being packed up on the Android side:

./
./lost+found/
./dontpanic/
./misc/
./misc/adb/
./misc/audit/
./misc/audit/audit.log
...

Now wait for the process to exit.

Restoring your data

Again, on your receiver side (Android device), mount /data if it was not mounted yet and change in there:

# mount /dev/block/platform/s3c-sdhci.0/by-name /data
# cd /data

Now, start the tar extraction process:

# busybox nc -lp 5555 | tar -xpvf -

On the sender side (desktop), again, set up adb port forwarding:

$ adb forward tcp:4444 tcp:5555

And send the tar file:

$ cat userdata.tar | nc -q 2 localhost 4444

Now you should be able to see your previously backed up files getting restored…

History / Changelog

[2022-08-26] Add nc method to section about restoring single partitions so it works for larger partitions as well
[2016-11-02] Initial version

External References

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

For the filesystem-level part of the article I used and adapted the following sources:

About

Mon, 01 Jan 0001 00:00:00 +0000

This website

The purpose of this personal website is to share thoughts and experience with family and friends. Most content is related to technology and free software.

Contact

The best way to contact me is to drop me an e-mail:

kuleszdl@posteo.org
GPG fingerprint 1CBC E794 81ED 51EC 49FC  C064 0ACA DAB3 8FB6 4240

You can obtain my public key here.

Technology and Typography used

This site was built using Hugo [1] and the Indigo theme [2] by Angelo Stavrow [3].

It makes use of the following wonderful typefaces:

Fira Sans for heading text
Charter for body text
Fira Code for monospaced text

Licenses are included in the Indigo theme’s static/fonts folder.

External References

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

[1] https://gohugo.io/
[2] https://github.com/AngeloStavrow/indigo
[3] https://angelostavrow.com

Legal notice

Mon, 01 Jan 0001 00:00:00 +0000

Audience and authorship

This is a personal website that is adressed to family and friends of the author. For the sake of convenience, access to it is not technically restricted. The content was authored by:

Daniel Kulesz
kuleszdl@posteo.org

Trademarks and product names

All product names and trademarks are the property of their respective owners, which are in no way associated or affiliated with this website. Product names are used solely for the purpose of identifying the specific products. Use of these names does not imply any co-operation or endorsement.

Liability for content

The content on this website is not monitored permanently nor scanned for evidence that indicates illegal activities. Illegal content can only be removed or blocked given the knowledge about a specific violation. If you should encounter illegal content on this website, please use the contact information above to notify me. Illegal content will be removed as soon as possible after I become aware of it.

Liability for links

This website includes links to external websites and other content that is provided by third parties. Since I have no influence on these external ressources, no warranty about them can be made. Instead, the providers of these ressources are solely responsible for their content.

All links to external ressources have been checked at the time of linking and no reasonable indications of illegal content were detected. However, while it is impossible for me to monitor the content of these linked ressources, I will remove links to any illegal ressources as soon as possible once I become aware of them.

License

Unless stated otherwise, the textual content on kulesz.me created by the author is licensed under the Creative Commons Attribution-ShareAlike 4.0 International Public License (CC-BY-SA 4.0).

License

Mon, 01 Jan 0001 00:00:00 +0000

Creative Commons Attribution-ShareAlike 4.0 International Public License

By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this Creative Commons Attribution-ShareAlike 4.0 International Public License (“Public License”). To the extent this Public License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from making the Licensed Material available under these terms and conditions.

Section 1 – Definitions.

Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording, Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving image.
Adapter’s License means the license You apply to Your Copyright and Similar Rights in Your contributions to Adapted Material in accordance with the terms and conditions of this Public License.
BY-SA Compatible License means a license listed at [ creativecommons.org/compatiblelicenses][4], approved by Creative Commons as essentially the equivalent of this Public License.
Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including, without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to how the rights are labeled or categorized. For purposes of this Public License, the rights specified in Section 2(b)(1)-(2) are not Copyright and Similar Rights.
Effective Technological Measures means those measures that, in the absence of proper authority, may not be circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on December 20, 1996, and/or similar international agreements.
Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright and Similar Rights that applies to Your use of the Licensed Material.
License Elements means the license attributes listed in the name of a Creative Commons Public License. The License Elements of this Public License are Attribution and ShareAlike.
Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied this Public License.
Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the Licensor has authority to license.
Licensor means the individual(s) or entity(ies) granting rights under this Public License.
Share means to provide material to the public by any means or process that requires permission under the Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination, communication, or importation, and to make material available to the public including in ways that members of the public may access the material from a place and at a time individually chosen by them.
Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or succeeded, as well as other essentially equivalent rights anywhere in the world.
You means the individual or entity exercising the Licensed Rights under this Public License. Your has a corresponding meaning.

Section 2 – Scope.

License grant.
1. Subject to the terms and conditions of this Public License, the Licensor hereby grants You a worldwide, royalty-free, non-sublicensable, non-exclusive, irrevocable license to exercise the Licensed Rights in the Licensed Material to:
  1. reproduce and Share the Licensed Material, in whole or in part; and
  2. produce, reproduce, and Share Adapted Material.
2. Exceptions and Limitations. For the avoidance of doubt, where Exceptions and Limitations apply to Your use, this Public License does not apply, and You do not need to comply with its terms and conditions.
3. Term. The term of this Public License is specified in Section 6(a).
4. Media and formats; technical modifications allowed. The Licensor authorizes You to exercise the Licensed Rights in all media and formats whether now known or hereafter created, and to make technical modifications necessary to do so. The Licensor waives and/or agrees not to assert any right or authority to forbid You from making technical modifications necessary to exercise the Licensed Rights, including technical modifications necessary to circumvent Effective Technological Measures. For purposes of this Public License, simply making modifications authorized by this Section 2(a)(4) never produces Adapted Material.
5. Downstream recipients.
  1. Offer from the Licensor – Licensed Material. Every recipient of the Licensed Material automatically receives an offer from the Licensor to exercise the Licensed Rights under the terms and conditions of this Public License.
  2. Additional offer from the Licensor – Adapted Material. Every recipient of Adapted Material from You automatically receives an offer from the Licensor to exercise the Licensed Rights in the Adapted Material under the conditions of the Adapter’s License You apply.
  3. No downstream restrictions. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, the Licensed Material if doing so restricts exercise of the Licensed Rights by any recipient of the Licensed Material.
6. No endorsement. Nothing in this Public License constitutes or may be construed as permission to assert or imply that You are, or that Your use of the Licensed Material is, connected with, or sponsored, endorsed, or granted official status by, the Licensor or others designated to receive attribution as provided in Section 3(a)(1)(A)(i).
Other rights.
1. Moral rights, such as the right of integrity, are not licensed under this Public License, nor are publicity, privacy, and/or other similar personality rights; however, to the extent possible, the Licensor waives and/or agrees not to assert any such rights held by the Licensor to the limited extent necessary to allow You to exercise the Licensed Rights, but not otherwise.
2. Patent and trademark rights are not licensed under this Public License.
3. To the extent possible, the Licensor waives any right to collect royalties from You for the exercise of the Licensed Rights, whether directly or through a collecting society under any voluntary or waivable statutory or compulsory licensing scheme. In all other cases the Licensor expressly reserves any right to collect such royalties.

Section 3 – License Conditions.

Your exercise of the Licensed Rights is expressly made subject to the following conditions.

Attribution.
1. If You Share the Licensed Material (including in modified form), You must:
  1. retain the following if it is supplied by the Licensor with the Licensed Material:
    1. identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);
    2. a copyright notice;
    3. a notice that refers to this Public License;
    4. a notice that refers to the disclaimer of warranties;
    5. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
  2. indicate if You modified the Licensed Material and retain an indication of any previous modifications; and
  3. indicate the Licensed Material is licensed under this Public License, and include the text of, or the URI or hyperlink to, this Public License.
2. You may satisfy the conditions in Section 3(a)(1) in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. For example, it may be reasonable to satisfy the conditions by providing a URI or hyperlink to a resource that includes the required information.
3. If requested by the Licensor, You must remove any of the information required by Section 3(a)(1)(A) to the extent reasonably practicable.
ShareAlike.

In addition to the conditions in Section 3(a), if You Share Adapted Material You produce, the following conditions also apply.

1. The Adapter's License You apply must be a Creative Commons license with the same License Elements, this version or later, or a BY-SA Compatible License.
2. You must include the text of, or the URI or hyperlink to, the Adapter's License You apply. You may satisfy this condition in any reasonable manner based on the medium, means, and context in which You Share Adapted Material.
3. You may not offer or impose any additional or different terms or conditions on, or apply any Effective Technological Measures to, Adapted Material that restrict exercise of the rights granted under the Adapter's License You apply.

Section 4 – Sui Generis Database Rights.

Where the Licensed Rights include Sui Generis Database Rights that apply to Your use of the Licensed Material:

for the avoidance of doubt, Section 2(a)(1) grants You the right to extract, reuse, reproduce, and Share all or a substantial portion of the contents of the database;
if You include all or a substantial portion of the database contents in a database in which You have Sui Generis Database Rights, then the database in which You have Sui Generis Database Rights (but not its individual contents) is Adapted Material, including for purposes of Section 3(b); and
You must comply with the conditions in Section 3(a) if You Share all or a substantial portion of the contents of the database. For the avoidance of doubt, this Section 4 supplements and does not replace Your obligations under this Public License where the Licensed Rights include other Copyright and Similar Rights.

Section 5 – Disclaimer of Warranties and Limitation of Liability.

Unless otherwise separately undertaken by the Licensor, to the extent possible, the Licensor offers the Licensed Material as-is and as-available, and makes no representations or warranties of any kind concerning the Licensed Material, whether express, implied, statutory, or other. This includes, without limitation, warranties of title, merchantability, fitness for a particular purpose, non-infringement, absence of latent or other defects, accuracy, or the presence or absence of errors, whether or not known or discoverable. Where disclaimers of warranties are not allowed in full or in part, this disclaimer may not apply to You.
To the extent possible, in no event will the Licensor be liable to You on any legal theory (including, without limitation, negligence) or otherwise for any direct, special, indirect, incidental, consequential, punitive, exemplary, or other losses, costs, expenses, or damages arising out of this Public License or use of the Licensed Material, even if the Licensor has been advised of the possibility of such losses, costs, expenses, or damages. Where a limitation of liability is not allowed in full or in part, this limitation may not apply to You.
The disclaimer of warranties and limitation of liability provided above shall be interpreted in a manner that, to the extent possible, most closely approximates an absolute disclaimer and waiver of all liability.

Section 6 – Term and Termination.

This Public License applies for the term of the Copyright and Similar Rights licensed here. However, if You fail to comply with this Public License, then Your rights under this Public License terminate automatically.
Where Your right to use the Licensed Material has terminated under Section 6(a), it reinstates:
1. automatically as of the date the violation is cured, provided it is cured within 30 days of Your discovery of the violation; or
2. upon express reinstatement by the Licensor. For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License.
For the avoidance of doubt, the Licensor may also offer the Licensed Material under separate terms or conditions or stop distributing the Licensed Material at any time; however, doing so will not terminate this Public License.
Sections 1, 5, 6, 7, and 8 survive termination of this Public License.

Section 7 – Other Terms and Conditions.

The Licensor shall not be bound by any additional or different terms or conditions communicated by You unless expressly agreed.
Any arrangements, understandings, or agreements regarding the Licensed Material not stated herein are separate from and independent of the terms and conditions of this Public License.

Section 8 – Interpretation.

For the avoidance of doubt, this Public License does not, and shall not be interpreted to, reduce, limit, restrict, or impose conditions on any use of the Licensed Material that could lawfully be made without permission under this Public License.
To the extent possible, if any provision of this Public License is deemed unenforceable, it shall be automatically reformed to the minimum extent necessary to make it enforceable. If the provision cannot be reformed, it shall be severed from this Public License without affecting the enforceability of the remaining terms and conditions.
No term or condition of this Public License will be waived and no failure to comply consented to unless expressly agreed to by the Licensor.
Nothing in this Public License constitutes or may be interpreted as a limitation upon, or waiver of, any privileges and immunities that apply to the Licensor or You, including from the legal processes of any jurisdiction or authority.

The text of this license has been obtained from [1].

External Resources

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

[1] https://creativecommons.org/licenses/by-sa/4.0/legalcode

Privacy Policy

Mon, 01 Jan 0001 00:00:00 +0000

PLEASE NOTE: Unlike other content on this website, the following text is NOT licensed under the CC-BY-SA 4.0 license!

Overview

The following gives a simple overview about what happens to personal information (any data that could be used to personally identify you) that is transmitted when you visit my website.

Party responsible for this website

The party responsible for processing data on this website is (me):

Daniel Kulesz
kuleszdl@posteo.org

I am the natural person who alone or jointly with others decides on the purpose and means of processing personal data (names, email addresses, etc.).

General

As the operator of this website, I take the protection of your personal data seriously. Thus, all personal data is used in accordance to applicable data protection regulations and this privacy policy.

Please note that data transmitted over the internet (e.g. between your device and this website or via e-mail) may be subject to security breaches. Complete protection of your data from third-party access is impossible.

If you access this website, you transfer data to my web server via your client (typically your web browser). The following data is recorded whilst a connection is established:

IP address of the accessing computer
Date and time of the access
Name, URL and transferred data quantity of the accessed file
Access status (requested file transferred, not found etc.)
Browser type and operating system (only if not turned off in your web browser)
Website from which the access took place (if transferred by your web browser)

The temporary storage of the IP address in the memory of my webserver is necessary in order to deliver the website to your device. This storage is automatically emptied once the session has expired.

The webserver also logs all accesses in a permanent logfile to ensure the security of the IT systems that I operate to provide this website. The data stored in the log files is anonymized after seven days by shortening the IP addresses.

The processing of the data in this log file takes place as follows:

The log entries are randomly evaluated in order to recognize attacks against the web server.
In individual cases, i.e. in case of reported disruptions, errors and security breaches, a manual analysis is conducted.

IP addresses contained in the log entries are not combined with other data inventories unless required by law, i.e. if relevant authorities and/or courts make valid inquiries to which I am obliged to respond. Also, I reserve the right to share the log files with investigative bodies of the state (for example the police, criminal prosecution authorities) in case attacks on my IT systems are detected.

The legal basis is Article 6 Paragraph 1 Letter f) GDPR.

SSL/TLS encryption

To enhance security and privacy, this website is only reachable using SSL or TLS encryption. This makes it harder - but not necessarily impossible - for unauthorized third parties to read the data that is transmitted between this website and your device.

No use of Cookies

This website does not use cookies.

No use of Plugins

This website uses only HTML, CSS and JavaScript and does not require the use of any browser plugins.

No use of external Data Analytics or other third party services

The data transmitted to this website is not shared with third parties such as external data analytics providers. Instead, all data analytics of log files are conducted on devices that are operated by the author.