Proof Portal

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-1651GitHub issuePublicReceived

Free space install (alongside exsisting data) Doesn't work alongside non-OS partitions

Reported by Matredit · filed Aug 19, 2026Closed upstream on 2026-10-08 by the bot omarchybot, as a duplicate (target not recorded).

Received and recorded verbatim. Nothing has been checked yet.

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?
Not yet mapped to any requirement or component.
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?
Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.

Original report

Free space install (alongside exsisting data) Doesn't work alongside non-OS partitionsrevision 1 · captured 2026-09-28 21:29 UTC via poll

System details

Omarchy 4.0.0

What's wrong?

When a disk has some data partition, e.g. like here:

<img width="1441" height="122" alt="Image" src="https://github.com/user-attachments/assets/398050f5-02ca-4ed2-90d8-54e85d3b34b2" />

and someone tries to install Omarchy 4 alongside this partition, it will fail on "Creating Btrfs filesystem and subvolumes":

<img width="1168" height="710" alt="Image" src="https://github.com/user-attachments/assets/2f665397-da1e-40dd-901e-29209534659b" />

It doesn't create any partitions when fail happens, here's still that ntfs partition and ~79G of unallocated space:

<img width="884" height="685" alt="Image" src="https://github.com/user-attachments/assets/6a082523-0968-4e0b-a4cc-7cceb224f01d" />

If I'll create some dummy EFI partition (I created 256M EFI System partition in cfdisk and formatted it to FAT32 with mkfs.fat) it will actually work.
The screenshot of me doing that and relaunching the script:

<img width="1000" height="803" alt="Image" src="https://github.com/user-attachments/assets/2a3f1204-e151-4abf-9d7e-6828f919ee27" />

Now It installs successfully on that unallocated free space.
Inside freshly installed Omarchy I end up with my dummy EFI without which it wouldn't have installed:

<img width="1256" height="1377" alt="Image" src="https://github.com/user-attachments/assets/df91a3ad-3948-4d98-9ea6-e655db99d8c0" />

The dummy EFI was empty except for random-seed binary file. When I was doing this on other device with empty linux fs partition (instead of ntfs like here) that EFI was completely empty. When I deleted that dummy EFI partition Omarchy still booted normally.

Screenshot of EFI partition contents:

<img width="741" height="585" alt="Image" src="https://github.com/user-attachments/assets/0061b6a9-a968-4e13-ab5a-de73fba34119" />

Inside the /var/log/omarchy-install.log there's nothing what's not on the first photo, the initial installation attempt that has failed ends at line 212, then I do that dummy EFI thing and all following 3000 lines is I guess just Omarchy successfully installing.
here's the file: omarchy-install.log

The 'free space install' feature is really nice thing, when I was trying to install Omarchy 3.8.4 following the old manual just days before 4.0 was released the installation script was failing, and this feature on Omarchy 4 is just what I needed.
It's weird that it doesn't work when there's no other OS on a disk, only a data partition, I don't think it's intended, since it doesn't actually use the dummy EFI it currently looks for.

I didn't look at any dmesg which is mentioned in the error:

mount: /mnt/boot: fsconfig() failed: Can't find a SQUASHFS superblock on sda2.
       dmesg(1) may have more information after failed mount system call.
mounting the ESP failed (exit 32)

I'm sure this can be reproduced on any device (I did that on two: a 10 years old laptop and a PC).

View raw text
### System details

Omarchy 4.0.0

### What's wrong?

When a disk has some data partition, e.g. like here:

<img width="1441" height="122" alt="Image" src="https://github.com/user-attachments/assets/398050f5-02ca-4ed2-90d8-54e85d3b34b2" />

and someone tries to install Omarchy 4 alongside this partition, it will fail on "Creating Btrfs filesystem and subvolumes":

<img width="1168" height="710" alt="Image" src="https://github.com/user-attachments/assets/2f665397-da1e-40dd-901e-29209534659b" />

It doesn't create any partitions when fail happens, here's still that ntfs partition and ~79G of unallocated space:

<img width="884" height="685" alt="Image" src="https://github.com/user-attachments/assets/6a082523-0968-4e0b-a4cc-7cceb224f01d" />

If I'll create some dummy EFI partition (I created 256M EFI System partition in cfdisk and formatted it to FAT32 with mkfs.fat) it will actually work.
The screenshot of me doing that and relaunching the script:

<img width="1000" height="803" alt="Image" src="https://github.com/user-attachments/assets/2a3f1204-e151-4abf-9d7e-6828f919ee27" />

Now It installs successfully on that unallocated free space.
Inside freshly installed Omarchy I end up with my dummy EFI without which it wouldn't have installed:

<img width="1256" height="1377" alt="Image" src="https://github.com/user-attachments/assets/df91a3ad-3948-4d98-9ea6-e655db99d8c0" />

The dummy EFI was empty except for random-seed binary file. When I was doing this on other device with empty linux fs partition (instead of ntfs like here) that EFI was completely empty. When I deleted that dummy EFI partition Omarchy still booted normally.

Screenshot of EFI partition contents:

<img width="741" height="585" alt="Image" src="https://github.com/user-attachments/assets/0061b6a9-a968-4e13-ab5a-de73fba34119" />

Inside the `/var/log/omarchy-install.log` there's nothing what's not on the first photo, the initial installation attempt that has failed ends at line 212, then I do that dummy EFI thing and all following 3000 lines is I guess just Omarchy successfully installing.
here's the file: [omarchy-install.log](https://github.com/user-attachments/files/31230630/omarchy-install.log)

The 'free space install' feature is really nice thing, when I was trying to install Omarchy 3.8.4 following [the old manual](https://learn.omacom.io/2/the-omarchy-manual/96/manual-installation) just days before 4.0 was released the installation script was failing, and this feature on Omarchy 4 is just what I needed.
It's weird that it doesn't work when there's no other OS on a disk, only a data partition, I don't think it's intended, since it doesn't actually use the dummy EFI it currently looks for.

I didn't look at any dmesg which is mentioned in the error:
```
mount: /mnt/boot: fsconfig() failed: Can't find a SQUASHFS superblock on sda2.
       dmesg(1) may have more information after failed mount system call.
mounting the ESP failed (exit 32)
```
I'm sure this can be reproduced on any device (I did that on two: a 10 years old laptop and a PC).
  • omarchy-install.log
  • 398050f5-02ca-4ed2-90d8-54e85d3b34b2
  • 2f665397-da1e-40dd-901e-29209534659b
  • 6a082523-0968-4e0b-a4cc-7cceb224f01d
  • 2a3f1204-e151-4abf-9d7e-6828f919ee27
  • df91a3ad-3948-4d98-9ea6-e655db99d8c0
  • 0061b6a9-a968-4e13-ab5a-de73fba34119

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.

No decision has been recorded yet.