mintupgrade ignores apt pin (-1) and force-reinstalls purged timeshift; broken has_space() check then fills root partition

Start by locating mintupgrade's package installation path and checking how it resolves apt candidates and priorities during the 22.1 to 22.3 upgrade. The report does not identify source files or tests, so trace the upgrade flow from its entry point and look for the handling of Timeshift. Done means an upgrade respects the reported -1 pin or clearly requires user confirmation before installing the package.

Summary

Upgrading 22.1 (xia) → 22.3 (zena), mintupgrade reinstalled timeshift despite the package being purged and explicitly pinned with Pin-Priority: -1 for all releases. The fresh install ran in first-run wizard mode, defaulted to RSYNC snapshots on the root partition, and created a snapshot estimated at 33.6 GB with only 23.1 GB free — Timeshift's own space check reported "0 B required" and "HAS_SPACE". This filled /, the upgrade was interrupted, and the system could only boot to a text console. Recovery required manually deleting the snapshot data.

Environment

Distribution: Linux Mint 22.1 → 22.3 upgrade attempt (reached sign-in on 22.3)
Kernel/arch: x86_64
CPU: Ryzen 7600X
Platform: B650I AX
Memory: 2x16GB DDR5-6000 CL30
Root filesystem: ext4, /dev/nvme0n1p2, 916G total, 23.1 GB free at start of upgrade
Desktop: Cinnamon (could not start after disk fill)
Username on system: [REDACTED]

Pre-upgrade state (deliberate configuration)

Timeshift had been previously removed specifically because of disk-consumption issues, and blocked from reinstallation:

$ cat /etc/apt/preferences.d/no-timeshift
Package: timeshift*
Pin: release *
Pin-Priority: -1

Prior to running mintupgrade, I had run:

sudo apt purge timeshift
sudo apt autoremove --purge

Current apt policy confirms the pin was and is valid and in force (candidate resolves to none):

$ apt policy timeshift
timeshift:
  Installed: 24.06.6+xia
  Candidate: (none)
  Version table:
     25.12.4+zena -1
        500 http://packages.linuxmint.com zena/backport amd64 Packages
 *** 24.06.6+xia -1
        100 /var/lib/dpkg/status
     24.01.1-1build2 -1
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages

Timeline (from /var/log/timeshift session logs, retained after the incident)

Timeshift's own logs document the entire sequence. Summary with key lines:

23:09:55 — Fresh install launches in first-run mode, selects defaults:

[23:09:55] Distribution: LinuxMint 22.1 (xia)
[23:09:55] Main: load_app_config()
[23:09:55] First run mode (config file not found)
[23:09:55] Selected default snapshot type: RSYNC

23:09:55 — Root partition auto-selected; free space measured:

[23:09:55] Selected snapshot device: /dev/nvme0n1p2
[23:09:55] Free space: 23,1 GB
[23:09:55] Mounted '/dev/nvme0n1p2' at '/run/timeshift/53878/backup'

23:09:57 — Wizard silently installs a cron task:

[23:09:57] Added cron task: /etc/cron.d/timeshift-hourly

23:10:17 — Estimator correctly computes snapshot size exceeding free space; space check simultaneously reports "0 B required":

[23:10:01] Export … rsync -ai --delete … --dry-run …
[23:10:17] First snapshot size: 33,6 GB
[23:10:17] File count: 979819
…
[23:10:17] SnapshotRepo: has_space() - 0 required (0 B)
[23:10:17] First snapshot requires: 0 B
[23:10:17] Status: NO_SNAPSHOTS_HAS_SPACE

23:10:21 → 23:13:32 — Snapshot proceeds anyway, rsync fails when the disk fills:

[23:10:21] Creating new snapshot...(RSYNC)
[23:10:21] Saving to device: /dev/nvme0n1p2 …
[23:13:32] AsyncTask: finish(): enter
[23:13:32] exit_code: -1
[23:13:32] E: rsync returned an error
[23:13:32] E: Failed to create new snapshot

Root was now full; Cinnamon could not start; system reached only the text console.

00:00:01 — The cron task installed by the first-run wizard fires an unsupervised second attempt (mid-recovery, free space 28.7 GB, estimate 34.2 GB — again proceeds):

[00:00:01] Daily snapshots are enabled
[00:00:12] First snapshot size: 34.2 GB
[00:00:12] Creating new snapshot...(RSYNC)
[00:00:12] Saving to device: /dev/nvme0n1p2 …

(This second attempt was killed manually; it was re-filling the freshly recovered root partition at midnight.)

Issues

Three distinct, compounding defects:

1. mintupgrade reinstalls a purged package against an explicit pin. Pin-Priority: -1 on timeshift* for all releases blocks installation via normal apt resolution (Candidate: (none) above). mintupgrade nonetheless installed timeshift during the upgrade. Whether via explicit-version install (which bypasses candidate resolution) or direct cache manipulation, the result is that user configuration deliberately disabling a package is silently overridden at the moment the user can least intervene.

2. Timeshift's has_space() reports 0 B required for first snapshots. In the same session where estimate_system_size() computed 33.6 GB, has_space() returned "0 required (0 B)" and NO_SNAPSHOTS_HAS_SPACE — i.e., "has space." The check appears to compute only the incremental delta relative to existing snapshots, which is necessarily zero on a first snapshot. A first snapshot of N GB against N-minus-10 free space therefore passes the pre-flight check. This turns any root-partition-targeted first run into a guaranteed disk fill, and it makes mid-operation disk exhaustion the expected outcome rather than an edge case.

3. First-run wizard defaults are unsafe and silent on this hardware. Fresh install (config purged, so first-run mode) auto-selects the root partition as snapshot target and silently installs /etc/cron.d/timeshift-hourly — combined with (1), a purged-and-pinned timeshift returns with automation armed and defaults the user never saw or chose. In my case this produced an unattended second snapshot attempt at midnight against a root partition that had just been manually recovered from the first attempt.

Expected behavior

• mintupgrade should respect an apt pin of -1 (or at minimum refuse to proceed / require explicit user confirmation rather than silently installing the blocked package).
• Timeshift should compare estimate_system_size() output against available free space before a first snapshot, not report "0 B required."
• First-run defaults should not silently install scheduled snapshots targeting the system's root partition without a space-feasibility check.

Workaround discovered after the fact

Recovery required Ctrl+Alt+F2 from the login screen, killing the rsync, removing /etc/cron.d/timeshift-hourly, and rm -rf of the partial snapshot data to make / bootable again.

Full session logs available on request (/var/log/timeshift/2026-10-18_23-09-55_gui.log, /var/log/timeshift/2026-10-19_00-00-01_backup.log).

Addendum

First time posting a formal bug report here, so apologies in advance if I've missed anything that "everybody knows" :). And yes I used an LLM to format my logs and ramblings into a readable format, I used Proton Lumo, if the reader cares.