Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-495GitHub issuePublicDecided· Out of scope

Kernel migration rejects valid FAT32 ESP discovered as systemd autofs

Reported by holystix04 · filed Sep 16, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

Kernel migration rejects valid FAT32 ESP discovered as systemd autofsrevision 1 · captured 2026-09-28 21:23 UTC via poll

System details

  • Omarchy: 4.0.4-1
  • systemd: 261.2-1
  • limine: 12.8.0-1
  • limine-mkinitcpio-hook: 1.38.0-1.1
  • UEFI system with a 2 GiB FAT32 EFI System Partition mounted at /boot
  • Root filesystem: Btrfs

What's wrong?

omarchy update fails during the kernel migration that installs linux-omarchy and rebuilds the Limine boot entry:

Running migration (1789325478)
Install the Omarchy kernel and make it the first Limine boot entry
ERROR: Boot path '/boot' is not a FAT32 filesystem.

The ESP is valid FAT32. The failure occurs because /boot is not listed in /etc/fstab, so systemd-gpt-auto-generator creates a generated /boot automount. Limine's check runs findmnt -n -o FSTYPE /boot and receives autofs for the outer mount instead of vfat, even though the underlying mount is the FAT32 ESP.

Observed before the fix:

/boot systemd-1              autofs
/boot /dev/...                vfat

The generated mount unit was equivalent to:

[Mount]
What=/dev/disk/by-diskseq/...
Where=/boot
Type=vfat

The Limine validation code in limine-mkinitcpio-hook checks the configured ESP path with mountpoint and findmnt, then rejects any result other than vfat. This makes the error message misleading: the underlying filesystem is FAT32, but the tool sees the systemd automount layer.

Steps to reproduce

  1. Install Omarchy with a GPT EFI System Partition that is not written to /etc/fstab and is instead discovered automatically by systemd.
  2. Boot the installed system.
  3. Run omarchy update.
  4. Reach migration 1789325478, which invokes limine-mkinitcpio linux-omarchy.
  5. Observe Boot path '/boot' is not a FAT32 filesystem.

Expected

A valid FAT32 EFI System Partition should pass the Limine check and the kernel migration should complete. If the mount layout is unsupported, the diagnostic should identify that /boot is an automount and explain that an explicit EFI mount entry is required.

Possible fixes

  • Ensure the installer writes the EFI System Partition to /etc/fstab as a vfat mount, avoiding an ambiguous systemd GPT auto-generated automount.
  • Add an Omarchy migration or preflight check for an ESP that is valid underneath a systemd automount.
  • Improve the Limine hook validation to resolve the underlying filesystem or report the automount layer accurately.
  • Add a test covering a systemd-generated EFI automount.

An explicit /boot vfat entry in /etc/fstab causes systemd to generate a normal boot.mount; findmnt then reports vfat and the Limine check can proceed.

Related

  • #11821 discusses missing free-space checks for the ESP during updates, but does not cover this filesystem-type detection failure.
  • #7867 discusses a different installer ESP-layout problem involving redundant ESPs and dual boot.

No filesystem formatting, repartitioning, or EFI data loss is involved in this report.

View raw text
## System details

- Omarchy: 4.0.4-1
- systemd: 261.2-1
- limine: 12.8.0-1
- limine-mkinitcpio-hook: 1.38.0-1.1
- UEFI system with a 2 GiB FAT32 EFI System Partition mounted at `/boot`
- Root filesystem: Btrfs

## What's wrong?

`omarchy update` fails during the kernel migration that installs `linux-omarchy` and rebuilds the Limine boot entry:

```text
Running migration (1789325478)
Install the Omarchy kernel and make it the first Limine boot entry
ERROR: Boot path '/boot' is not a FAT32 filesystem.
```

The ESP is valid FAT32. The failure occurs because `/boot` is not listed in `/etc/fstab`, so `systemd-gpt-auto-generator` creates a generated `/boot` automount. Limine's check runs `findmnt -n -o FSTYPE /boot` and receives `autofs` for the outer mount instead of `vfat`, even though the underlying mount is the FAT32 ESP.

Observed before the fix:

```text
/boot systemd-1              autofs
/boot /dev/...                vfat
```

The generated mount unit was equivalent to:

```ini
[Mount]
What=/dev/disk/by-diskseq/...
Where=/boot
Type=vfat
```

The Limine validation code in `limine-mkinitcpio-hook` checks the configured ESP path with `mountpoint` and `findmnt`, then rejects any result other than `vfat`. This makes the error message misleading: the underlying filesystem is FAT32, but the tool sees the systemd automount layer.

## Steps to reproduce

1. Install Omarchy with a GPT EFI System Partition that is not written to `/etc/fstab` and is instead discovered automatically by systemd.
2. Boot the installed system.
3. Run `omarchy update`.
4. Reach migration `1789325478`, which invokes `limine-mkinitcpio linux-omarchy`.
5. Observe `Boot path '/boot' is not a FAT32 filesystem`.

## Expected

A valid FAT32 EFI System Partition should pass the Limine check and the kernel migration should complete. If the mount layout is unsupported, the diagnostic should identify that `/boot` is an automount and explain that an explicit EFI mount entry is required.

## Possible fixes

- Ensure the installer writes the EFI System Partition to `/etc/fstab` as a `vfat` mount, avoiding an ambiguous systemd GPT auto-generated automount.
- Add an Omarchy migration or preflight check for an ESP that is valid underneath a systemd automount.
- Improve the Limine hook validation to resolve the underlying filesystem or report the automount layer accurately.
- Add a test covering a systemd-generated EFI automount.

An explicit `/boot` `vfat` entry in `/etc/fstab` causes systemd to generate a normal `boot.mount`; `findmnt` then reports `vfat` and the Limine check can proceed.

## Related

- #11821 discusses missing free-space checks for the ESP during updates, but does not cover this filesystem-type detection failure.
- #7867 discusses a different installer ESP-layout problem involving redundant ESPs and dual boot.

No filesystem formatting, repartitioning, or EFI data loss is involved in this report.

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 14:03 UTC