tik installer leaves /etc/fstab.repart after failed install, breaking all subsequent attempts

[davbenx]

Describe the bug

The tik installer fails in two chained ways on first-time installation:

1. The first install attempt completes all disk operations successfully (wipe, ESP format, LUKS encryption, btrfs population) but then fails at the very end with Failed to reread partition table: Device or resource busy, causing systemd-repart to exit with code 1.

2. Because tik does not clean up /etc/fstab.repart after the crash, every subsequent install attempt fails immediately with Failed to link temporary file to /etc/fstab.repart: File exists — making the installer appear permanently broken with no actionable error message shown to the user.

---

To Reproduce

1. Boot the Aeon installer USB on a machine with an NVMe drive (Samsung MZALQ512HBLU-00BL2, 476.9GB) alongside a separate SATA SSD with Windows.
2. Select the NVMe as the installation target and confirm.
3. Observe the first attempt fail with Device or resource busy after all disk operations have completed.
4. Dismiss the error and click Install again.
5. Observe all subsequent attempts fail immediately with Failed to link temporary file to /etc/fstab.repart: File exists.

---

Expected behavior

First attempt: systemd-repart should either succeed in rereading the partition table or handle the Device or resource busy condition gracefully without treating it as a fatal error.

All attempts: tik should remove /etc/fstab.repart as part of its error cleanup so that retrying the installer works correctly.

---

Workaround

From a terminal in the Aeon live environment, before retrying:

sudo rm /etc/fstab.repart

---

Screenshots

N/A — see tik.log below.

---

tik log

Key excerpts:

First attempt — root cause:

Syncing future partition 1 contents to disk.
Adding new partition 0 to partition table.
Adding new partition 1 to partition table.
Writing new partition table.
Informing kernel about changed partitions...
Failed to reread partition table: Device or resource busy
[tik][20260419-09:28:10][pkexec][1] systemd-repart ... FAILED

Second and third attempts — cascading failure:

[tik][20260419-18:09:20][dump_image_repart_self] self-deploying
Failed to link temporary file to /etc/fstab.repart: File exists
[tik][20260419-18:09:20][pkexec][1] systemd-repart ... FAILED
[tik][20260419-18:09:20][ERROR] Command systemd-repart ... FAILED

Full tik.log attached.

---

**`NAME="Aeon"

VERSION="20260416"

ID="aeon"
ID_LIKE="suse opensuse opensuse-tumbleweed opensuse-microos opensuse-aeon microos"
VERSION_ID="20260416"
PRETTY_NAME="Aeon"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:aeon:20260416"
BUG_REPORT_URL="https://aeondesktop.org/reportbug"
SUPPORT_URL="https://aeondesktop.org/bugs"
HOME_URL="https://aeondesktop.org/"
DOCUMENTATION_URL="https://aeondesktop.org/docs"
LOGO="distributor-logo-Aeon"`**

---

Additional context

• Hardware: Lenovo V15, AMD CPU, AMD PSP (fTPM), Secure Boot enabled, TPM PolicyAuthorizeNV supported (Default Mode confirmed in log)
• NVMe: Samsung MZALQ512HBLU-00BL2 476.9GB
• Second disk: CT500MX500SSD1 465.8GB (SATA, Windows, untouched)
• Installer USB written with Fedora Media Writer in DD mode from Windows
• NVMe was fully wiped with wipefs -a before the first attempt shown in this log
• SBAT policy was reset with mokutil --set-sbat-policy delete prior to installation

tik.log

[jaminsamuel18]

Wow, incredible! I thought this problem had already been resolved. This problem has been reported for weeks in different tickets prior to this one.