Running Ubuntu on the Lenovo IdeaPad Duet

By Valentin Haudiquet
Software Engineer

I am the owner of a Lenovo IdeaPad Duet, which is essentially a 2-in-1 ARM64 tablet running ChromeOS. My journey with this device has been a series of OS experiments: I started with ChromeOS, transitioned to postmarketOS, and eventually hit a wall when the latter suddenly stopped working.

This failure provided the perfect excuse for some firmware hacking to see if I could get Ubuntu running on the hardware.

🛠️ Hardware Specifications

The Lenovo IdeaPad Duet is a compact device designed for portability. Here are the technical details:

I originally bought this during my first year of engineering school. I love 10" laptops for their portability, and I hoped the stylus would improve my note-taking workflow (though it turns out that wasn't for me).

The Road to Ubuntu

Initially, I wanted to develop Android apps natively on the device. However, the experience was satisfying disappointing; ChromeOS performance was lacking, and running everything through a Linux container felt clunky. I craved a "real" Linux distribution—something based on Alpine Linux or similar—with a full Desktop Environment (DE) and native tooling.

The postmarketOS Phase

Installing postmarketOS was straightforward thanks to their excellent documentation. The process followed these steps:

• Enable 'developer mode' in the firmware.
• Download the OS image.
• Flash the image to a USB drive.
• Boot from the USB via the developer menu.
• Install the image to the internal eMMC.

While the developer menu offers a Start legacy BIOS option, it does nothing on this device; it's likely a leftover from x86 Chromebook firmware.

I chose the GNOME image since it's my primary DE on my main PC. Unfortunately, GNOME proved too resource-heavy for the MT8183 and $4\text{ GiB}$ of RAM. It felt sluggish and overly complex for a minimalist setup. In hindsight, a terminal-centric tiling window manager would have been a much better fit.

The Breaking Point

Everything worked until I updated to postmarketOS 26.06. Suddenly, the device refused to reboot. While I could still boot the older 25.12 version, the 26.06 image failed even when run from a USB stick. Something in the update had silently broken the boot process.

The Ubuntu Bring-up

As a developer at Canonical working on RISC-V bring-up, I noticed that the necessary drivers for the Duet had finally hit the mainline kernel. This made an Ubuntu installation feasible.

The "Dumb" Installation Method

Since I wasn't entirely sure how postmarketOS handled the boot flow, I decided to try the simplest (and perhaps most elegant dumbest) approach: replace the postmarketOS 26.06 rootfs with an Ubuntu one.

First, I checked the partition table using fdisk on /dev/mmcblk0:

1. A mysterious ChromeOS Kernel partition.
2. A /boot EFI partition.
3. The rootfs partition.

I then executed the following sequence:

# Mount the rootfs partition
mount /dev/mmcblk0p3 /mnt

# Clear the existing postmarketOS files
rm -rf /mnt/*

# Download the minimal Ubuntu base image
curl -L -O https://cdimage.ubuntu.com/.../ubuntu-base-26.04-base-arm64.tar.gz

# Extract the Ubuntu rootfs to the partition
tar -C /mnt -xzf ubuntu-base-26.04-base-arm64.tar.gz

Testing the Setup

I used a postmarketOS 25.12 USB stick to chroot into the new Ubuntu installation at /mnt. At this stage, I was running the 6.12.87-mt81 kernel from the USB stick.

Surprisingly, when I rebooted from internal storage, it worked! This proved that the 26.06 failure wasn't the kernel, but rather something in the rootfs startup scripts. The device booted into the 6.18.44-mt81 kernel.

Final Polishing

There were two remaining hurdles:

1. Configuration: The system identified itself as localhost, requiring some basic setup (though my user account was already created via chroot).
2. Connectivity: Wi-Fi was dead because the minimal Ubuntu rootfs lacked the specific firmware for the postmarketOS kernel.

While I could have simply copied the firmware from the postmarketOS 26.06 image, that would have tethered me to their kernel. I wanted a pure Ubuntu experience.

The Solution: I installed the linux-generic package from the official archives. This placed vmlinuz and initrd into the /boot partition (/dev/mmcblk0p2). I also manually copied the upstream DTB (Device Tree Blob) into /boot to ensure the kernel had the correct hardware description.

Despite my expectations that it would crash, the result was a success. Running fastfetch confirmed that I was now running a full Ubuntu system with its own native kernel.