Omarchy 4.5 boots faster now that startup no longer stalls on binfmt
Two systemd tweaks from DHH took userspace startup in a test VM from about 2.4 seconds to 0.74 seconds, with hardware numbers still to come.
Image: omacom/omarchy PR #15175 (GitHub)
Omarchy 4.5 shaves real time off every boot. The release notes put it in one line: “Startup no longer stalls on binfmt registration.” Behind that line are two small systemd changes from DHH that, in his VM tests, cut userspace startup by more than two thirds.
The first is “Mount binfmt before registration to shorten boot by about a second”, opened on October 12, 2026 and merged into the quattro branch on October 13. According to the PR, systemd-binfmt.service, which registers the binary formats that let you run foreign-architecture programs (QEMU handlers, for instance), orders itself after the binfmt mount but never pulls that mount into the boot transaction. So registration sat waiting on an automount for almost a second. The fix is a pair of drop-ins that pull the mount in explicitly, while keeping the automount’s path and read/write conditions so restricted container environments still behave.
The PR measured five alternating boots with the verified 2026.10.12.442 edge image in a VM. Median userspace startup went from 2.408 s to 1.503 s, and the binary-format registration service dropped from 992 ms to 13 ms. Every boot reached running with no failed units and all 31 QEMU handlers registered, and an ARM64 Alpine Docker container still ran and reported aarch64.
The second change, “Avoid mount-event throttling during boot”, stacks on the first and was merged the same day. By default, systemd’s mount monitor accepts five notifications per second and defers new mount jobs when a boot burst goes over that. DHH’s debug journals showed local-filesystem mounts waiting out that one-second window even after the binfmt fix, so the PR raises the allowance to 30 events per second while keeping the one-second interval.
Over ten boots per configuration, the median userspace startup went from 2.413 s unchanged, to 1.501 s with the binfmt fix alone, to 0.737 s with both. The PR says a limit of ten still kept the pause, twenty still paused in one of ten boots, and thirty gives more headroom without the runtime cost of the fifty-event setting that was also tested.
There is a tradeoff, and the PR spells it out. Under a synthetic stress of 1,000 mount/unmount operations, PID1 CPU usage went from 3.5% to 5.5% of one core with 31 existing mounts, and from roughly 5.3% to 15.5% with 1,031 mounts. systemctl stayed responsive and every stress run finished healthy. The tuning variable also has a weaker stability guarantee than regular system.conf options, so the PR flags it for a recheck on systemd upgrades.
One important caveat: these are VM numbers. The second PR says plainly that they are “VM userspace measurements, not hardware or initrd claims,” and ends with “Hardware measurements remain follow-up validation before adoption.” So don’t expect your laptop to hit exactly 0.74 s, though DHH noted the same near-one-second binfmt delay in his own development machine’s boot journal.
The settings ship through Omarchy’s existing etc/ copy path for new and updated installations, so once you’re on 4.5 they kick in on your next boot.
