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-2027GitHub issuePublicDecided· Out of scope

Hibernate Crash & systemd-coredump CPU Spike

Reported by virtualabishek · filed Jan 14, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 4 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

Hibernate Crash & systemd-coredump CPU Spikerevision 1 · captured 2026-09-28 21:29 UTC via poll

System details

Aspire A315-58 (V1.35), 11th Gen Intel(R) Core(TM) i5-1135G7 (8) @ 4.2z, Omarchy 3.3.3

What's wrong?

Hibernate Crash & systemd-coredump CPU Spike

After a recent Omarchy system update, hibernation was enabled from system settings.
Following this change, the system began exhibiting severe performance issues after resume, including:

  • Extremely high CPU usage
  • Excessive RAM usage
  • Loud fan noise
  • System slowdown or near-freeze

The root cause was an incomplete and invalid hibernation configuration combined with active systemd core dumps.

Symptoms

  • systemd-coredump consuming ~90–100% CPU
  • Core dump size reaching multiple gigabytes
  • Disk I/O spikes (Btrfs activity)
  • Swap activity (kswapd0)
  • Electron applications (VS Code) crashing after resume
  • System fans running at maximum speed

Example log:


systemd-coredump: Process (code) dumped core
Memory peak: ~2.5GB
CPU time: ~1 minute

System Configuration

  • Kernel: Latest
  • Filesystem: Btrfs
  • Display Server: Wayland (Hyprland)
  • GPU: NVIDIA
  • Swap:
  • Disk swapfile: ~7.5GB
  • zram: ~3.5GB (higher priority) All of this are created automatically by omarchy itself

Root Cause

1. Hibernate Enabled Without Proper Kernel Resume Configuration

The kernel command line lacked the required resume= parameter:


cat /proc/cmdline
→ no resume=UUID

2. zram Interfering With Hibernate

zram was enabled with higher swap priority than disk swap:


zram PRIO = 100
disk swap PRIO = 0

Hibernate cannot resume from zram.
This caused memory pages to be stored in an invalid location during hibernation.

3. systemd-coredump Amplified the Failure

After resume, Electron applications (VS Code) crashed due to corrupted memory state.

systemd-coredump then:
- Captured large memory dumps
- Compressed them
- Wrote them to disk
- Consumed massive CPU and RAM

Default configuration had core dumps fully enabled:

[Coredump]
#Storage=external
#ProcessSizeMax=32G

(All values commented → defaults active)

View raw text
### System details

 Aspire A315-58 (V1.35), 11th Gen Intel(R) Core(TM) i5-1135G7 (8) @ 4.2z, Omarchy 3.3.3

### What's wrong?


# Hibernate Crash & systemd-coredump CPU Spike 

After a recent Omarchy system update, hibernation was enabled from system settings.  
Following this change, the system began exhibiting severe performance issues after resume, including:

- Extremely high CPU usage
- Excessive RAM usage
- Loud fan noise
- System slowdown or near-freeze

The root cause was **an incomplete and invalid hibernation configuration combined with active systemd core dumps**.

---

## Symptoms

- `systemd-coredump` consuming ~90–100% CPU
- Core dump size reaching multiple gigabytes
- Disk I/O spikes (Btrfs activity)
- Swap activity (`kswapd0`)
- Electron applications (VS Code) crashing after resume
- System fans running at maximum speed

Example log:
```

systemd-coredump: Process (code) dumped core
Memory peak: ~2.5GB
CPU time: ~1 minute

```

---

## System Configuration
- **Kernel**: Latest
- **Filesystem**: Btrfs
- **Display Server**: Wayland (Hyprland)
- **GPU**: NVIDIA
- **Swap**:
  - Disk swapfile: ~7.5GB
  - zram: ~3.5GB (higher priority) All of this are created automatically by omarchy itself

---

## Root Cause

### 1. Hibernate Enabled Without Proper Kernel Resume Configuration

The kernel command line lacked the required `resume=` parameter:

```

cat /proc/cmdline
→ no resume=UUID

```
---

### 2. zram Interfering With Hibernate

zram was enabled with **higher swap priority** than disk swap:

```

zram PRIO = 100
disk swap PRIO = 0

````

Hibernate cannot resume from zram.  
This caused memory pages to be stored in an invalid location during hibernation.

---

### 3. systemd-coredump Amplified the Failure

After resume, Electron applications (VS Code) crashed due to corrupted memory state.

`systemd-coredump` then:
- Captured large memory dumps
- Compressed them
- Wrote them to disk
- Consumed massive CPU and RAM

Default configuration had core dumps fully enabled:

```ini
[Coredump]
#Storage=external
#ProcessSizeMax=32G
````

(All values commented → defaults active)

---

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 02:34 UTC