Fixing Haiku Applications That Stop Launching After a System Update
A safe workflow for post-update Haiku app failures using Terminal evidence, package ownership, prior states, settings isolation, and reports.
When an application stops launching immediately after a Haiku update, preserve the relationship instead of replacing libraries at random. The failure may be an incompatible package, stale user add-on, damaged setting, wrong architecture, or an application bug exposed by a system change. Packagefs makes /boot/system package-owned and read-only, so manual library copying is both ineffective and likely to hide the real dependency transition.
Capture the first useful error
Start the application from Terminal using its real executable. Record all loader, missing-symbol, add-on, and runtime messages. If it crashes, save the debug report or core file offered by Haiku and note the first application-specific frames. Do not repeatedly dismiss the crash dialog before preserving evidence.
Record the Haiku revision and architecture, application package/version, enabled repositories, and the update time. Distinguish “nothing appears,” “loader reports a missing library,” “window appears then exits,” and “Debugger opens.” Those symptoms start in different layers.
Check whether only this application fails. If several unrelated programs fail to load the same library, the package state or shared dependency deserves priority. If one application fails while the rest of the desktop works, begin with its package, add-ons, and settings.
Compare the previous package state
Haiku retains old package states under the system package administrative directory. Enter Boot Loader Options—Shift on legacy BIOS, Space on UEFI—and choose the last state from before the update. Do not change additional safe-mode options for this comparison.
If the application works in the prior state with the same user settings and data, the result strongly links the failure to the package transition. Record both working and failing revisions. This rollback is a diagnostic and temporary recovery, not the final fix.
If it fails identically in the old state, investigate application data, settings, or an independently updated user package. A system update occurring nearby is correlation, not proof.
Inspect packages and repositories
Use HaikuDepot or pkgman to identify the installed application and available compatible update. Confirm that repositories match the intended stable or nightly track and current architecture. Do not mix arbitrary repository generations to satisfy one missing library.
The official update guide documents pkgman full-sync for synchronizing the installed set with configured repositories. Read the proposed changes before approving them and preserve a backup. A consistent reinstall from the repository is safer than placing a downloaded .so beside the executable.
If the package is third-party and no compatible rebuild exists, keep the previous boot state for necessary work or remove the affected application until its maintainer updates it. Report the exact package pair or symbol that changed.
Isolate settings and user add-ons safely
Copy the application’s settings directory before testing. Rename or move only that application’s settings so it starts with defaults; do not delete the entire user configuration hierarchy. If clean settings work, restore pieces selectively to locate the incompatible file.
User-installed translators, input methods, media add-ons, or plug-ins can load into applications after a system update. Boot once with user add-ons disabled or temporarily isolate the application’s plug-in directory. If that changes the result, re-enable add-ons one at a time.
Keep system package contents untouched. For a packaged component known to break startup, Haiku provides boot-loader/component-blocking mechanisms and package transactions; editing the virtual packagefs view is not a durable fix.
Produce an actionable report
Reproduce once on the current supported package set if safe. Attach the saved crash report or core, Terminal output, exact revision/architecture, package versions, working previous state, and minimal steps. Explain whether clean settings, disabled user add-ons, or another user account changes the failure.
For a loader error, include the exact missing library or symbol. For a crash, include symbols where available and the complete report, not one screenshot of the top frame. For an application package, check its HaikuPorts issue tracker or maintainer channel; for a Haiku system regression, use Haiku’s bug tracker.
The safe recovery pattern is evidence, one controlled rollback, one clean package synchronization, and narrow settings/add-on isolation. Once the fixed package is available, boot the current state, update normally, and verify the application twice before deleting older recovery states.
Related:
- Fixing and Diagnosing App Crashes Using Haiku’s Debug Server
- Fixing Haiku Boot Failures with Safe Mode
Sources: