Skip to content

Proposal: Support for UKI (Unified Kernel Images) synchronization during Btrfs backup and restore #543

Description

@jairogaleano

Title Proposal

Proposal: Support for UKI (Unified Kernel Images) synchronization during Btrfs backup and restore

Description

With the increasing adoption of UKIs (Unified Kernel Images) and systemd-boot, there is a growing challenge for system restore utilities like Timeshift.

In a typical Btrfs setup, Timeshift creates snapshots of the root subvolume (@). However, the EFI System Partition (ESP), where the UKIs reside, is usually a separate FAT32 partition and is not included in the Btrfs snapshot.

The Problem

When a user restores a snapshot from a previous state:

  1. The root filesystem (/) is reverted to an older version (including old kernel modules).
  2. The ESP remains in its current state (with a newer UKI/Kernel).
  3. Result: The system fails to boot or modules fail to load because the restored /lib/modules/ do not match the newer kernel in the ESP.

Proposed Solution

I have developed and tested a hook-based approach that ensures atomic synchronization between the root snapshot and the UKI. The logic is as follows:

  1. Pre-Backup Hook: Just before the snapshot is created, the current functional UKI is copied from the ESP to a directory inside the root (e.g., /etc/timeshift/uki-backup/). This ensures the UKI is "captured" inside the Btrfs snapshot.
  2. Post-Restore Hook: Immediately after a restoration, the script takes the restored UKI from /etc/timeshift/uki-backup/ and copies it back to the physical ESP partition, ensuring the boot binary matches the restored modules.

Reference Implementation

I have published a working implementation with robust scripts that handle:

  • Dynamic detection of /boot vs /efi mount points.
  • Safe remounting of the ESP (handling RO/RW states).
  • Integration with timeshift-autosnap and native Timeshift restore hooks.

You can review the logic here: https://github.com/jairogaleano/timeshift-uki-hooks

Goal

I believe this logic (or a native version of it) would be a valuable addition to Timeshift to support modern Linux boot standards. At the very least, providing an official or documented way to handle these "out-of-snapshot" boot files would greatly benefit the community.

I'm open to discussing how this could be integrated into the core or if there's interest in a pull request regarding hook documentation.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions