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.
Netbooting omarchy, power save disables net, locks up system
Reported by jeremytregunna · filed Jul 18, 2025Closed upstream on 2025-11-03 by dhh, as not planned.
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
Hi, this is an issue that I've been facing, since I boot my omarchy machine off of the network. So I've decided to open an issue to describe the problem, and offer a workaround. This isn't a PR, because few probably set it up this way, but the issue will be helpful if anyone netbooting has similar issues in the future and needs a mitigation strategy, so here I am.
What happens
After a period of inactivity, about 5-10 minutes or so, screen will go blank, and a little while after that, power save mode kicks in for memory and disk (you can check this by running cat /sys/power/state). This makes sense for a laptop, but not a desktop that's being netbooted.
My system specific things
- I boot using iSCSI
- I have a network interface using the
igcmodule - My network interface is
eth0
Those are the pertinent details.
How to stop the network dropping during periods of inactivity
I created a udev rule: /etc/udev/rules.d/99-disable-network-power-management.rules containing:
SUBSYSTEM="net", ACTION="add", DRIVERS=="igc", RUN+="/bin/sh -c 'echo on > /sys/class/net/%k/device/power/control'"And then ran: udevadm control --reload-rules.
Additionally, I ran echo on | sudo tee /sys/class/net/eth0/device/power/control.
After that, I waited about 15 minutes, and my computer was still usable, not locked up needing a hard reboot.
View raw text
Hi, this is an issue that I've been facing, since I boot my omarchy machine off of the network. So I've decided to open an issue to describe the problem, and offer a workaround. This isn't a PR, because few probably set it up this way, but the issue will be helpful if anyone netbooting has similar issues in the future and needs a mitigation strategy, so here I am. ## What happens After a period of inactivity, about 5-10 minutes or so, screen will go blank, and a little while after that, power save mode kicks in for memory and disk (you can check this by running `cat /sys/power/state`). This makes sense for a laptop, but not a desktop that's being netbooted. ## My system specific things - I boot using iSCSI - I have a network interface using the `igc` module - My network interface is `eth0` Those are the pertinent details. ## How to stop the network dropping during periods of inactivity I created a udev rule: `/etc/udev/rules.d/99-disable-network-power-management.rules` containing: ``` SUBSYSTEM="net", ACTION="add", DRIVERS=="igc", RUN+="/bin/sh -c 'echo on > /sys/class/net/%k/device/power/control'" ``` And then ran: `udevadm control --reload-rules`. Additionally, I ran `echo on | sudo tee /sys/class/net/eth0/device/power/control`. After that, I waited about 15 minutes, and my computer was still usable, not locked up needing a hard reboot.
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.