#raspberry #homelab #debian #qemu

I needed a virtual host to test Ansible scripts for my Raspberry Pi in the home lab. I found my way around this task by reading through the many great posts and examples online.

Extract kernel and device tree

First, you have to get the image (in my case, I used a modified build of the bookworm image) and extract the “kernel” and the “device tree” (to be honest, this was new for me when I read about this today).

We do this by mounting the boot partition and extracting the relevant files.

# Check image partitions
$ fdisk -l ./HashiPi-pi0.img

Setup loop device with image, scan partitions. This is easier than fiddling with fdisk and partition offsets for mounting.

$ sudo losetup -P /dev/loop0 HashiPi-pi0.img
$ sudo mount /dev/loop0p1 /mnt

# copy kernel and device tree binary (dtb)
$ cp /mnt/kernel8.img .
$ cp /mnt/bcm2711-rpi-4-b.dtb .

# unmount
$ sudo umount /mnt
$ sudo losetup --detach /dev/loop0

Patch device tree to enable USB controller

The “device tree binary” (.dtb) needs to be translated into a readable “device tree source” (.dts) file.

$ dtc -I dtb -O dts -o bcm2711-rpi-4-b.dts bcm2711-rpi-4-b.dtb

The .dts file can be patched to enable the usb controller. This is required, if we want to boot later using the usbnet device and port-forward (hostfwd) the ssh port.

--- bcm2711-rpi-4-b.dts.orig    2025-09-21 15:05:59.304575294 +0200
+++ bcm2711-rpi-4-b.dts 2025-09-21 15:04:56.709581742 +0200
@@ -1450,7 +1450,7 @@
                        phy-names = "usb2-phy";
                        interrupt-names = "usb", "soft";
                        power-domains = <0x10 0x06>;
-                       status = "disabled";
+                       status = "okay";
                        phandle = <0xbf>;
                };

Unfortunately, we need to use this usb device, because all other emulated network devices are pci based which is not supported by QEMU for the Raspberry Pi

$ qemu-system-aarch64 -device help
...
Network devices:
name "e1000", bus PCI, alias "e1000-82540em", desc "Intel Gigabit Ethernet"
name "e1000-82544gc", bus PCI, desc "Intel Gigabit Ethernet"
name "e1000-82545em", bus PCI, desc "Intel Gigabit Ethernet"
name "e1000e", bus PCI, desc "Intel 82574L GbE Controller"
name "i82550", bus PCI, desc "Intel i82550 Ethernet"
name "i82551", bus PCI, desc "Intel i82551 Ethernet"
name "i82557a", bus PCI, desc "Intel i82557A Ethernet"
name "i82557b", bus PCI, desc "Intel i82557B Ethernet"
name "i82557c", bus PCI, desc "Intel i82557C Ethernet"
name "i82558a", bus PCI, desc "Intel i82558A Ethernet"
name "i82558b", bus PCI, desc "Intel i82558B Ethernet"
name "i82559a", bus PCI, desc "Intel i82559A Ethernet"
name "i82559b", bus PCI, desc "Intel i82559B Ethernet"
name "i82559c", bus PCI, desc "Intel i82559C Ethernet"
name "i82559er", bus PCI, desc "Intel i82559ER Ethernet"
name "i82562", bus PCI, desc "Intel i82562 Ethernet"
name "i82801", bus PCI, desc "Intel i82801 Ethernet"
name "igb", bus PCI, desc "Intel 82576 Gigabit Ethernet Controller"
name "ne2k_pci", bus PCI
name "pcnet", bus PCI
name "rocker", bus PCI, desc "Rocker Switch"
name "rtl8139", bus PCI
name "tulip", bus PCI
-> name "usb-net", bus usb-bus
name "virtio-net-device", bus virtio-bus # No 'virtio-bus' bus found for device 'virtio-net-device'
name "virtio-net-pci", bus PCI, alias "virtio-net"
name "virtio-net-pci-non-transitional", bus PCI
name "virtio-net-pci-transitional", bus PCI
name "vmxnet3", bus PCI, desc "VMWare Paravirtualized Ethernet v3"

We really need the usb device (virtio-net-device does not work either I tried), that's the reason for the patch.

A comment of the “interrupt.memfault blog” describes it nicely (very helpful community):

Note that for raspi4, the bcm2711-rpi-4-b.dtb devicetree file has disabled the USB controller. So, to enable USB keyboard & mouse, the .dtb file must be decompiled to .dts, patched, and recompiled back to .dtb.

Unfortunately, it's not only needed for keyboard and mouse, but also to make our network adapter work (for ssh port-forwarding).

Thaa patching.. Then recompiling into binary form with dtc:

$ dtc -I dtb -O dts -o bcm2711-rpi-4-b.dts bcm2711-rpi-4-b.dtb

Would be really nice to have this usb controller enabled by default in the next Trixie Pi OS 🤞

Boot the image

For booting the image, I had to ensure two things for the kernel arguments for the Raspberry 4:

• Use the ttyAMA1 console
• Use the root partition mmcblk1p2

Note that I'm not enabling the keyboard & mouse devices (as suggested in the references online), because I'm mainly interested to connect to the machine remotely via the ssh port fowarding:

$ sudo qemu-system-aarch64 \
  -machine raspi4b -cpu cortex-a72 \
  -dtb bcm2711-rpi-4-b-mod.dtb \ # use mod device tree
  -m 2G -smp 4 \
  -kernel kernel8.img -sd HashiPi-pi0.img \
  -append "rw earlyprintk loglevel=8 console=ttyAMA1,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk1p2 rootdelay=1" \
  -device usb-net,netdev=net0 \
  -netdev user,id=net0,hostfwd=tcp::2222-:22

That's it. Is still a bit slow, but good enough to throw some Ansible against the wall and see if it sticks.

My idea here is to do less with the HashiCorp packer scripts and go back to more Ansible, because that might be more sustainable in the long run.. Let's see. Next I'm probably also going to give the Trixie (nightly image) a try.

References

• https://interrupt.memfault.com/blog/emulating-raspberry-pi-in-qemu
• https://www.qemu.org/docs/master/system/qemu-manpage.html
• https://www.qemu.org/docs/master/system/arm/raspi.html
• https://github.com/trinitronx/qemu-raspbian/blob/main/run-raspi4.sh
• https://github.com/trinitronx/qemu-raspbian/blob/main/bcm2711-rpi-4-b.dts.patch
• https://downloads.raspberrypi.org
• https://www.man7.org/linux/man-pages/man8/losetup.8.html

#borg #rclone #backup

A while ago I purchased quite some TB of storage at pCloud, a small Swiss cloud storage provider. Only recently, I found out that you can use rclone to push files and data to the cloud in an rsync-like fashion.

Since I wanted to use that approach to backup files from my router, I first figured ways to install it with opkg. I followed the Turris docs to switch to a more recent feed/branch “Here be Lions” but noticed quickly, that I actually needed to install Borg2. What most distributions package nowadays is Borg (verison 1), which is the stable release. Borg2 is a breaking change (incompatible, but runs the new feature that supports rclone).

Therefore, I decided to build a small Debian 12 lxc container and run Borg inside the container. That approach worked well.

To mount a host path inside the container, I used the following modification of the lxc config file:

# Mount host ssd
lxc.mount.entry = /srv host-srv none bind,create=dir 0 0

This will mount the /srv directory of the Turris host to the container, so the Borg process can backup files from that path.

The rclone setup with pCloud was straight forward, I simply needed to confirm the login from my laptop with a browser, because the Turris cannot connect via browser to confirm the login on pCloud. Easy!

The next step was configuring the Borg backup repository on pCloud.

My borg configuration points to the backup folder on pCloud:

# ~/.config/borg/config 
BORG_REPO='rclone:pcloud:backup-folder'
BORG_PASSPHRASE='***'
PATTERNSFILE='/root/.config/borg/patterns.lst'

I also maintain a patterns file, but won't go into details here.

borg repo-create --encryption=repokey-chacha20-poly1305

⚠️ Note that the repo-create and also a lot of other commands in Borg2 are similar, but different from the Borg v1 commands. A little bit confusing when reading the docs, but you'll get the hang of it..

I chose to use chacha20-poly1305 encryption mode, because that combination was suggested to me as the fastest algorithm on my Turris. You can find out the speed of the different supported algorithms by running:

borg benchmark cpu

This is yet another convenient feature of Borg2.

Lastly, I started the backup using a Systemd timer and some variation of borg create combined with another prune command to prune old backups.

So far, so good. I'm happy that I finally found a suitable solution for my backup. The process seems quite slow though. In my create borg command I included the --compression lz4 (which should be Speedy Gonzales), but more than 8h for the first backup? Common..

I found a small signal trick that allowed me to check the current state of the upload process. This will show me the current file of the upload process:

kill -s USR1 $(pidof python) && journalctl -eu borg-backup | tail -1

I could also contribute a small improvement in the Borg docs regarding the compilation of the dependencies required for Borg2 🎉 so the hassle was worth it.

For automation of the entire procedure, I created a small packer build script that can rebuild the lxc container from scratch whenever needed. Essentially, it contains the commands to install the prerequisites for Borg on Debian followed by the installation with Pip in an virtual environment and the configuration with rclone.

Edit 2024-12-17

Turris Omnia Borg benchmark:

Chunkers =======================================================
buzhash,19,23,21,4095    1GB        12.052s
fixed,1048576            1GB        2.655s
Non-cryptographic checksums / hashes ===========================
xxh64                    1GB        2.394s
crc32 (zlib)             1GB        2.970s
Cryptographic hashes / MACs ====================================
hmac-sha256              1GB        10.785s
blake2b-256              1GB        24.264s
Encryption =====================================================
aes-256-ctr-hmac-sha256  1GB        39.176s
aes-256-ctr-blake2b      1GB        51.622s
aes-256-ocb              1GB        34.483s
chacha20-poly1305        1GB        12.335s
KDFs (slow is GOOD, use argon2!) ===============================
pbkdf2                   5          1.969s
argon2                   5          7.606s
Compression ====================================================
lz4          0.1GB      0.239s
zstd,1       0.1GB      0.739s
zstd,3       0.1GB      0.923s
zstd,5       0.1GB      16.528s
zstd,10      0.1GB      26.171s
zstd,16      0.1GB      51.617s
zstd,22      0.1GB      64.239s
zlib,0       0.1GB      0.703s
zlib,6       0.1GB      15.758s
zlib,9       0.1GB      16.217s
lzma,0       0.1GB      88.872s
lzma,6       0.1GB      114.931s
lzma,9       0.1GB      96.051s
msgpack ========================================================
msgpack      100k Items 0.818s

For comparison, on my x230, where I would choose blake2 for hashing (blake2-chacha20-poly1305):

Chunkers =======================================================
buzhash,19,23,21,4095    1GB        1.360s
fixed,1048576            1GB        0.134s
Non-cryptographic checksums / hashes ===========================
xxh64                    1GB        0.097s
crc32 (zlib)             1GB        0.406s
Cryptographic hashes / MACs ====================================
hmac-sha256              1GB        3.474s
blake2b-256              1GB        1.980s
Encryption =====================================================
aes-256-ctr-hmac-sha256  1GB        3.901s
aes-256-ctr-blake2b      1GB        3.938s
aes-256-ocb              1GB        0.572s
chacha20-poly1305        1GB        1.251s
KDFs (slow is GOOD, use argon2!) ===============================
pbkdf2                   5          0.362s
argon2                   5          0.434s
Compression ====================================================
lz4          0.1GB      0.022s
zstd,1       0.1GB      0.041s
zstd,3       0.1GB      0.062s
zstd,5       0.1GB      0.104s
zstd,10      0.1GB      0.188s
zstd,16      0.1GB      13.794s
zstd,22      0.1GB      14.795s
zlib,0       0.1GB      0.067s
zlib,6       0.1GB      2.735s
zlib,9       0.1GB      2.740s
lzma,0       0.1GB      18.819s
lzma,6       0.1GB      36.049s
lzma,9       0.1GB      30.293s
msgpack ========================================================
msgpack      100k Items 0.258s