Ubuntu on Raspberry Pi: summer ‘25 update

Project Discussion Ubuntu Architectures
, , ,
1

Hello friends, my name is Ravi, and I recently took the lead of the Ubuntu Architectures team (Part of Foundations). The Architectures team is responsible for the support of Ubuntu and its ecosystem on non-x86 architectures. In particular, we’re talking about RISC-V and ARM, as well as special focus on the Raspberry Pi ecosystem. This includes making sure Ubuntu works on the latest hardware for each architecture while also providing the best support for each architecture-specific ecosystem. If you’re not familiar with our recent work on ARM, check out:

Have a look also at our RISC-V blogposts. But the focus of today’s post is Raspberry Pi.

What Foundations is doing for Raspberry Pi

Raspberry Pis are single-board computers, known for affordability and low power consumption. They are popular for a myriad of use cases, such as education, home automation, robotics, and industrial automation, to name a few. Raspberry Pi OS is the standard operating system for these devices.

In this article, I’ll introduce what the Foundations team has been doing on Raspberry Pis, our goals, and a bit about our future engineering roadmap.

Keeping up with Raspberry Pi OS

Our primary goal has been to keep up with Raspberry Pi OS. We have done a good job of that recently, releasing an Ubuntu image for the Raspberry Pi 5 on the day of its launch.

Historically, we have struggled a bit to keep up with peripherals support, but I am happy to report that all official accessories (touchscreen, camera modules, the keyboard variants 400/500) are supported on Ubuntu today.

Our goal is not to compete with Pi OS but to provide a complementary, modern experience, as well as a choice of an operating system, thus enabling both Raspberry Pi OS and Ubuntu to improve in the long run. We work in close collaboration with the Raspberry Pi Ltd.

Ubuntu Images

Our support for Raspberry Pi goes as far back as 2B. You can run Ubuntu Server on Raspberry Pi 2B v1.2 and later models.

Architectures team has been the driver to bring Ubuntu Desktop to Raspberry Pi. Raspberry Pi 4 and 5 can run Ubuntu with the GNOME desktop reasonably well. The Ubuntu Desktop team has an ambitious roadmap and supporting GNOME takes priority. This leaves little room to support other desktop environments, especially if we want to support all the stable releases. We would like the minimum required specifications to be much lower.

This is something Ubuntu flavors can help with, particularly Lubuntu and Xubuntu. Edubuntu is a natural fit and does have Raspberry Pi images (thank you!). Please reach out to me or the Edubuntu team if you need help with building images.

You can see all combinations of devices and Ubuntu support here: Canonical Ubuntu Boards.

Upgrades and reliability

To upgrade the Ubuntu operating system to the next major version, use do-release-upgrade or the Software Properties UI. We commit a significant amount of time to testing Raspberry Pis for every release. This usually happens every 3 months or so, either for a stable point release or an intermediate release. We do have community participation by contributing test cases and results. However, the time commitment keeps increasing with the combination of devices (models, accessories, features) and Ubuntu flavors.

We are exploring automated ways to test Raspberry Pi upgrades and install media. This is in a very early stage, but I’ll share more once we have a prototype working.

Ubuntu Pro

Commercial plug: Raspberry Pi is committed to selling their boards for at least 10 years. You can buy an updated version of the Pi 3 Model B today at roughly the same price as on launch day. This aligns very well with 10 years of security and maintenance updates with Ubuntu Pro’s Expanded Security Maintenance (ESM). Ubuntu is the choice for long-term software support for Raspberry Pis. Ubuntu Pro is free for personal use for up to 5 devices.

Future plans

We are working on creating a mechanism to always have a “known good” boot state to fall back on. This is necessary in case your kernel or initrd is messed up and your Pi fails to boot. Raspberry Pis encourage tinkering, so it is natural that you will see these warning LEDs at some point.

We are investigating boot integrity. Raspberry Pis have a lot of boot artifacts, and we want to ensure the boot flow is not tampered with. Raspberry Pi 4 and 5 support this, and it needs to be adopted for Ubuntu images.

A special mention to the people who make it all happen:

8 Likes
2

Hello,

When will Ubuntu kernel have NUMA (emulated) support?.

You’ve said that “Our primary goal has been to keep up with Raspberry Pi OS” but in this case Ubuntu is currently way behind Raspberry Pi OS, been almost a year since this feature was initially tested [1], and it’s not mentioned in the “Future Plans” section. We’re talking about a very noticeable performance improvement for the latest boards [2].

Thanks and regards.

[1] https://forums.raspberrypi.com/viewtopic.php?t=378276
[2] https://www.jeffgeerling.com/blog/2024/numa-emulation-speeds-pi-5-and-other-improvements

3

Hello fprietog, thank you for raising this. We will investigate NUMA support and do some benchmarking in the next cycle. Please follow Topics tagged raspberrypi for an update.

1 Like
4

Hello,

I’ve just updated Ubuntu Desktop for Raspberry Pi to 25.10 Questing.

I saw in Questing Release Notes [1] that one of the 25.10 default configuration changes is that Ubuntu Desktop replaced “initramfs-tools” by “dracut” (while Ubuntu Server still uses “initramfs-tools”). But that replacement wasn’t done in the Ubuntu Raspberry Pi Desktop installation.

I’m not sure if its because of this other change “The Ubuntu desktop images for Raspberry Pi are now based upon the “desktop-minimal” seed rather than “desktop”” or if there are other requirements involved that prevent this replacement. Maybe it’s something that should be clarify in the Release Notes [1].

Thanks and best regards.

[1] Questing Quokka Release Notes

5

AFAIK the dracut replacement only happens on fresh installs, for upgraded systems you will need to manually migrate…

1 Like
6

For the Raspberry Pi there is no dracut replacement in both cases: fresh install and upgrade.

1 Like
7

fprietog, thank you for noticing. I have updated the release notes.

1 Like
8

Hi, Any news about NUMA testing/support? It should be a very good addition to the upcoming LTS release :wink:

Thks!

9

Hi, we investigated this in the Ubuntu 26.04 development cycle: Multimedia improvements for Raspberry Pi Desktop in Ubuntu Resolute Raccoon, but we didn’t observe any significant improvements on Geekbench 6. So this isn’t included to reduce the delta from mainline kernel.

10

Hi @r41k0u , first of all thanks for answering.

I have a “Raspberry Pi5 16GB” and a “Raspberry Pi 4 8GB”. I’ve done a fresh install of “Ubuntu 26.04” from the iso. Unfortunately numa is not working in this fresh installation.

For the “Raspberry Pi 5 16GB” the default numa nodes should be 8. The Raspberry Pi bootloader detects the machine type and sent the necessary parameters to the kernel.

This is an example from the latest “Raspberry Pi OS trixie”:

# uname -a
Linux raspberrypi 6.12.75+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux

# dmesg | grep -i numa
[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000003ffffffff]
[    0.000000] NUMA: Initialized distance table, cnt=8
[    0.000000] Kernel command line: reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=0  numa=fake=8 system_heap.max_order=0 iommu_dma_numa_policy=interleave smsc95xx.macaddr=xx:xx:xx:xx:xx:xx vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000  console=ttyAMA10,115200 console=tty1 root=PARTUUID=29cbc784-07 rootfstype=ext4 fsck.repair=yes rootwait plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=ES
[    0.000000] mempolicy: NUMA default policy overridden to 'interleave:0-7'
[    0.000000] DMA IOMMU NUMA default policy overridden to 'interleave:0-7'

# numactl --show
policy: interleave
preferred node: 4 (interleave next)
interleavemask: 0 1 2 3 4 5 6 7 
interleavenode: 4
physcpubind: 0 1 2 3 
cpubind: 0 1 2 3 4 5 6 7 
nodebind: 0 1 2 3 4 5 6 7 
membind: 0 1 2 3 4 5 6 7 
preferred: 0 1 2 3 4 5 6 7

You can see that the bootloader sent the commands numa_policy=interleave and numa=fake=8 to the kernel command line and after boot there are 8 numa nodes (can be seen using command numactl –show). This is the optimal situation.

Now we’ll see what is happening in “Ubuntu 26.04 resolute”:

# uname -a
Linux fprietog-test 7.0.0-1009-raspi #9-Ubuntu SMP PREEMPT_DYNAMIC Mon Apr 13 16:37:04 UTC 2026 aarch64 GNU/Linux

# dmesg | grep -i numa
[    0.000000] Malformed early option 'numa'
[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000003ffffffff]
[    0.000000] Kernel command line: reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe numa_policy=interleave nvme.max_host_mem_size_mb=0  numa=fake=8 system_heap.max_order=0 iommu_dma_numa_policy=interleave smsc95xx.macaddr=xx:xx:xx:xx:xx:xx vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000  zswap.enabled=1 zswap.compressor=zstd multipath=off dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=29cbc784-0b rootfstype=ext4 panic=10 rootwait fixrtc quiet splash
[    0.000000] mempolicy: NUMA default policy overridden to 'interleave:0'
[    0.000000] DMA IOMMU NUMA default policy overridden to 'interleave:0'
[    0.007160] futex hash table entries: 1024 (65536 bytes on 1 NUMA nodes, total 64 KiB, linear).

# numactl --show
policy: interleave
preferred node: 0 (interleave next)
interleavemask: 0 
interleavenode: 0
physcpubind: 0 1 2 3 
cpubind: 0 
nodebind: 0 
membind: 0 
preferred: 0

You can see that bootloader sent the commands numa_policy=interleave and numa=fake=8 to the kernel command line like but after boot there are only 1 numa node (can be seen using command numactl –show). To my knowledge 1 numa node is practically the same that numa disabled.

The dmesg indicates that there is a problem with this error:

[    0.000000] Malformed early option 'numa'
11

For the “Raspberry Pi 4 8GB” the default numa nodes should be 2. The Raspberry Pi bootloader detects the machine type and sent the necessary parameters to the kernel.

This is an example from the latest “Raspberry Pi OS trixie”:

# uname -a
Linux raspberrypi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux

# dmesg | grep -i numa
[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000001ffffffff]
[    0.000000] NUMA: Initialized distance table, cnt=2
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_headphones=0 cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=0 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0  numa=fake=2 system_heap.max_order=0 iommu_dma_numa_policy=interleave smsc95xx.macaddr=xx:xx:xx:xx:xx:xx vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  console=ttyS0,115200 console=tty1 root=PARTUUID=29cbc784-07 rootfstype=ext4 fsck.repair=yes rootwait plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=ES
[    0.000000] mempolicy: NUMA default policy overridden to 'interleave:0-1'
[    0.000000] DMA IOMMU NUMA default policy overridden to 'interleave:0-1'

# numactl --show
policy: interleave
preferred node: 0 (interleave next)
interleavemask: 0 1 
interleavenode: 0
physcpubind: 0 1 2 3 
cpubind: 0 1 
nodebind: 0 1 
membind: 0 1 
preferred: 0 1

You can see that the bootloader sent the commands numa_policy=interleave and numa=fake=2 to the kernel command line and after boot there are 2 numa nodes (can be seen using command numactl –show). This is the optimal situation.

Now we’ll see what is happening in “Ubuntu 26.04 resolute”:

# uname -a
Linux fprietog-test 7.0.0-1009-raspi #9-Ubuntu SMP PREEMPT_DYNAMIC Mon Apr 13 16:37:04 UTC 2026 aarch64 GNU/Linux

# dmesg | grep -i numa
[    0.000000] Malformed early option 'numa'
[    0.000000] NUMA: Faking a node at [mem 0x0000000000000000-0x00000001ffffffff]
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_headphones=0 numa_policy=interleave nvme.max_host_mem_size_mb=0 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0  numa=fake=2 system_heap.max_order=0 iommu_dma_numa_policy=interleave smsc95xx.macaddr=xx:xx:xx:xx:xx:xx vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  zswap.enabled=1 zswap.compressor=zstd multipath=off dwc_otg.lpm_enable=0 console=tty1 root=PARTUUID=29cbc784-0b rootfstype=ext4 panic=10 rootwait fixrtc quiet splash
[    0.000000] mempolicy: NUMA default policy overridden to 'interleave:0'
[    0.000000] DMA IOMMU NUMA default policy overridden to 'interleave:0'
[    0.010959] futex hash table entries: 1024 (65536 bytes on 1 NUMA nodes, total 64 KiB, linear).

# numactl --show
policy: interleave
preferred node: 0 (interleave next)
interleavemask: 0 
interleavenode: 0
physcpubind: 0 1 2 3 
cpubind: 0 
nodebind: 0 
membind: 0 
preferred: 0

You can see that bootloader sent the commands numa_policy=interleave and numa=fake=2 to the kernel command line like but after boot there are only 1 numa node (can be seen using command numactl –show).

The dmesg indicates that there is a problem with this error:

[    0.000000] Malformed early option 'numa'

All tests were done using a fresh install of “Ubuntu 26.04 resolute” from the iso. I’m waiting for the opening of the update window to update from an “Ubuntu 25.10 questing” and see what happens.

12

So my conclusion is that numa has been partially enabled in “Ubuntu 26.10 resolute” as numactl –show this in previous “Ubuntu 25.10 questing”:

# numactl --show
physcpubind: 0 1 2 3 
No NUMA support available on this system.

At this time it’s causing the abovementioned error at boot and I don’t know if having only 1 numa node enabled may be harming to the system or not.

I’m sorry but I can’t understand this decision:

we didn’t observe any significant improvements on Geekbench 6. So this isn’t included to reduce the delta from mainline kernel.

Sorry but a simple benchmark should meant nothing. The Raspberry Pi foundation says that the overall improvement is noticeable (more in the Raspberry Pi 5) and they enabled a whole environment for it.

In my opinion a very good opportunity to improve the Ubuntu LTS for Raspberry Pi has been lost just to “reduce the delta”, despite the fact that the Raspberry Pi is a very concrete machine so delta differences are not only unavoidable but also necessary .

Also, as there is that obvious numa at boot error in “Ubuntu 26.04” I suspect that maybe you have not implemented numa correctly and that’s why you find no improvement in your test.

Thanks and best regards.

13

Hi @fprietog

Yes, NUMA emulation for the Raspberry Pi is not included in Ubuntu 26.04 Resolute. We decided against it to avoid further deviation from the mainline kernel, especially since we didn’t see significant improvements with those patches.

14

So why is numa enabled?. It’s giving an error at every boot.

Have you read what I wrote above?

15

Keeping up with Raspberry Pi OS

Our primary goal has been to keep up with Raspberry Pi OS. We have done a good job of that recently, releasing an Ubuntu image for the Raspberry Pi 5 on the day of its launch.

This will never happens if instead of apply the improvements from The Raspberry Pi Foundation you priorize that the kernel has no differences to the mainline one.

I’m sorry but as an user I feel betrayed. I’m not going to waste my time with Ubuntu anymore.