Update not working after fresh install

[rip747]

I was getting the following error when trying to update Omarchy from a fresh install:

Update system packages
:: Synchronizing package databases...
error: failed to synchronize all databases (unable to lock database)

Something went wrong during the update!

Please review the output above carefully, correct the error, and retry the update.

If you need assistance, get help from the community at https://omarchy.org/discord

DeepSeek V4 Pro found the issue and fixed it:

Here's what happened and what I did:

1. Diagnosed the cause — unable to lock database means pacman thinks another package operation is already running. It checks for a lock file at /var/lib/pacman/db.lck.
2. Confirmed it was stale — I checked for any running pacman process (pgrep pacman) and found none, and fuser confirmed no process actually held the lock. The lock file was dated Sep 8 — leftover from an update that got interrupted (e.g. a crash, reboot, or killed terminal) and never cleaned up.
3. Removed the stale lock — I deleted the orphaned file with:
   pkexec rm -f /var/lib/pacman/db.lck
   (Used pkexec because removing it requires root, and my shell had no terminal to prompt for a sudo password.)
   Since the lock file was just orphaned garbage and nothing was actually running, deleting it was safe and let pacman proceed normally.
   If it ever happens again, the quick fix is simply:
   sudo rm -f /var/lib/pacman/db.lck
   — but only after confirming no update/pacman process is actually running (otherwise you could corrupt the database).

[btsouth]

Reviewed against v0.0.18-preview: the guest build now rejects a locked package database, and recorded upgrade tests confirm that a busy lock blocks package updates and is not removed by repository publication. A complete older-guest package upgrade also passed.

That does not yet reproduce the stale lock you reported or prove interrupted package-transaction recovery, so this issue remains open as a v1 gate in #77.

Next investigation: boot the released factory image, check the database lock before the first update, run the normal updater, and exercise interruption/relaunch on a disposable copy with package logs and preserved-file checks. Distinguish an active package transaction from a stale lock before any recovery action. Existing evidence.

[btsouth]

Investigation and reproducible test: #117. On checksum-verified v0.0.18-preview, the factory image and first boot have no pacman lock. The normal updater's system-package phase installed five updates and left no lock. This was headless KVM testing; the desktop-shell restart reported that the shell was not ready, so it is not graphical acceptance.

A real fixture pacman transaction paused in a pre-transaction hook, then killed with SIGKILL, left a stale lock across reboot. Another transaction was correctly blocked. After confirming the known test transaction was gone and no process held the lock, controlled recovery completed installation and another reboot retained the package and user-file hash.

Keeping this open: the original image/version and interruption are not established, and killing before package writes does not cover power loss during extraction or scriptlets. No automatic lock deletion has been added.

Separately, pacman -Dk found two duplicate Neovim helper ownership entries already present before testing; #116 tracks that defect. Those diagnostics remained unchanged through recovery.