Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
install/hardware/intel/fred.sh writes a `fred=on` cmdline that Linux 7.1 no longer reads
Reported by Faxulous · filed Sep 4, 2026 · open at source
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
System details
Dell XPS 16 DA16260, Intel Panther Lake (Core Ultra 300), Omarchy 4.0.0.alpha, linux-ptl 7.1.8.arch1-2 (stock linux 7.1.9.arch1-2 also installed)
What's wrong?
On an Intel Panther Lake machine, the FRED drop-in installed by install/hardware/intel/fred.sh has no effect on Linux 7.1, and the kernel hands the parameter to user space instead:
$ cat /etc/limine-entry-tool.d/intel-panther-lake-fred.conf
# Intel Panther Lake FRED support
KERNEL_CMDLINE[default]+=" fred=on"
$ journalctl -k -b 0 | grep 'Unknown kernel command line'
kernel: Unknown kernel command line parameters "splash cryptdevice=PARTUUID=…:root fred=on", will be passed to user space.FRED is enabled regardless: CONFIG_X86_FRED=y, the CPU advertises the fred flag, and asm_fred_entrypoint_user shows up in stack traces.
It was correct when it landed (91af40f, "Enable fred=on on intel ptl machines", 2026-04-30). On 7.0 the option was required — arch/x86/kernel/cpu/common.c:1761 at v7.0:
arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
if (arglen != 2 || strncmp(arg, "on", 2))
setup_clear_cpu_cap(X86_FEATURE_FRED);ac66a73be03a ("x86/fred: Enable FRED by default", merged for 7.1-rc1) inverted that. Same file, common.c:1764 at v7.1:
arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
if (arglen == 3 && !strncmp(arg, "off", 3))
setup_clear_cpu_cap(X86_FEATURE_FRED);Only off is read; on matches nothing. kernel-parameters.txt at v7.1 now reads "on: enable FRED when it's present, the default setting."
The log line above is the second half: fred= has no __setup() stub, so it misses the registered-parameter sweep. clearcpuid=/setcpuid= carry dummy stubs at common.c:2231/2237 for exactly this, per the comment above them — "to prevent them from becoming an environment variable for init".
Suggested fix: drop fred.sh and its install/hardware/all.sh:23 call. That covers new installs, but every PTL machine installed since April still has the drop-in — nothing under migrations/ removes it, and omarchy apply hardware would rewrite it — so a migration deleting the file and rebuilding the boot image would be needed too, along the lines of what 1785944594.sh and 1786482992.sh already do for other limine-entry-tool.d drop-ins. If a disable switch is ever wanted later, fred=off is the spelling the kernel still reads.
No functional harm observed here — FRED is running as intended either way.
Related: #10037 (same directory, stale drop-in left behind).
View raw text
### System details
Dell XPS 16 DA16260, Intel Panther Lake (Core Ultra 300), Omarchy 4.0.0.alpha, linux-ptl 7.1.8.arch1-2 (stock `linux` 7.1.9.arch1-2 also installed)
### What's wrong?
On an Intel Panther Lake machine, the FRED drop-in installed by `install/hardware/intel/fred.sh` has no effect on Linux 7.1, and the kernel hands the parameter to user space instead:
```
$ cat /etc/limine-entry-tool.d/intel-panther-lake-fred.conf
# Intel Panther Lake FRED support
KERNEL_CMDLINE[default]+=" fred=on"
$ journalctl -k -b 0 | grep 'Unknown kernel command line'
kernel: Unknown kernel command line parameters "splash cryptdevice=PARTUUID=…:root fred=on", will be passed to user space.
```
FRED is enabled regardless: `CONFIG_X86_FRED=y`, the CPU advertises the `fred` flag, and `asm_fred_entrypoint_user` shows up in stack traces.
It was correct when it landed (91af40f, "Enable fred=on on intel ptl machines", 2026-04-30). On 7.0 the option was required — `arch/x86/kernel/cpu/common.c:1761` at v7.0:
```c
arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
if (arglen != 2 || strncmp(arg, "on", 2))
setup_clear_cpu_cap(X86_FEATURE_FRED);
```
`ac66a73be03a` ("x86/fred: Enable FRED by default", merged for 7.1-rc1) inverted that. Same file, `common.c:1764` at v7.1:
```c
arglen = cmdline_find_option(boot_command_line, "fred", arg, sizeof(arg));
if (arglen == 3 && !strncmp(arg, "off", 3))
setup_clear_cpu_cap(X86_FEATURE_FRED);
```
Only `off` is read; `on` matches nothing. `kernel-parameters.txt` at v7.1 now reads "on: enable FRED when it's present, the default setting."
The log line above is the second half: `fred=` has no `__setup()` stub, so it misses the registered-parameter sweep. `clearcpuid=`/`setcpuid=` carry dummy stubs at `common.c:2231`/`2237` for exactly this, per the comment above them — "to prevent them from becoming an environment variable for init".
Suggested fix: drop `fred.sh` and its `install/hardware/all.sh:23` call. That covers new installs, but every PTL machine installed since April still has the drop-in — nothing under `migrations/` removes it, and `omarchy apply hardware` would rewrite it — so a migration deleting the file and rebuilding the boot image would be needed too, along the lines of what `1785944594.sh` and `1786482992.sh` already do for other `limine-entry-tool.d` drop-ins. If a disable switch is ever wanted later, `fred=off` is the spelling the kernel still reads.
No functional harm observed here — FRED is running as intended either way.
Related: #10037 (same directory, stale drop-in left behind).
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 10:47 UTC