Update to Fedora Silverblue Fails

Coming here to confirm this is happening on my Aurora Linux (UBlue) install. Looks like on line 167 of the RPM install scripts...

mkdir -p /usr/local/bin

… is the culprit. It’s in a block to expose the new 1Password MCP server. From what I’ve been able to deduce, here’s what’s happening:

1. /usr/local is actually a symlink under the hood of Fedora Atomic spins.
2. When inside rpm-ostree’s brwap sandbox, the target (/usr/local) doesn’t exist, so it becomes a dangling symlink.
3. When mkdir -p is ran, it tries to create /usr/local and gets an EEXIST error.

Let’s hope they fix this soon! It’s preventing me from upgrading my base image.

Hi ​@KBC827012435522 and ​@frinchilla, thanks for taking the time to report this!

Our development team have identified that on rpm-ostree-based systems, /usr/local is a symlink that points into /var, which isn't populated during the rpm-ostree layering transaction. Our post-install script tries to create a directory through it, fails, and aborts the update.

While I don't have a timeline to share, the team is currently working on a fix for this, and I do apologise for the inconvenience caused in the meantime.

Hello 1P_Gem

Thank you very much for the quick response letting us know that this issue is being addressed. As a customer, that’s exactly the kind of response time you hope for. 

I have patched the rpm using rpmtools as a temporary work-around (using distrobox, toolbox should work in the same way):

```sh
# Rebuild tooling in a disposable container
distrobox create --name fedora --image registry.fedoraproject.org/fedora:44
distrobox enter fedora -- sudo dnf install -y rpmrebuild rpm-build

# Grab the stock RPM
curl -LO https://downloads.1password.com/linux/rpm/stable/x86_64/1password-8.12.28.x86_64.rpm

# Strip the two offending %post lines
distrobox enter fedora -- rpmrebuild -p -n -b \
  -f "sed -e '/mkdir -p \/usr\/local\/bin/d' -e '/ln -sf \/opt\/1Password\/1password-mcp \/usr\/local\/bin\/1password-mcp/d'" \
  ./1password-8.12.28.x86_64.rpm
# -> prints patched RPM path, e.g. ~/rpmbuild/RPMS/x86_64/1password-8.12.28-1.x86_64.rpm

# Layer it on the host and reboot
rpm-ostree install ~/rpmbuild/RPMS/x86_64/1password-8.12.28-1.x86_64.rpm
systemctl reboot
```

The MCP binary still works fine at `/opt/1Password/1password-mcp`; add the `/usr/local/bin` symlink by hand post-boot if wanted (`sudo ln -sf /opt/1Password/1password-mcp /usr/local/bin/1password-mcp`).

Hello! Is there any update on this? My Bazzite updates are being blocked by the mkdir error as well.

Environment

• Fedora Silverblue 44 (rpm-ostree/ostree-based, atomic desktop variant)
• 1Password installed via the official RPM repo, layered with rpm-ostree install
• Currently stuck on 1password-8.12.26-1; every rpm-ostree update since ~July 15 fails trying to move to 8.12.28-1

Error

error: Running %post for 1password: bwrap(/bin/sh): Child process exited with code 1

journalctl -t 'rpm-ostree(1password.post)'
mkdir: cannot create directory '/usr/local': File exists

This isn't a one-off — it fails identically on every update attempt, which on rpm-ostree systems aborts the entire transaction (base OS + every other layered package), not just the 1Password install.

What I think is going on
Pulled apart after-install.sh from the current .tar.gz (which appears to share this logic with the RPM's %post). This block is new-ish and only fires when the 1password-mcp binary is present:

sh

MCP_BINARY_PATH="./1password-mcp"
if [ -f "$MCP_BINARY_PATH" ]; then
  ...
  mkdir -p /usr/local/bin
  ln -sf /opt/1Password/1password-mcp /usr/local/bin/1password-mcp
fi

mkdir -p normally never errors on an existing directory, so hitting "File exists" here suggests /usr/local is a symlink (into /var, which is standard on ostree-based Fedora to keep /usr/local writable despite the read-only /usr tree) that isn't resolving cleanly inside rpm-ostree's sandboxed (bwrap) scriptlet execution. Because the script runs under set -eu, that single failure kills the whole postinstall, which rpm-ostree treats as a hard transaction failure.

This lines up with timing: the 1password repo metadata bumped July 14, and my first failure was July 15 — right when this MCP-related code path started actually executing (presumably because 1password-mcp started shipping in the package around then).

Ask
Could this mkdir -p /usr/local/bin step be made resilient on ostree/immutable systems — e.g. skip silently if the path can't be created, or place the convenience symlink somewhere under /opt/1Password instead of assuming /usr/local is always safely writable? As-is, this blocks all system updates (not just 1Password's) for anyone running Silverblue, Kinoite, Bazzite, or similar rpm-ostree-based distros with 1Password layered.

Hi ​@david.radice, thanks for taking the time to share your workaround!

Hi ​@donburr, I’m sorry to hear you’re encountering this as well, and I’ve added your report to the internal tracker for the issue. Our developers are actively working on it, but I don’t have any updates I’m able to share just yet.

Hi ​@oract, thank you for such a thorough writeup! I've merged your post into an existing thread covering the same topic to keep all the information together and avoid any duplication of efforts.

I can confirm that this is a known issue at the moment, and our development team is working on a fix. I do apologise for the inconvenience caused in the meantime. I’ve added your report to the internal tracker for the issue.

Just adding that I am affected as well on Fedora Kinoite with the same error:

error: Running %post for 1password: bwrap(/bin/sh): Child process exited with code 1; run `journalctl -t 'rpm-ostree(1password.post)'` for more information

Jul 20 19:20:36 whitebox rpm-ostree(1password.post)[77837]: mkdir: cannot create directory ‘/usr/local’: File exists