Finally, some light at the end of the tunnel!
As I have said in this
blog
and elsewhere, after putting quite a bit of work into generating the Debian
Raspberry Pi images between late
2018
and 2023, I had to recognize I don t have the time and energy to properly
care for it.
I even registered a GSoC project for it. I mentored Kurva Prashanth, who
did good work on the vmdb2
scripts we use for the image generation but in the end, was unable to
push them to be built in Debian infrastructure. Maybe a different approach
was needed! While I adopted the images as they were conceived by Michael
Stapelberg,
sometimes it s easier to start from scratch and build a fresh approach.
So, I m not yet pointing at a stable, proven release, but to a good
promise. And I hope I m not being pushy by making this public: in the
#debian-raspberrypi channel, waldi has shared the images he has created
with the Debian Cloud Team s infrastructure.
So, right now, the images built so
far
support Raspberry Pi families 4 and 5 (notably, not the 500 computer I
have, due to a missing Device Tree, but I ll try to help figure that bit
out Anyway, p400/500/500+ systems are not that usual). Work is
underway to get the 3B+ to boot (some hackery is needed, as it only
understands MBR partition schemes, so creating a hybrid image seems to be
needed).
Sadly, I don t think the effort will be extended to cover older,
32-bit-only systems (RPi 0, 1 and 2).
Anyway, as this effort stabilizes, I will phase out my (stale!) work on
raspi.debian.net, and will redirect it to point at the new images.
Comments
Andrea Pappacoda tachi@d.o 2026-01-26 17:39:14 GMT+1
Are there any particular caveats compared to using the regular Raspberry Pi
OS?
Are they documented anywhere?
Gunnar Wolf gwolf.blog@gwolf.org 2026-01-26 11:02:29 GMT-6
Well, the Raspberry Pi OS includes quite a bit of software that s not
packaged in Debian for various reasons some of it because it s non-free
demo-ware, some of it because it s RPiOS-specific configuration, some of
it I don t care, I like running Debian wherever possible
Andrea Pappacoda tachi@d.o 2026-01-26 18:20:24 GMT+1
Thanks for the reply! Yeah, sorry, I should ve been more specific. I also
just care about the Debian part. But: are there any hardware issues or
unsupported stuff, like booting from an SSD (which I m currently doing)?
Gunnar Wolf gwolf.blog@gwolf.org 2026-01-26 12:16:29 GMT-6
That s beyond my knowledge Although I can tell you that:
Raspberry Pi OS has hardware support as soon as their new boards hit the
market. The ability to even boot a board can take over a year for the
mainline Linux kernel (at least, it has, both in the cases of the 4 and
the 5 families).
Also, sometimes some bits of hardware are not discovered by the Linux
kernels even if the general family boots because they are not declared in
the right place of the Device Tree (i.e. the wireless network interface
in the 02W is in a different address than in the 3B+, or the 500 does not
fully boot while the 5B now does). Usually it is a matter of just
declaring stuff in the right place, but it s not a skill many of us have.
Also, many RPi hats ship with their own Device Tree overlays, and they
cannot always be loaded on top of mainline kernels.
Andrea Pappacoda tachi@d.o 2026-01-26 19:31:55 GMT+1
That s beyond my knowledge Although I can tell you that:
Raspberry Pi OS has hardware support as soon as their new boards hit the
market. The ability to even boot a board can take over a year for the
mainline Linux kernel (at least, it has, both in the cases of the 4 and
the 5 families).
Yeah, unfortunately I m aware of that I ve also been trying to boot
OpenBSD on my rpi5 out of curiosity, but been blocked by my somewhat
unusual setup involving an NVMe SSD as the boot drive :/
Also, sometimes some bits of hardware are not discovered by the Linux
kernels even if the general family boots because they are not declared in
the right place of the Device Tree (i.e. the wireless network interface
in the 02W is in a different address than in the 3B+, or the 500 does not
fully boot while the 5B now does). Usually it is a matter of just
declaring stuff in the right place, but it s not a skill many of us have.
At some point in my life I had started reading a bit about device trees and
stuff, but got distracted by other stuff before I could develop any
familiarity with it. So I don t have the skills either :)
Also, many RPi hats ship with their own Device Tree overlays, and they
cannot always be loaded on top of mainline kernels.
I m definitely not happy to hear this!
Guess I ll have to try, and maybe report back once some page for these new
builds materializes.
It took nearly a year, but today a new ftpsync version got released.
Most of the work for this release was done by weasel, with one new
feature submitted by waldi, my work was mostly style fixes and a bit
of documentation. And of course the release now.
If you run a mirror, you will find the new version at the usual place,
that is the project/ftpsync/ subdirectory. You may also want to
subscribe to the debian mirrors mailinglist, as the mirror team will
post more information about changes in ftpsync there.
I've been using Linode since 2010, and many of
my friends have heard me talk about how big a fan I am of linode. I've
used Debian unstable on all my Linodes, since I often use them as a remote
shell for general purpose Debian development. I've found my linodes to be
indispensable, and I really love Linode.
The Problem
Recently, because of my work on Docker, I was forced
to stop using the Linode kernel in favor of the stock Debian kernel, since
the stock Linode kernel has no aufs support, and the default LVM-based
devicemapper backend can be quite a pain.
I tried loading in btrfs support, and
using that to host the Docker instance backed with btrfs, but it was throwing
errors as well. Stuck with unstable backends, I wanted to use the
aufs backend, which, dispite problems in
aufs internally, is quite stable with Docker (and in general).
I started to run through the Linode Library's guide on PV-Grub,
but that resulted in a cryptic error with xen not understanding the compression
of the kernel. I checked for recent changes to the compresson, and lo, the
Debian kernel has been switched to use xz compression in sid. Awesome news,
really. XZ compression is awesome, and I've been super impressed with how
universally we've adopted it in Debian. Keep it up! However, it appears only
a newer pv-grub than the Linode hosts have installed will fix this.
After contacting the (ever friendly) Linode support, they were unable to give
me a timeline on adding xz support, which would entail upgrading pv-grub. It
was quite disapointing news, to be honest. Workarounds were suggested,
but I'm not quite happy with them as proper solutions.
After asking in #debian-kernel, waldi was
able to give me a few pointers, and the following is very inspired by him,
the only thing that changed much was config tweaking, which was easy enough.
Thanks, Bastian!
The Constraints
I wanted to maintain a 100% stock configuration from the kernel up.
When I upgraded my kernel, I wanted to just work. I didn't want to
unpack and repack the kernel, and I didn't want to install software
outside main on my system. It had to be 100% Debian and unmodified.
The Solution
Left unable to run my own kernel directly in the Linode interface, the tact
here was to use Linode's old pv-grub to chain-load grub-xen, which loaded
a modern kernel. Turns out this works great.
Let's start by creating a config for Linode's pv-grub to read
and use.
sudomkdir-p/boot/grub/
Now, since pv-grub is legacy grub, we can write out the following
config to chain-load in grub-xen (which is just Grub 2.0, as far as I can
tell) to /boot/grub/menu.lst. And to think, I almost forgot all about
menu.lst. Almost.
Next, change your boot configuration to use pv-grub, and give the machine
a kick. Should work great! If you run into issues, use the lish shell to
debug it, and let me know what else I should include in this post!
Hack on!
Today I held a lightning talk at the Karlsruhe Functional Programmer s Group, where I presented Real World Haskell applications, i.e. programs that are written in Haskell, are somewhat mature and well-known and have non-programmers as their target group. Here is the (surely subjective) list that I have come up (also see the slides):
darcs (since 2002, 35 000 loc): Distributed version control system with an innovative focus on changes instead of states.
xmonad (since 2007, 30000 loc): Well known tiling window manager with a huge library of layout and other plugins. Made it into the list despite its configuration file being a Haskell file.
hledger (since 2007, 9000 loc): Text-file based double-ledger accounting tool, a clone of ledger.
Raincat (since 2008, 2000 loc): Platform game with a cat that does not want to get wet.
arbtt (since 2009, 2000 loc): My automatic rule-based time tracker. Made it into the list as a shameless plug; probably not that popular. It has now a proper web page contributed by Waldir Pimenta.
detexify (since 2010, 500 loc): The back end of the very useful LaTeX character command finder is written in Haskell.
git-annex (since 2010, 28 000 loc): Manages your files and their location, a mixture of dropbox and git. Written by famous Joey Hess, who made a living from it via kickstarter He is currently running a second round of funding!
Nikki and the Robots (since 2010, 18 000 loc): Platform game with Nikki and, well, his robots. It was produced as a commercial independent game and sold via a pay-what-you-like scheme, but the company unfortunately closed down.
hoodle (since 2011, 13 000 loc): A note-taking and PDF annotation software like xournal.
Chordify (since 2012, ? loc): Analyses music, e.g. from a YouTube video, and calculates the corresponding guitar chords. Closed software, but supposedly written in Haskell.
There is also an impressive list of industrial users that use Haskell without talking about it much, but that does not work well to show off that you can do any kind of application in Haskell.
If I missed anything important, let me know!
Linux includes a syscall filter since a long time.
It was restricted to a pre-defined set of syscalls.
Since some versions Linux got a more generic filter.
Linux can use a BPF-filter to define actions for syscalls.
This allows a fine granular specification on which syscalls to act.
Also it supports different outcomes assigned to the filter.
This filter can be used to filter out sync operations.
Debian already got a tool to do this called eatmydata.
It is pretty limited as it uses a shared library to drop the library functions.
It needs to be available at all times, or it will not do anything.
I wrote a small tool that asks the kernel to filter out sync operations for all children.
It sets a filter with all currently supported sync-like operations and makes them return success.
However it can't filter the O_SYNC-flag from the open-syscall,
so it just makes it return an error.
It executes the command given on the command-line after that.
This is just a proof of concept, but lets see.
/*
* Copyright (C) 2013 Bastian Blank <waldi@debian.org>
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
* ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
* LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#define _GNU_SOURCE 1
#include <errno.h>
#include <fcntl.h>
#include <seccomp.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define filter_rule_add(action, syscall, count, ...) \
if (seccomp_rule_add(filter, action, syscall, count, ##__VA_ARGS__)) abort();
static int filter_init(void)
scmp_filter_ctx filter;
if (!(filter = seccomp_init(SCMP_ACT_ALLOW))) abort();
if (seccomp_attr_set(filter, SCMP_FLTATR_CTL_NNP, 1)) abort();
filter_rule_add(SCMP_ACT_ERRNO(EINVAL), SCMP_SYS(open), 1, SCMP_A1(SCMP_CMP_MASKED_EQ, O_SYNC, O_SYNC));
filter_rule_add(SCMP_ACT_ERRNO(0), SCMP_SYS(fsync), 0);
filter_rule_add(SCMP_ACT_ERRNO(0), SCMP_SYS(fdatasync), 0);
filter_rule_add(SCMP_ACT_ERRNO(0), SCMP_SYS(msync), 0);
filter_rule_add(SCMP_ACT_ERRNO(0), SCMP_SYS(sync), 0);
filter_rule_add(SCMP_ACT_ERRNO(0), SCMP_SYS(syncfs), 0);
filter_rule_add(SCMP_ACT_ERRNO(0), SCMP_SYS(sync_file_range), 0);
return seccomp_load(filter);
int main(__attribute__((unused)) int argc, char *argv[])
if (argc <= 1)
fprintf(stderr, "usage: %s COMMAND [ARG]...\n", argv[0]);
return 2;
if (filter_init())
fprintf(stderr, "%s: can't initialize seccomp filter\n", argv[0]);
return 1;
execvp(argv[1], &argv[1]);
if (errno == ENOENT)
fprintf(stderr, "%s: command not found: %s\n", argv[0], argv[1]);
return 127;
fprintf(stderr, "%s: failed to execute: %s: %s\n", argv[0], argv[1], strerror(errno));
return 1;
So, Waldi filed #545032, arguing the udev rules shipped in devicekit-disks are broken. He even added a conflict in dmsetup because of that. Whenever you ask him about this issue, the only things he answers are:
The rules are broken and they need to be removed.
The information is already available in other variables.
It would be nice if all of this was true, but:
There is no explanation about how and why these rules could actually break anything.
The information is not available in other variables, apart from a couple of trivial things. Or maybe it is, but since all that udev crap has absolutely zero documentation, there is no way to know how it is available.
The result: GNOME is currently not installable on a system with LVM. There is no foreseeable possibility to fix that. Great. Thanks.
Today I received two emails with even newer BIOS updates for my problem. The second, latest version 1.80p did actually
fix the problem of not booting with 4 GB of RAM. I haven't tried the first, previous version 1.80k yet, so I can't tell
if that worked as well.
Anyway, despite the fact that the machine now recognizes 4 GB dual-ranked memory, Linux uses 3.1 GB of it - at least
when not using Xen... But first without Xen, standard Debian 2.6.26-1-686 kernel:
Now, when I try to boot Xen hypervisor & kernel, Linux recognizes 4 GB of memory:
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 2.6.26-1-xen-686 (Debian 2.6.26-13) (waldi@debian.org) (gcc version 4.1.3 20080704
(prerelease) (Debian 4.1.2-24)) #1 SMP Sat Jan 10 22:52:47 UTC 2009
[ 0.000000] Reserving virtual address space above 0xf5800000
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 00000000f5730000 (usable)
[ 0.000000] 3199MB HIGHMEM available.
[ 0.000000] 728MB LOWMEM available.
[ 0.000000] Entering add_active_range(0, 0, 1005360) 0 entries of 256 used
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 4096
[ 0.000000] Normal 4096 -> 186368
[ 0.000000] HighMem 186368 -> 1005360
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 1005360
[ 0.000000] On node 0 totalpages: 1005360
[ 0.000000] DMA zone: 32 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 4064 pages, LIFO batch:0
[ 0.000000] Normal zone: 1424 pages used for memmap
[ 0.000000] Normal zone: 180848 pages, LIFO batch:31
[ 0.000000] HighMem zone: 6399 pages used for memmap
[ 0.000000] HighMem zone: 812593 pages, LIFO batch:31
[ 0.000000] Movable zone: 0 pages used for memmap
[ 0.000000] DMI 2.3 present.
[ 0.000000] ACPI: RSDP 000F9BC0, 0014 (r0 ACPIAM)
[ 0.000000] ACPI: RSDT BFF30000, 0030 (r1 A M I OEMRSDT 6000816 MSFT 97)
[ 0.000000] ACPI: FACP BFF30200, 0081 (r2 A M I OEMFACP 6000816 MSFT 97)
[ 0.000000] ACPI: DSDT BFF30360, 3417 (r1 P4V88 P4V88001 1 INTL 2002026)
[ 0.000000] ACPI: FACS BFF40000, 0040
[ 0.000000] ACPI: APIC BFF30300, 0052 (r1 A M I OEMAPIC 6000816 MSFT 97)
[ 0.000000] ACPI: OEMB BFF40040, 003F (r1 A M I OEMBIOS 6000816 MSFT 97)
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
[ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] Allocating PCI resources starting at c4000000 (gap: c0000000:3ffc0000)
[ 0.000000] PERCPU: Allocating 28552 bytes of per cpu data
[ 0.000000] NR_CPUS: 32, nr_cpu_ids: 2
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 997505
[ 0.000000] Kernel command line: root=/dev/md2 console=tty0
[ 0.000000] Enabling fast FPU save and restore... done.
[ 0.000000] Enabling unmasked SIMD FPU exception support... done.
[ 0.000000] Initializing CPU#0
[ 0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes)
[ 0.000000] Xen reported: 2792.268 MHz processor.
[ 0.004000] Console: colour VGA+ 80x25
[ 0.004000] console [tty0] enabled
[ 0.004000] console [hvc-1] enabled
[ 0.004000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.004000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.004000] Software IO TLB enabled:
[ 0.004000] Aperture: 64 megabytes
[ 0.004000] Kernel range: c3bce000 - c7bce000
[ 0.004000] Address size: 27 bits
[ 0.004000] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[ 0.004000] Memory: 3888208k/4021440k available (1843k kernel code, 124136k reserved, 742k data, 196k init, 3275968k
highmem)
Sadly, the machine gets so slow that it needs >20 mins (1100 secs) to boot. Most likely something is broken with PAE on
this machine so it get's awfully slow.
I'm curious what the Asrock support will say about this!? ;)
Side note: I'm really satisfied with the good response from Asrock Support. Asrock might not be the company with the
best mainboards available, but its support seems very good to me: very responsive and care taking!
Serious business involving the vmsplice() exploit: The kernel is fixed, hopefully Debian security team will have a fix for production use soon. In the meantime, waldi has provided unofficial fixed images. Thanks! They are confirmed to be working. These images are for etch. Lenny and sid are still vulnerable, but I suspect this will be fixed soon. If you are using these images in virtual machines, be aware that you will need to install the modules into each one or they may have problems later.
GNOME is broken on Debian/kFreeBSD: All of this exploit nonsense made me consider installing Debian/kFreeBSD on one of my machines to see if it was worth using as a desktop system. Sadly, it doesn’t work for me right now. I guess I’ll try back in a couple of months. Also, it’d be nice if a new install CD was released with the proper /etc/apt/sources.list (ftp.gnuab.org -> ftp-debian-ports.org).
Today I thought it’s time to look deeper into the Xen hype. So I decided to install xen on etch. I followed Ganneffs recommandation
playground:~# aptitude install bridge-utils iproute \
xen-ioemu-3.0.3-1 xen-utils-3.0.3-1\
xen-linux-system-2.6.18-4-xen-vserver-686 libc6-xen
Booting the dom0 leeds me into kernel panic, cause no root device was found. Hmm … there seems to be the driver missing. Right - there wasn’t any /boot/initrd.img-2.6.18-4-xen-vserver-686. Waldi did hint me to /var/lib/dpkg/info/linux-image-2.6.18-4-xen-vserver-686.postinst and I got my ramdisk this way:
playground:~# update-initramfs -c -t -k \
2.6.18-4-xen-vserver-686
playground:~# command -v update-grub > \
/dev/null && update-grub
After booting dom0 successfully, my serial console disappeared. After some digging around, I got the clue I need to tell xen, that there is one.
I modified /boot/grub/menu.lst:
# xenhopt=com1=115200,8n1 console=com1
..
# xenkopt=console=vga
Dom0 is running now, lets see what we can do next, maybe:
Finally, some light at the end of the tunnel!
As I have said in this
blog
and elsewhere, after putting quite a bit of work into generating the Debian
Raspberry Pi images between late
2018
and 2023, I had to recognize I don t have the time and energy to properly
care for it.
I even registered a GSoC project for it. I mentored Kurva Prashanth, who
did good work on the vmdb2
scripts we use for the image generation but in the end, was unable to
push them to be built in Debian infrastructure. Maybe a different approach
was needed! While I adopted the images as they were conceived by Michael
Stapelberg,
sometimes it s easier to start from scratch and build a fresh approach.
So, I m not yet pointing at a stable, proven release, but to a good
promise. And I hope I m not being pushy by making this public: in the
#debian-raspberrypi channel, 
Sadly, I don t think the effort will be extended to cover older,
32-bit-only systems (RPi 0, 1 and 2).
Anyway, as this effort stabilizes, I will phase out my (stale!) work on
I've been using 
Today I held a lightning talk at the 
So, Waldi filed 
Serious business involving the vmsplice() exploit: The kernel is fixed, hopefully Debian security team will have a fix for production use soon. In the meantime,