Omarchy 4.0.0 install fails because gst-plugin-gtk is missing from offline mirror

[jack-builds]

System details

MacBook Pro Retina, 2013 Intel x86_64, Omarchy 4.0.0 ISO image version: 2026.08.14, Installation method: Omarchy ISO flashed with Balena Etcher

What's wrong?

Hi! I'm trying to install Omarchy on a 2013 Retina MacBook Pro (Intel).
I downloaded the Omarchy 4.0.0 ISO from the official website about 20 minutes before trying the installation and flashed it to a USB using Balena Etcher.
The installation consistently fails during the "Installing Arch + Omarchy" / pacstrap stage with:
gst-plugin-gtk-1.28.6-1-x86_64.pkg.tar.zst
The installer reports that it cannot retrieve this package and then fails with:
ERROR: Failed to install packages to new root
I checked my internet connection from the installer shell:
ping -c 4 1.1.1.1 works
ping -c 4 archlinux.org works
curl -I https://mirror.omarchy.org/ returns HTTP 301 (redirects to omarchy.org)
I also checked /etc/pacman.conf and found that the installer is using:
Server = file:///var/cache/omarchy/mirror/offline/
I checked that directory and there is no gst-plugin-gtk package in the offline mirror.
The ISO reports:
BUILD_ID="4.0.0"
IMAGE_VERSION=2026.08.14
Is the offline package mirror in the current ISO missing gst-plugin-gtk-1.28.6-1?
Thanks!

[omarchybot]

Thanks for including the Server = file:///var/cache/omarchy/mirror/offline/ line and for checking that directory — that is what made this diagnosable.

The 4.0.0 ISO's offline mirror is not missing gst-plugin-gtk. Its package database lists gst-plugin-gtk-1.28.6-1-x86_64.pkg.tar.zst (39091 bytes, sha256 b69d038f6ca0dee39878810047df9633e7536707e01c94ffedcc07c7c3dbc0cd), and resolving the installer's entire target list against that database alone comes out complete — 938 packages, nothing missing. gst-plugin-gtk arrives as a dependency of sushi, and the mirror is built by resolving the full dependency closure, so it is included. An install from the same ISO build is on record installing that exact package successfully.

What appears to have happened instead is that the installer deleted it. During installation the offline mirror directory is bind-mounted as pacman's package cache, so the repository pacman fetches from and the cache it validates are the same directory. If a package file fails its checksum — a truncated download of the ISO, a bad write to the stick, or one bad read off it — pacman's answer to "File … is corrupted. Do you want to delete it?" under --noconfirm is yes, and the file is unlinked from the mirror. Every attempt after that reports failed retrieving file 'gst-plugin-gtk-1.28.6-1-x86_64.pkg.tar.zst' from disk, and the package really is gone from /var/cache/omarchy/mirror/offline/ — which is what you found when you looked.

I reproduced that sequence on a clean VM with pacman 7.1.0: an intact copy installs and stays put; a copy with one altered block is deleted out of the mirror and the run fails with a checksum error; the next run then fails with your error, word for word. I did not attempt your install, so the first bad read on your media is inferred rather than observed.

One detail that would help: on that reading, your first attempt should have failed with invalid or corrupted package (checksum) rather than with the retrieval error, and only later attempts with the retrieval error. If you still have the machine, /var/log/omarchy-install.log from the live session holds the full text, and the first failure in it is the one that matters.

Two checks you can run yourself:

• The deletion lands in the live session's overlay, not on the USB stick, so booting the stick again should show gst-plugin-gtk-1.28.6-1-x86_64.pkg.tar.zst back in /var/cache/omarchy/mirror/offline/. If it is there on a fresh boot, it was deleted by the failed install rather than absent from the ISO.
• On that fresh boot, before starting the installer, sha256sum /var/cache/omarchy/mirror/offline/gst-plugin-gtk-1.28.6-1-x86_64.pkg.tar.zst should print b69d038f6ca0dee39878810047df9633e7536707e01c94ffedcc07c7c3dbc0cd. If it does not match, the corruption is in your copy of the ISO or in the write to the stick — verify the downloaded .iso against its published checksum and re-flash before trying again.

A second reviewer went over this independently and agreed on the mechanism, and corrected the order of the errors it produces — that correction is the paragraph above about your first attempt. It also noted a plausible alternative that needs no deletion at all: a hard I/O error reading the stick could fail the open directly.

Next: the part that is Omarchy's rather than yours is that a single bad byte deletes a package out of the ISO's own mirror and makes the failure unrecoverable without a reboot, instead of costing one retry. That is written up for the maintainer, and it sits in the code two open ISO pull requests are currently rewriting.

[gable00]

Is this only happening to a limited amount of users or is it a primary ISO issue? Asking because I'm experiencing this and awaiting an ISO update in order to move forward.

[omarchybot]

@gable00 — the direct answer is that the shipped 4.0.0 ISO is not missing this package, so an ISO update is not what you are waiting for.

I checked the published artifact itself rather than reasoning about it. omarchy-4.0.0.iso as served today (6,273,040,384 bytes, published 2026-08-14 — the only 4.0.0 ISO there is, and the one @jack-builds' IMAGE_VERSION=2026.08.14 names): its detached signature verifies against the Omarchy signing key 40DFB630FF42BCFFB047046CF0134EE680CAC571, its airootfs.sfs matches the airootfs.sha512 manifest shipped beside it, and inside it the offline mirror holds 1247 packages whose SHA256 sums I checked one by one against the mirror's own database. 1247 checked, none missing, none mismatched. gst-plugin-gtk-1.28.6-1-x86_64.pkg.tar.zst is there, 39091 bytes, b69d038f6ca0dee39878810047df9633e7536707e01c94ffedcc07c7c3dbc0cd.

So a respin would ship the same bytes that are already there. What goes wrong happens between that published file and pacman reading it — the download, the write to the stick, or the read back off it — which means the checks worth your time are on your own copy. Being straight about the limit of that: this proves the build is sound, not how many people are hitting the failure. If enough verified sticks fail the same way, that points somewhere else again, which is why the two checks below are worth doing even if you expect them to pass.

Is your download intact? No .sha256 is published beside the ISO yet, so here is the one I measured on a copy whose signature verifies:

9224fab3720560f771969a99a499e5f7e0f8e2d6a0681d872d52f05fb5003da4  omarchy-4.0.0.iso

The .sig sits beside the ISO at the same URL if you would rather verify it yourself; the manual's security page covers that.

Is the stick intact? A download checksum cannot tell you that, and neither can your flashing tool: it validates what it wrote against the file you handed it, so it cannot know that file was right. The ISO carries a manifest for exactly this check. Boot it, and before starting the install, from a shell in the live session:

cd /run/archiso/bootmnt/arch/x86_64 && sha512sum -c airootfs.sha512

That reads the whole 5.9 GB root image off the stick and checks it against what the build recorded. Give it a few minutes. It is not a guarantee — the image is too big to be copied into RAM, so the install rereads it from the stick afterwards and a flaky stick can pass this and still misread later — but a failure here settles it immediately. OK means the medium is sound and your failure is something else; say so here, because that would be a different bug from this one.

On the package that "went missing". It ships; the installer deletes it. During the install pacman's package cache and the [offline] repository are the same directory, so when a package fails its checksum, pacman's "File … is corrupted. Do you want to delete it?" is answered yes by --noconfirm and the file is unlinked out of the mirror. I ran that today on a clean VM with pacman 7.1.0, using the real gst-plugin-gtk file taken out of the 4.0.0 ISO: intact, it installs and stays; with 64 bytes altered, pacman reports invalid or corrupted package (checksum) and deletes it; the next attempt reports failed retrieving file 'gst-plugin-gtk-1.28.6-1-x86_64.pkg.tar.zst' from disk : Could not open file …, which is the error this issue was filed about. The first failure in a boot names the cause; every one after it names the symptom, which is what makes this thread hard to read.

The stick is not damaged by that, and retrying is not what makes it worse — retrying without rebooting is. The deletion lands in RAM: the live system is an overlay whose lower layer is the read-only image on the stick and whose upper layer is a tmpfs, and no Omarchy boot entry asks for a persistent one. So the missing file stays missing for the rest of that boot and every retry in it fails on the file rather than on the bytes; a reboot brings it back. Reboot between attempts, and quote the first error after a fresh boot. A reboot does not repair a bad download or a bad flash, so a genuinely damaged copy will fail again at the same place.

Nothing about gst-plugin-gtk is special — 979 of the 1247 packages are under 1 MB and this one is the 1041st largest, so a small one being named is unremarkable. Which package gets named is a useful signal, though: after a fresh reboot, the same package again means a stable fault, a bad download or a bad write, and re-downloading and re-flashing is the fix. A different package each time means the bytes on the stick are fine and the reads are not — a port, a cable, a controller, or memory. If yours names a package other than gst-plugin-gtk, that is the same failure rather than a different one, and worth saying which.

What is Omarchy's here, and with the maintainer rather than with either of you, is that one bad byte anywhere in 4.4 GB of mirror deletes a package out of the ISO's own mirror and ends the install pointing at the wrong culprit, instead of costing one retry. That code is being rewritten by two open ISO pull requests.

Diagnosed by Claude Opus 5 in Claude Code and reviewed independently by Codex at xhigh reasoning. It confirmed the deletion mechanism and the overlay reasoning against the ISO's own initramfs, and corrected two things that are in this reply because of it: that an intact build says nothing about how many people are hitting the failure, and that the package named after a reboot distinguishes a stable fault from a flaky read.

[thomasxd24]

@omarchybot I have exactly the same problem where Gst-plugin also fails, so it can't be the problem.of corrupted build? Is there anything we can do to fix the error without rebooting?

[omarchybot]

@thomasxd24 — the direct answers, both new since the last reply here.

No, it is not a corrupted build, and that now holds for 4.0.1 as well. I fetched omarchy-4.0.1.iso today and checked the artifact itself on a clean VM: 6,227,752,960 bytes, sha256 69cbb4e10d98ad831c3c9f245b5757a9d1fedfd0c9592780e977d6f950dea8c3, which matches the checksum published in the v4.0.1 release notes; its airootfs.sfs verifies against the airootfs.sha512 shipped beside it; and inside it the offline mirror holds 1249 packages including gst-plugin-gtk-1.28.6-2-x86_64.pkg.tar.zst, 39174 bytes, sha256 4c675dba5c29fc5ddd7c4a771fbbba94d01ab52620efb103f119c5ae1f4b1a0e, matching the entry in the mirror's own database. The 4.0.0 ISO was checked the same way a few days ago with the same result. Neither image is missing the package, and a second report does not change that — what it changes is how much weight the build explanation deserves, which is why I checked the newer image rather than reasoning from the version number.

Note which release you are on: 4.0.0 carries gst-plugin-gtk-1.28.6-1, 4.0.1 carries -2. If your error names -1 you are installing from the 4.0.0 image.

Yes, you can fix it without rebooting. The deletion lands in the live session's RAM overlay; the read-only image on your stick is untouched, and archiso keeps that image mounted for the whole session at /run/archiso/airootfs. So the package can be put straight back where the installer looks for it. From a shell in the live session:

sudo cp /run/archiso/airootfs/var/cache/omarchy/mirror/offline/gst-plugin-gtk-*.pkg.tar.zst \
        /var/cache/omarchy/mirror/offline/

Then start the installer again. I checked both halves of that rather than assuming them: the mount path comes from the mkinitcpio-archiso hook inside the 4.0.1 image itself, which mounts the read-only root at /run/archiso/airootfs before overlaying it; and I built the same overlay arrangement on a VM and ran the sequence — removed through the overlay the file is gone from the writable view and still present on the read-only image, and copying it back restores it byte for byte with pacman reading it as a valid package.

That cp is also a test, because it re-reads the same bytes off the same stick:

• It succeeds and the install gets past this package — the first read was a one-off misread, and you are done.
• It succeeds and the install rejects the same package again with invalid or corrupted package (checksum) — the bytes on the stick are genuinely wrong. Re-download, check it against the sha256 above, and write the stick again.
• It fails with an input/output error — the medium itself is failing. Another port, another stick.

Two things that would sharpen this. You wrote "Gst-plugin" — the exact filename matters, because gst-plugin-pipewire is also in the package set, and the same package every time means a stable fault while a different one each time means flaky reads rather than bad bytes. And the first error in /var/log/omarchy-install.log after a fresh boot is the one that names the cause: failed retrieving file … Could not open file is only ever the wake of an earlier attempt in the same boot.

What changed on our side. Until now a retry produced no diagnosis at all — the failure screen only recognised the first attempt's is corrupted line, so every attempt after it showed the bare pacstrap error with nothing pointing at the medium. That is fixed in omacom/omarchy-iso#131, which recognises the retry, names the package, and says to reboot first. It does not stop the deletion; that is the cache arrangement two open ISO pull requests are rewriting.

Where this belongs. The offline mirror is built by omacom-io/omarchy-iso, and so is the installer code that mounts it as pacman's writable cache — this repository only supplies the package lists. So the defect and its fix live in that repository, and a maintainer will decide whether to move the issue.

Diagnosed by Claude Opus 5 in Claude Code and reviewed by Codex at xhigh reasoning. Codex looked for any mechanism that would single out this package in the build — the mirror download, the prune, the repo index, the signature policy, the second read-write bind of the mirror into the target — and found none, which leaves a damaged or misread medium as the explanation the sources support. It also established that the offline repository runs with SigLevel = Never, so nothing about signatures can be involved, and that the second bind is never reached when pacstrap is what failed. Its independence is not currently guaranteed.

[osouthgate]

Confirming a second reproduction of exactly the mechanism @omarchybot described — different package, different hardware — plus a downstream consequence I haven't seen mentioned in the offline-mirror threads.

Environment: Omarchy 4.0.2 ISO (label OMARCHY_202608), full-disk LUKS + btrfs, UEFI. ASUS TUF Z790-PLUS WIFI, i9-14900K, RTX 4080 SUPER, 96 GB DDR5. Install target a Samsung 990 PRO 1TB (Windows on a separate disk, untouched).

Same cascade, package nvidia-utils: the install ran through partitioning/base/most of "Configuring system", then hard-exited at hardware/nvidia.sh with status 1:

:: File /var/cache/pacman/pkg/nvidia-utils-610.57.04-1-x86_64.pkg.tar.zst is corrupted
Do you want to delete it? [Y/n]  error: failed to commit transaction (invalid or corrupted package)
Failed: /usr/share/omarchy/install/hardware/nvidia.sh

Retrying then gave Could not open file …/offline/nvidia-utils-… and, shortly after, failed retrieving 'offline.db' from disk — i.e. the package (and then the db read) were gone from the bind-mounted offline mirror, exactly as your gst-plugin-gtk write-up predicts. So this isn't specific to gst-plugin-gtk; any single bad read off the install media deletes that package out of /var/cache/omarchy/mirror/offline/ and aborts the run.

The part I'd add to the discussion — the abort can leave the machine un-loginable, not just missing a driver. Because nvidia.sh sits in "Configuring system", the failure lands after base + Limine + the user account, but before the tail of that phase. In my case the greeter/autologin config was never written. First boot reached SDDM, which rejected the correct password — the same password worked at a TTY, and journalctl -u sddm showed the greeter submitting an empty username (pam_unix(sddm:auth): check pass; user unknown / Authentication for user "" failed). So one corrupt package in the offline bundle doesn't just skip an optional step — it can leave a bootable-but-unusable graphical target. Fixed by hand with an /etc/sddm.conf.d/*.conf autologin drop-in after finishing the driver install.

Workaround that got it installed (from the failure menu → drop to shell, target still mounted at /mnt): repoint pacman at the real Arch mirrors and finish the step in the chroot —

echo 'Server = https://geo.mirror.pkgbuild.com/$repo/os/$arch' > /mnt/etc/pacman.d/mirrorlist
sed -i '/\[offline\]/,$d' /mnt/etc/pacman.conf
printf '\n[core]\nInclude = /etc/pacman.d/mirrorlist\n[extra]\nInclude = /etc/pacman.d/mirrorlist\n[multilib]\nInclude = /etc/pacman.d/mirrorlist\n' >> /mnt/etc/pacman.conf
arch-chroot /mnt pacman-key --init && arch-chroot /mnt pacman-key --populate archlinux
arch-chroot /mnt pacman -Syy
arch-chroot /mnt bash /usr/share/omarchy/install/hardware/nvidia.sh   # `bash …` — the script isn't +x; direct exec is 126

Which is really the design ask underneath all of these threads: when an offline-mirror package is corrupt/missing and a network is up, falling back to online repos (or offering "retry online" at the failure prompt) would turn a fatal, media-dependent abort into a recoverable one. Happy to attach /var/log/omarchy-install.log if useful.

[omarchybot]

@osouthgate — thank you, and specifically thank you for the different package. That is the piece this thread had been missing.

It closes an open question. Three reporters here all named gst-plugin-gtk, and nothing found in the ISO build, the mirror prune, the repository index or the signature policy singled that package out. Yours is the counter-example: same cascade, different package, a third ISO build. The mechanism is not about gst-plugin-gtk and never was — it is any cached package pacman rejects during validation. Your nvidia-utils trace is the sequence written out in full: is corrupted … Do you want to delete it? answered yes by --noconfirm, the file unlinked out of the bind-mounted mirror, then Could not open file …/offline/nvidia-utils-… on the retry, and finally failed retrieving 'offline.db' from disk once the read itself is failing rather than just one package.

Your bash … note is right, and expected. The install scripts are deliberately not executable: run_logged sources them through bash -eE -c 'source "$1"' (install/helpers/logging.sh), so bash /usr/share/omarchy/install/hardware/nvidia.sh is the correct way to run one by hand and 126 from a direct exec is not a defect.

The un-loginable consequence checks out in source, and reaches further than the driver. run_logged returns the leaf's status rather than swallowing it, nvidia.sh is line 11 of install/hardware/all.sh, and omarchy-apply-hardware runs under set -euo pipefail, so the failure exits it. Its caller omarchy-apply-system then aborts at that invocation — which is before install/login/all.sh and before install/post-install/all.sh. Two things therefore never ran on your machine:

• install/login/sddm.sh, which strips the pam_gnome_keyring lines from /etc/pam.d/sddm.
• install/post-install/pacman.sh, which is what replaces the ISO's offline pacman.conf and mirrorlist with the online ones. That is why your workaround had to rewrite /mnt/etc/pacman.conf by hand — the target was still pointed at the offline repository, by design, until a step that never ran.

SDDM itself was already enabled, because that happens earlier in the configuration phase (install/config/enable-services.sh:14). So the machine boots to a greeter whose login phase never finished.

On the empty username, there is a mechanism in this repository. The Omarchy SDDM theme has no username field: default/sddm/omarchy/Main.qml:10 sets currentUser: userModel.lastUser, and pressing Enter submits that value directly to sddm.login(...). If lastUser is empty the theme submits an empty username and offers no way to type one, which is exactly the Authentication for user "" failed you saw, and exactly why your /etc/sddm.conf.d drop-in fixed it. What cannot be established from this repository is why lastUser was empty on your machine — /var/lib/sddm/state.conf is written by omarchy-provision-owner, which runs from a first-boot service the ISO stages rather than from the install phase that aborted, and that ordering lives in omacom-io/omarchy-iso. If you still have /var/log/omarchy-install.log, please do attach it: the first failure line in it, and whether /var/lib/sddm/state.conf exists on that machine, would settle the last step.

Where each piece belongs. The deletion itself, and your "retry online when a network is up" request, are omacom-io/omarchy-iso's — that repository builds the offline mirror and owns the installer code that bind-mounts it as pacman's writable cache. The greeter having no recovery when lastUser is empty is this repository's. Both are the maintainer's to decide on; we have not filed either from here.

Diagnosed by Claude Opus 5 in Claude Code with an independent second opinion from Codex at xhigh reasoning. Two things above are in this reply because of Codex rather than despite it: the abort ordering through run_logged and omarchy-apply-system (including that the skipped post-install/pacman.sh explains your pacman.conf workaround), and the lastUser mechanism in the SDDM theme. It also pushed back on one thing worth repeating: a fourth package disproves a package-specific defect, but "selection bias" for the earlier three remains an inference rather than something established. Its independence is not guaranteed.

[jack-builds]

Accidentally closed this. Sorry lol newb.
I am still struggling with this issue, and i just wanna get omarchy installed super bad. i need my linux computer back. So is there anything i can do just to move on and get this installed? What are other people doing that we aren't? They can install omarchy.
Thanks;

[thomasxd24]

@jack-builds I installed omarchy 4.0.2 successfully, i just change the intallation media, i was using sd card with a usb sd reader connected to a usb c dongle. I just bought a real usb drive and it worked for me.

If it helps for you, i did this command and i can confirm that it was not identical with the checksum when i used the sd card:
cd /run/archiso/bootmnt/arch/x86_64 && sha512sum -c airootfs.sha512

[jack-builds]

@thomasxd24
Thanks for that tip! I am actually using a micro sd card and a usb adapter as well! I will try flashing omarchy 4.0.2 to a real USB drive soon. Thanks!