Raspberry Pi OS Moves to the Linux 6.18 LTS Kernel With an Updated LabWC Compositor

In brief — 2026 · Raspberry Pi OS jumps to Linux 6.18 LTS and refreshes the LabWC compositor, giving the Pi 4, Pi 5, and Zero 2 W a longer maintenance window, a leaner Wayland desktop, and updated drivers carried in from mainline.

As of 2026, Raspberry Pi OS has shifted from the Linux 6.6 LTS base it has shipped on for the past two release cycles to the newly minted Linux 6.18 LTS kernel, and at the same time has bumped the version of LabWC powering the default Wayland desktop. Per Phoronix, the rebase lands across the Pi 4, Pi 5, Zero 2 W, and Compute Module families in the same image, with the Raspberry Pi Foundation staging the rollout through standard apt updates rather than forcing a reflash. Raspberry Pi Foundation news posts state the move is timed to align Raspberry Pi OS with an LTS branch that will receive upstream maintenance into 2028, materially extending the security window for the millions of Pi boards already in the field.

For Pi builders this is the most consequential base-system change since the 2024 jump to Wayland-by-default. The kernel skip from 6.6 to 6.18 collapses roughly two years of upstream work — KVM improvements on ARM64, the maturing of sched_ext, eBPF feature growth, a refreshed power-management framework, and a long tail of Broadcom VideoCore VII fixes — into a single update. LabWC, the lightweight Wayland compositor that replaced Wayfire on the Pi 5 in 2024 and on the Pi 4 in 2025, picks up its own multi-version refresh in the same drop.

What happened

Per the Raspberry Pi Foundation news feed, the 2026 image of Raspberry Pi OS — built atop Debian 13 "Trixie" — now ships with Linux 6.18 as its default kernel on all currently supported boards. The previous image series had been pinned to 6.6 LTS since late 2024, which is itself an LTS line; the Foundation has historically waited for the next stable LTS to land before rebasing, rather than tracking the rolling stable kernel. Kernel.org released 6.18 as an LTS at the end of 2025, and Raspberry Pi OS picked it up roughly six months later after the customary Broadcom VideoCore and bcm2712/bcm2711 device-tree work was upstreamed and validated.

The LabWC update accompanying the kernel rebase moves the compositor several point releases forward, picking up tearing-control protocol support, session-lock improvements, and lower-latency cursor handling. The default panel — wf-panel-pi, inherited from the Wayfire era — has been updated to talk to the newer LabWC IPC surface, and the Foundation has refreshed the default theme to track the Debian 13 GTK4 stack.

Existing images can move forward with the usual two-command upgrade path:

sudo apt update
sudo apt full-upgrade
sudo reboot

On a typical Pi 4 with an Raspberry Pi 4 Model B 8GB and a healthy SD card or USB SSD boot device, that sequence pulls the new linux-image-rpi-2712 and linux-image-rpi-v8 packages, regenerates the initramfs, and reboots into 6.18 without re-imaging. The Foundation's news post recommends rpi-eeprom-update first on Pi 5 to align the bootloader, and a clean snapshot of /boot/firmware/config.txt before kicking the upgrade off.

Why it matters: LTS support window and desktop responsiveness for Pi builders

The most important practical change is the calendar. Linux 6.6 LTS is currently scheduled for maintenance through December 2026 in the regular LTS table and longer under the Civil Infrastructure Platform's super-long-term branch. Linux 6.18 LTS, per the same release-tracking convention, is slated for maintenance through 2028. By rebasing now, the Foundation buys roughly two extra years of upstream patches without an architectural break. For Pi builders running headless home automation, kiosks, signage, or Pi-based light industrial controllers, that lines up nicely with typical deployment cycles where re-imaging the field is expensive.

Per Phoronix running coverage of the 6.18 cycle, the ARM64 changes most relevant to the Pi are concentrated in five buckets:

• KVM-on-ARM64 picks up nested virtualization improvements that matter for Pi 5 users running Docker, LXC, or microVM stacks.
• sched_ext matures, allowing the Foundation to ship a Pi-tuned scheduler extension without patching the core scheduler.
• eBPF feature growth allows the desktop tracing stack (bpftrace, bcc) to work out of the box on the stock Pi kernel for the first time without a linux-headers build.
• The energy-model and cpufreq subsystems get rework that helps the Pi 5's Cortex-A76 cores throttle more gracefully under sustained load.
• VideoCore VII driver fixes, carried via the v3d and vc4 DRM drivers, smooth out a long tail of HDMI handshake and 4K60 stability bugs.

On the desktop side, LabWC's refreshed cursor and tearing-control paths shave latency on the Pi 5's HDMI output, and on lower-end boards such as the Raspberry Pi Zero 2 W the lean Wayland stack remains the right call: the Zero W simply does not have the headroom to run a full GNOME or KDE session, and a properly tuned LabWC plus a wf-panel-pi is the closest the Pi line gets to a "snappy" desktop on 512 MB of RAM.

Kernel 6.6 LTS to 6.18 LTS at a glance

The skip is large enough that it is worth laying out the deltas explicitly. The summary below reflects upstream Kernel.org release notes and Phoronix benchmark coverage across the 6.7 through 6.18 cycle.

The Pi 4 still tops out at the Cortex-A72 baseline regardless of kernel version, but the wireless and DRM work is meaningful even there, and the security tightening is exactly what extends the practical service life of a 2019-era board.

The source

The two primary references are the Raspberry Pi Foundation software hub, which carries the current image and the canonical upgrade instructions, and the Foundation's news feed, which holds the release announcement and the LabWC notes. Phoronix has the most useful third-party coverage of the kernel jump itself: a multi-part series tracking ARM64 changes through the 6.7 → 6.18 cycle, plus standalone pieces on sched_ext, the refreshed energy model, and the VideoCore driver work. The Raspberry Pi OS changelog at /usr/share/doc/raspberrypi-archive-keyring/changelog.Debian.gz on any updated image carries the package-level delta if you want to audit exactly what shifted.

LabWC vs Wayfire vs X11: what changed for the Pi desktop

The Pi desktop has now passed through three generations of window system in five years, and the 6.18 image cements the LabWC-only path. The trade-offs are easy to summarize.

The LabWC choice is largely about resource budget. Wayfire is more visually ambitious, with effects pipelines and 3D desktop transforms, but it carries a working set the Zero 2 W cannot afford. LabWC takes the openbox-style "stack of wlroots modules" approach: it leans on wlroots for the heavy lifting, exposes an openbox-compatible config syntax, and stays out of the way. On 8 GB Pi 5 boards the difference is mostly invisible; on 1 GB and 2 GB Pi 4 boards and on the Zero 2 W, LabWC is the difference between a usable desktop and a swap-thrashing one.

What it means for existing Pi users

The day-to-day implications break down by deployment shape.

For desktop users on a Pi 4 or Pi 5, the upgrade should be uneventful. The kernel rebase is invisible to most applications, LabWC retains its config file format, and the panel layout carries forward. Browser and electron-app workloads benefit from the refreshed v3d driver path; Chromium hardware video decode continues to work where it did before, and a regression-free upgrade is the expected outcome.

For headless users running home automation, Pi-hole, NAS roles backed by a Crucial BX500 1TB SATA SSD on USB 3, or self-hosted dashboards, the upgrade is mostly a security and container story. The 6.18 KVM and eBPF improvements meaningfully change what is reasonable to run on a Raspberry Pi 5 8GB — small VMs become more practical, and Cilium-style eBPF networking works without compiling kernel headers.

For education and signage deployments, the LTS calendar is the headline. A fleet imaged today on 6.18 LTS gets routine security updates until 2028 without an OS rebase, which matters when the fleet is bolted to walls in classrooms and museums.

For maker and GPIO-heavy projects, the standard caution applies: kernel rebases are the moment when an obscure out-of-tree driver or a HAT vendor's DKMS module stops building. Most mainstream HATs — Sense HAT, PoE+ HAT, Pimoroni's Wayland-aware boards — are validated by the Foundation before the image ships. Anything bespoke, including custom kernel modules, custom device-tree overlays, and DKMS-shipped Wi-Fi dongles, should be re-tested.

Common pitfalls

Several rough edges have surfaced consistently across the kernel-skip releases the Foundation has shipped historically, and the 6.18 rebase is unlikely to be different.

Driver compatibility. Vendor-shipped DKMS modules occasionally fail to build against a kernel that has reworked an internal API. The fix is almost always to pull the vendor's latest source or to disable the module temporarily. The Foundation's news posts call out specific known-broken drivers each cycle; per Raspberry Pi Foundation guidance, the cleanest pre-upgrade step is dkms status to enumerate what is installed.

GPIO and libgpiod. Per the Raspberry Pi Foundation software hub, the GPIO stack has been steadily moving from sysfs and the legacy RPi.GPIO Python bindings to libgpiod and gpiozero. The 6.18 kernel keeps the legacy sysfs paths working for now, but scripts that hard-coded /sys/class/gpio should be migrated. The drop-in path is pinctrl for shell scripts and gpiozero for Python.

Camera stack. libcamera is the supported path on Wayland; the older raspistill/raspivid tools have been deprecated for several releases. After the 6.18 upgrade the rpicam-* family is the canonical CLI. Existing scripts calling raspistill should be migrated to rpicam-still; the flag surface is similar but not identical.

HDMI and 4K displays. The new vc4/v3d DRM patches generally improve handshake reliability with stubborn 4K displays, but a handful of monitors with aggressive DDC behaviour have historically needed hdmi_force_hotplug=1 and a fixed hdmi_group/hdmi_mode in /boot/firmware/config.txt. Keep that config snapshotted before upgrading.

SD-card endurance. A kernel rebase pulls a substantial amount of data through the boot device. SD cards near end-of-life sometimes pick this moment to fail. Per general Raspberry Pi Foundation guidance, the safer pattern on any non-trivial Pi — particularly home-server roles — is to boot from a USB-attached SSD, which is where a 1 TB BX500-class drive earns its keep.

LabWC config drift. The LabWC refresh tightens a few config defaults. Custom rc.xml files that worked under the 2024 LabWC may emit warnings under the 2026 build. The warnings are usually cosmetic — the compositor falls back to defaults — but for production kiosks it is worth diffing the shipped /etc/xdg/labwc/rc.xml against any local override.

A worked upgrade example

A representative upgrade on a Pi 4 8 GB running the prior 2025 image, booting from an SD card with /home on a USB SSD, would look approximately like this. The wall-clock figures reflect typical residential gigabit; the Pi-side bottleneck is SD-card write speed.

# 1. Snapshot config
sudo cp /boot/firmware/config.txt /boot/firmware/config.txt.pre618
sudo cp /boot/firmware/cmdline.txt /boot/firmware/cmdline.txt.pre618

# 2. Refresh the bootloader (Pi 5 only)
sudo rpi-eeprom-update -a

# 3. Update package metadata
sudo apt update

# 4. Pull the kernel + LabWC + userland
sudo apt full-upgrade -y

# 5. Reboot into 6.18
sudo reboot

# 6. Verify
uname -r # expect 6.18.x
labwc --version # expect the refreshed build
dpkg -l | grep -E 'linux-image-rpi|labwc'

Total download is typically 800 MB to 1.2 GB depending on the prior state of the image. End-to-end wall clock on a Pi 4 with a Class A2 SD card is roughly 25-40 minutes; on a USB-SSD-booted Pi 5 it is closer to 8-12 minutes.

If a regression appears, the rollback path is the canonical Raspberry Pi OS one: write the prior image to a spare card with rpi-imager, boot it, and remount the upgraded card's /home for data recovery. The Foundation does not officially support kernel downgrade via apt, although apt install linux-image-rpi-v8=<old-version> will work if the package version is still in the archive.

Where the Pi line goes next

The 2026 rebase is also a signal about the Foundation's medium-term direction. Per the Raspberry Pi Foundation news feed, Wayland-by-default is now uniform across the product line, the legacy X11 session is no longer offered on new images, and the GPIO stack is consolidating around libgpiod. The next image cycle is expected to focus on tightening the LabWC experience and expanding rpi-imager and rpi-connect rather than another kernel skip. A Pi 6 announcement has not been made as of mid-2026; if and when it lands, the 6.18 LTS base buys the Foundation room to focus engineering effort on board bring-up rather than userland churn.

For builders evaluating Pi-class hardware against alternatives — RK3588 boards, the Orange Pi 5 line, the Radxa Rock series, the Jetson Orin Nano on the higher end — the LTS-window argument is now stronger than it has been in years. Per Phoronix coverage of comparable boards, very few non-Pi SBC vendors maintain the same cadence of upstream kernel work; the Foundation's willingness to skip from 6.6 to 6.18 in a single image is a structural advantage.

Shop the hardware this update supports

Every board on Raspberry Pi OS's supported list picks up the 6.18 LTS window through 2028. If you are still spinning up a fleet, these are the three current-generation SKUs the rebase covers:

• Raspberry Pi 5 8GB — the KVM, sched_ext, and eBPF headline features land hardest here. Best for containers, small VMs, and Pi-based home servers where the 8 GB ceiling is the difference between "usable" and "swap-thrashing".
• Raspberry Pi 4 Model B 8GB — the mainstream deployment board, and the one most likely to be in your existing fleet. The security tightening and DRM fixes extend its practical service life through the 2028 LTS window.
• Raspberry Pi Zero 2 W — LabWC is the only sane Wayland compositor on 512 MB of RAM. If you are deploying kiosk-class Zero 2 W builds, the 6.18 image is the right base to standardize on.

Pair any of these with a USB-attached SSD such as the Crucial BX500 1TB if the deployment is anything more demanding than casual desktop use — the 6.18 kernel and package upgrades pull hundreds of megabytes through the boot device and SD-card endurance is the failure mode you will hit first.

Related reading on SpecPicks

• Raspberry Pi 4 as a Home Assistant Hub (2026)
• Raspberry Pi Zero W FM Radio Station Build (2026)
• Raspberry Pi category index
• Best SSDs for Pi USB boot (buying guide)
• Pi 5 vs Pi 4: when the upgrade is worth it

Citations and sources

• Phoronix
• Raspberry Pi Foundation — Software
• Raspberry Pi Foundation — News

This piece is editorial synthesis based on publicly available information. No independent first-party benchmarking is reported.