Fixes for 5.0, through APT.

Release facts

Version

5.0.1 «Umbra», a point release of 5.0.0

Kind

Update through the signed APT repository; no ISO of its own

APT suite

umbra (unchanged: 4.1 and 5.0 systems already track it)

Packages

Every Shadowfetch package 5.0.1-1; grub-btrfs keeps its own 4.14-2

ShadowCode

1.0.1 (5.0.0 shipped 1.0.0)

Install media

shadowfetch-5.0.0-amd64.iso (5.0.0), then update

Install media SHA-256

2d8a72e044e8061bd616b2b4668425cc4d4ec0480a98975f961c0e58cba95e21

Published

2026-10-01

Signing key

8F13 CE15 35EE 1F4A 2916 A1F7 3C5C 900B 7BE8 0CA1

Source

branch release/5.0.1, commit a932f1b582a24ba9fc27c037773351fe0f285602

How to update

From 5.0.0 or 4.1: use apt for this one update

The supported path is the signed Shadowfetch APT repository. Use these two commands, not fireproof update or Control Center's Software page, to install 5.0.1:

sudo apt update
sudo apt full-upgrade

If apt lists packages as “kept back”, that is expected while Debian testing is in the middle of a transition: apt holds them and removes nothing. Then log out and back in once (or restart).

From 5.0.1 on, fireproof update is the update command again, including for Fireproof's own updates, and it never removes packages: while Debian testing is in a transition, it holds back the upgrades that would remove packages, lists them, and installs the rest.

Why apt this once. 5.0.1 fixes fireproof update updating Fireproof (below), but on a 5.0.0 or 4.1 system this one update would still be run by the Fireproof daemon that is already running, and the old daemon still controls the update itself:

• It runs dpkg inside its own service, under the old service settings, until systemd reloads them partway through the update. A stop that reaches it before then, such as a shutdown or a service restart, still kills dpkg with it.
• It does not notice a system that an earlier attempt left half configured, and offers a normal update on top.
• It plans the update with the resolver that removes packages during a Debian testing transition. In QA, 4.1's fireproof update removed shadowfetch-desktop, shadowfetch-creative-base, Krita and Kdenlive on the way to 5.0.0.

With apt, dpkg runs in your terminal, not inside fireproofd, so none of this applies. 5.0.1's install script then restarts the idle daemon on the new version.

If an earlier update was interrupted

Repair it first. Signs of this are sudo dpkg --audit printing anything, or apt asking you to run dpkg --configure -a. An earlier fireproof update that included shadowfetch-fireproof, such as 4.1 to 5.0.0, went through the same stop and was most likely interrupted:

sudo dpkg --configure -a
sudo apt full-upgrade
sudo apt install shadowfetch-desktop shadowfetch-creative-base

The last command puts back the desktop metapackages (and with them Krita and Kdenlive) if the interrupted update removed them; if they are still installed, it does nothing. Then restart. If apt says the package lock is held by fireproofd, the old daemon is still waiting out its one-hour stop timeout, and a normal restart is refused while it waits: free the lock with sudo systemctl kill --signal=KILL fireproofd.service (or restart with sudo systemctl reboot -i), then run the repair.

After updating from 5.0.0

Log out and back in once. The update does not restart the Mission Control worker already running in your session, so until you do, that worker is still the 5.0.0 engine. To restart only the worker instead:

systemctl --user restart shadowfetch-missions.service

Nothing else changes for a 5.0.0 setup: no setting, command or file format.

After updating from 4.1

The same two commands bring a 4.1 system straight to 5.0.1, because the umbra suite serves the newest release. Everything in upgrading from 4.1 to 5.0.0 applies: log out and back in once, check shadowfetch-agent-network status, update scripts that used the removed commands, and connect your services in ShadowCode. Read what changes for a 4.1 system first.

A new install

There is no 5.0.1 ISO. Install from the 5.0.0 ISO (shadowfetch-5.0.0-amd64.iso, verify it first), then run the two commands above.

What 5.0.1 fixes

fireproof update can update Fireproof itself

Found in 5.0.1 QA; present since 2.1.4. fireproof update (and the Fireproof page) could not install an update that included shadowfetch-fireproof. The new package's install script stopped Fireproof's daemon, fireproofd. That daemon is the process running apt and dpkg, and systemd stopped everything inside its service, so dpkg was killed halfway through the update, leaving dozens of packages unpacked but not configured. needrestart then tried to restart fireproofd from inside the same update, which could hang for up to an hour while holding the package lock and blocking reboot.

• No install script of the package stops, starts or restarts fireproofd any more.
• Stopping fireproofd signals the daemon only, not dpkg (KillMode=mixed). The daemon already waits for dpkg to finish before it exits.
• needrestart never restarts fireproofd.
• The new daemon still takes over once the update is done: an idle daemon is restarted right away, and when fireproofd is the one running the update, the restart waits until that update has finished.
• An interrupted update is reported, not built on. When an earlier dpkg run was interrupted, fireproof check, fireproof update and the Fireproof page offer no update; they list the unfinished packages and show the command that repairs it, sudo dpkg --configure -a && sudo apt -f install.
• The verify battery's “Mirror still resolves” check now looks up the mirror's host name; a mirror URL with a port was looked up as host:port and reported as not resolving.

Fireproof never removes packages as a side effect of an update

Found in 5.0.1 QA. While Debian testing is in the middle of a library transition, some upgrades can only be installed by removing packages that still use the old library. In QA, on a system that came from 4.1, Fireproof planned 14 to 16 removals during the libavcodec/mlt transition, among them shadowfetch-desktop, shadowfetch-creative-base, Krita and Kdenlive; on the same system apt full-upgrade held 12 packages back and removed nothing. Fireproof planned the update with libapt's classic resolver, which removes packages to install upgrades; apt 3's solver holds those upgrades back.

• When the full update would remove a package, Fireproof keeps that package and holds back only the upgrades that needed it removed. Nothing is removed, and the rest of the update goes ahead.
• fireproof check, fireproof update and the Fireproof page list the held-back packages, the packages that would have been removed, and why: Debian testing is in a library transition, the updates will install once it completes, and you do not need to do anything. Held-back updates are not counted on the update badge.
• The only removals an update can make are the ones Shadowfetch itself asks for: a package that an incoming shadowfetch-* package conflicts with or breaks, and that was installed automatically. shadowfetch-desktop, shadowfetch-creative-base and any package you installed yourself are never removed by an update.
• The commit re-checks the same plan under the package lock and refuses a plan that would remove a protected package. The update is still wrapped in a Phoenix Point.

“database is busy” from Mission Control under heavy disk load

5.0.0 known issue. While a mission finished a step on a heavily loaded disk, Mission Control and shadowfetch-missions show, list and cancel could answer “database is busy” after waiting 10 seconds.

Cause. The mission engine opens and closes a database connection for every call, so nearly every close was the last open connection. SQLite's last close copies the write-ahead log back into the database and deletes it, and it holds an exclusive lock while it waits for two disk syncs. Every other process waited behind that lock. On the 5.0.0 stress guest one sync took 15 to 34 seconds, so a single read could wait past its whole budget.

• No connection copies the log back on close any more. SQLite's normal checkpoint after a commit still keeps the log small, and it blocks no one. Short commands also skip that checkpoint, so no sync lands on them after they commit. Data is as safe as before.
• Reads no longer wait on a writer. show, list, events and the desktop's views answer while the worker is writing.
• The engine now needs Python 3.12 or newer (Depends: python3 (>= 3.12)). The 5.0 image already ships a newer one.

Stop works while the database is busy

• Stop is saved first. cancel saves the request as a small file in Mission Control's private state directory, then waits at most 2 seconds for the database.
• If the database is busy, cancel answers at once that the Stop was requested and saved, and is recorded in the mission's history as soon as the database is free. Mission Control shows Stop requested: saved, waiting to be recorded until the worker records it.
• The worker records it as the ordinary stop, in the mission's history, at its next check. A queued mission whose stop is not yet recorded does not start.
• A late Stop is never lost. If the Stop arrives while the mission is already finishing, the history says the stop was asked for and not applied.
• If the request cannot be saved (a full disk, for example), cancel writes the stop directly, as 5.0.0 did.

Missions created together run in the order you created them

5.0.0 broke a tie between missions created in the same second on their random mission id, so four media missions created within half a second ran 1, 4, 3, 2. Missions now run, and list, in the order they were created.

A waiting mission says what it is waiting for

In 5.0.0, once one mission waited for your review, the other missions for the same project stayed Queued with nothing running and no reason given. The engine holds them until you review the first one, and now says so: show and list report a hold naming the mission you need to review, and Mission Control shows the reason on the queue row (the tooltip has the full message) and under Waiting in the mission's Overview. The rule itself is unchanged.

Live USB: the package-list refresh

5.0.0 known issue. About five minutes after login, KDE's update notifier refreshes the package lists in the live session: a download of about 200 MB that also uses about 350 MB of RAM, because a live session keeps its changes in memory.

shadowfetch-defaults 5.0.1 does not start the update notifier on a live USB; installed and upgraded systems keep update notifications. An update cannot change a USB stick, and 5.0.1 comes without an ISO, so a 5.0.0 USB stick keeps the refresh. The change reaches the live USB only with a later ISO. On a 5.0.0 stick, keep using the workaround: stay offline in the live session, or run systemctl --user stop app-org.kde.discover.notifier@autostart.service soon after logging in.

ShadowCode's window size (Wayland)

5.0.0 known issue. Under Wayland, ShadowCode 1.0.0 opens a slightly larger window each time, and on a 1366x768 screen even the first window is larger than the screen. 5.0.1 moves ShadowCode to 1.0.1, which fixes this: ShadowCode_1.0.1_amd64.deb, 28,892,500 bytes, SHA-256 dce2064d6b2df07aabf61e0ee9c9006383e22322e8895389dce09fb5f2490b8b, republished byte for byte from upstream's signed release.

Package changes

Every Shadowfetch package moves to 5.0.1-1; nothing is added or retired. Each package's debian/changelog has the details.

Known issues

• Install this update with apt, not fireproof update: on a 4.1 or 5.0.0 system the update is still run by the Fireproof already installed, which can stop partway through updating Fireproof itself and can remove packages during a Debian testing transition. Run sudo apt update, then sudo apt full-upgrade; packages apt lists as kept back are expected during a transition, and apt removes nothing. From 5.0.1 on, fireproof update is safe again. If an earlier update stopped partway (sudo dpkg --audit prints anything, or apt asks for dpkg --configure -a): if apt says the lock is held by fireproofd, run sudo systemctl kill --signal=KILL fireproofd.service first; then run sudo dpkg --configure -a, then sudo apt full-upgrade, then sudo apt install shadowfetch-desktop shadowfetch-creative-base, and restart.
• Live USB: there is no 5.0.1 ISO, so every live USB is a 5.0.0 stick and keeps KDE's update notifier. About five minutes after login it refreshes the package lists, a download of about 200 MB that also takes about 350 MB of RAM. If the computer is low on memory or the connection is metered, stay offline in the live session or run systemctl --user stop app-org.kde.discover.notifier@autostart.service soon after logging in. Installed systems are not affected.
• After updating, the Mission Control worker already running in your session is still the 5.0.0 engine until you log out and back in, or run systemctl --user restart shadowfetch-missions.service.
• A shadowfetch-missions create that answers "database is busy" may already have queued the mission: after it commits, the engine reads the database once more to write the mission's entry to the system journal, and in rare cases under very heavy disk load that read is the one that answers busy. Check shadowfetch-missions list before creating it again. Not fixed in 5.0.1.
• Stop can still be slow on a saturated disk in one case: right after SQLite has emptied its log, the next write restarts the log with two disk syncs, and on the 5.0.0 stress guest one sync took up to 34 seconds. The Stop is saved before that write, so the worker still records it.
• Carried from 5.0.0, unchanged: the security advisory about the shared DKMS module-signing key on systems installed from 4.x ISOs (shadowfetch-doctor still flags it), OpenClaw's security-advisory record, Hermes Agent running unsandboxed, the agent network not setting ShadowCode's own network mode, ShadowCode's first run opening light on the dark desktop, ShadowCode's glibc 2.39 and Vulkan requirements, and Secure Boot that is not Microsoft-signed. See the known-issues page.

All known issues →

Release state

5.0.1 is delivered as packages in the signed APT repository only; no 5.0.1 ISO is built. New installs start from the 5.0.0 ISO, SHA-256 2d8a72e044e8061bd616b2b4668425cc4d4ec0480a98975f961c0e58cba95e21, whose acceptance record is on its release notes.

The Fireproof no-removals fix was proven in a VM on the 4.1 upgrade base against the served, signed 5.0.1 repository: sudo apt update && sudo apt full-upgrade to 5.0.1 (0 removed, 12 kept back), a reboot, then fireproof check and fireproof update against the live Debian testing archive, which proposed 0 removals, listed the same 12 held-back packages with the message, and left shadowfetch-desktop, shadowfetch-creative-base, Krita and Kdenlive installed. Fireproof's self-update was proven by a diagnostic VM run with a prototype of the fix.

The Mission Control fixes are proven by host-side tests: a worker-shaped process with every disk sync delayed by 12 seconds while show polls and Stop is pressed fails on the 5.0.0 engine and passes on 5.0.1, and with each sync delayed by 3 seconds Stop answered in 0.2 seconds. The live-USB change was checked against the shipped 5.0.0 image with the 5.0.1 drop-in added: the notifier was skipped at login in the live session and still started on an installed system.

Qualification of the published packages: Packages-only acceptance subset recorded against the published repository indices (qa/5.0.1/acceptance.json): SRC-01, PKG-01, UPGRADE-01 and DURABLE-01 pass; MISSION-01 is waived by the release owner for the paid-account code mission only. A 5.0.0 -> 5.0.1 upgrade with sudo apt full-upgrade passed 19/19 checks in a VM (nothing removed, user data and ShadowCode settings kept, Mission Control fixes live, ShadowCode 1.0.1 window stable), and fireproof update afterwards exited 0 with no removals. The live signed InRelease is byte-identical to the one built and verified (SHA-256 2be292bd8008d3459481845a6433fc9d81ebca3001a94bab71f0b900f07fc279).

Source: Shadowfetchapps/shadowfetch-linux, branch release/5.0.1. Release history: changelog.