Shadowfetch Linux 5.0.1 «Umbra» · ShadowCode

Known issues

The honest caveats for Shadowfetch Linux 5.0. Read this before you install on a machine you depend on.

Security advisory · 4.x installs

Earlier ISOs shipped a shared DKMS module-signing key

Building the ISO ran DKMS (for v4l2loopback-dkms), which generated/var/lib/dkms/mok.key and mok.pub, and the private key shipped in the image. Every install from the same ISO has the same key, and anyone with that ISO can extract it. Confirmed in 4.1.0; 4.0.0 and earlier releases were built the same way, so treat them as affected too.

The key only matters if you enrolled its certificate in Secure Boot:shadowfetch-gpu offers that enrolment on Secure Boot machines, and you may also have run mokutil --import /var/lib/dkms/mok.pub yourself. In that case, anyone with the ISO could sign a kernel module that your machine would trust. The 5.0.0 image is built without the key: each machine generates its own the first time DKMS builds a module. Existing installs keep the old key until you replace it.

If sudo mokutil --test-key /var/lib/dkms/mok.pub says the key is already enrolled:

sudo mokutil --delete /var/lib/dkms/mok.pub   # choose a one-time password
sudo rm /var/lib/dkms/mok.key /var/lib/dkms/mok.pub
dkms status                                   # for each <module>/<version>:
sudo dkms build --force <module>/<version> && sudo dkms install --force <module>/<version>
sudo mokutil --import /var/lib/dkms/mok.pub   # the new per-machine key

Reboot. In MOK Manager, choose Delete MOK and then Enroll MOK. If the key is not enrolled, you do not need to take any action; deleting the two files is still a good idea.

After upgrading a 4.x system to 5.0, shadowfetch-doctor reports the shared key as a sec.dkms_mok failure with these steps, and a one-time desktop notice at login points to them.

Earlier ISOs also shipped a shared ssl-cert-snakeoil TLS key; 5.0.0 installs generate their own on first boot. If you pointed a service at the snakeoil key, runsudo make-ssl-cert generate-default-snakeoil --force-overwrite.

Current known issues

5.0.1 is an update through the signed APT repository. From 4.1 or 5.0.0, install it with sudo apt update, then sudo apt full-upgrade, not withfireproof update (see the first item). Items marked “Fixed in 5.0.1 (apt update)” are fixed once you have updated; the 5.0.0 ISO and a freshly installed system have them until then. 5.0.1 release notes.

Update to 5.0.1 with apt, not fireproof update; from 5.0.1 on, fireproof update is safe again.
On a 4.1 or 5.0.0 system, this one update is still run by the Fireproof already installed. When fireproof update installs a new version of Fireproof itself, which 5.0.1 and every 4.1 to 5.0 upgrade do, it stops partway through and can stay stuck for up to an hour. Its update plan can also remove the desktop metapackages (shadowfetch-desktop, shadowfetch-creative-base) and apps such as Krita and Kdenlive while Debian testing is in the middle of a library transition; apt holds those packages back instead. So from 4.1 or 5.0.0, install 5.0.1 from a terminal with sudo apt update, then sudo apt full-upgrade, not with fireproof update or Control Center's Software page. If apt lists packages as kept back, that is expected during a transition: apt removes nothing. Then log out and back in once. From 5.0.1 on, fireproof update is safe again, including for Fireproof's own updates: it no longer stops itself partway, and it never removes packages during an update; while Debian testing is in a transition it holds back the upgrades that would remove packages and says so. If an update already stopped partway (sudo dpkg --audit prints anything, or apt asks for dpkg --configure -a): 1) if apt says the lock is held by fireproofd, run sudo systemctl kill --signal=KILL fireproofd.service (a normal restart is refused while it is stuck; sudo systemctl reboot -i also works); 2) run sudo dpkg --configure -a, then sudo apt full-upgrade, then sudo apt install shadowfetch-desktop shadowfetch-creative-base; 3) restart.
Fixed in 5.0.1 (apt update): ShadowCode's window no longer grows each time it opens (Wayland).
Each launch of ShadowCode 1.0.0 restores a slightly larger window, which can end up extending under the panel. On a 1366x768 screen even the first window is larger than the screen, so the message box and status bar sit under the panel. The 5.0.0 ISO installs ShadowCode 1.0.0, which does this. 5.0.1 brings ShadowCode 1.0.1, which fixes it: run sudo apt update, then sudo apt full-upgrade. Until you update, maximize the window (its maximize button, or Meta+PgUp); ShadowCode then does not save the size.
Fixed in 5.0.1 (apt update): Mission Control no longer says “database is busy” under very heavy disk load.
On 5.0.0, while a mission is finishing a step on a heavily loaded disk, Mission Control or a shadowfetch-missions command can briefly report “database is busy”. Nothing is lost. 5.0.1 fixes it: reads no longer wait on a writer, and Stop is saved even while the database is busy. Run sudo apt update, then sudo apt full-upgrade, then log out and back in once (or run systemctl --user restart shadowfetch-missions.service) so the Mission Control worker runs the 5.0.1 engine. Until you update: retry after a few seconds; the retry works.
Live USB: a package-list refresh about five minutes after login.
In the live session, KDE's update notifier refreshes the package lists about five minutes after you log in: a download of about 200 MB that also takes about 350 MB of RAM, because the live session keeps its changes in memory. Installed systems are not affected. Workaround, if the computer is low on memory or the connection is metered: stay offline in the live session, or stop the notifier soon after logging in with systemctl --user stop app-org.kde.discover.notifier@autostart.service. An update cannot change a USB stick: a 5.0.0 USB stick keeps the notifier, also after 5.0.1, because 5.0.1 is delivered through APT without a new ISO. Its change, which stops the notifier on a live USB, reaches the live USB only with a later ISO; until then, use the workaround.
5.0.1: a 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 the mission again. Not fixed in 5.0.1.
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.
5.0.0 is the signed ISO; six acceptance cases are waived, not passed.
Of the cases due before publication, 12 pass, including EVIDENCE-01 (the release evidence bundle), and 6 are waived by the release owner, who chose to ship this image and deliver its fixes through APT updates, starting with 5.0.1. Four waivers are account or harness limits: MISSION-01's code missions need a paid vendor account (the media and cited-report missions pass); GROK-01 and GROK-VISUAL-01 need an X/Grok account (install, integrity, launch to sign-in and the URL handler are proven, a signed-in session is not); and UPGRADE-01's recovery leg has no harness (the 4.1 to 5.0 upgrade and every migration check pass). Two are checks that did not pass: SHADOWCODE-01's open/close soak failed only its memory-drift check, which a diagnostic rerun traced to the live session's one-time package-list refresh rather than ShadowCode; and STRESS-01's two 45-minute runs of combined stress left the system healthy, but in both runs its mission loop stopped on “database is busy” and its container loop on a podman run --rm client that did not exit.
OpenClaw has a long security-advisory record.
More than 700 GitHub advisories since early 2026, including critical ones, and new ones monthly, by the count in Shadowfetch's own consent text. A pinned lockfile, the Firebreak sandbox and a Gateway that is off by default narrow exposure; they do not make OpenClaw safe. An enabled Gateway runs outside the sandbox with your file access. shadowfetch-openclaw update uses a lockfile npm generates at that moment, whose dependencies Shadowfetch has not reviewed. Update often.
Hermes Agent is not sandboxed.
It is installed into your home without root, but it runs commands and edits files as you.
The agent network setting does not set ShadowCode's network mode.
shadowfetch-agent-network offline (including an upgraded Ice machine) governs Firebreak sandboxes and the three optional agents only. ShadowCode starts Online by default; set Settings › Permissions & network › Offline in ShadowCode if you want it to run only local models. Vendor agents started by ShadowCode use their own sandboxes, not Firebreak or ShadowCode's own shell sandbox.
Rollback after the 4.1 upgrade was not exercised.
The in-place path through the signed APT repository was proven from an installed, APT-updated 4.1.0 system: it pulls in ShadowCode, applies the gold accent at the next login, moves an Ice machine to the offline agent network, removes the retired launchers and keeps user data. Rolling an upgraded system back was not exercised in acceptance. On a Btrfs root, Fireproof's Phoenix Points remain the rollback path; back up your files before upgrading either way. Scripts that called shadowfetch-element, shadowfetch-codex or shadowfetch-code-agent, passed sf.element=, or parsed element / blocked_by_ice / recommended_element from JSON output need updating.
The APT suite is still named umbra.
It is carried from 4.x so 4.1 systems receive 5.0 from the suite they already track; sources lists from 4.x keep working unchanged.
ShadowCode would idle at high CPU without a GPU render node.
On a machine with no /dev/dri/renderD* node (many virtual machines), ShadowCode's window process held 122–174% CPU while idle in 5.0 VM qualification. Shadowfetch sets WEBKIT_DISABLE_DMABUF_RENDERER=1 for the whole session only on such machines, through a systemd user environment generator; with it, ShadowCode measured about 7% over two minutes idle. Machines with a working GPU keep hardware rendering, and a value you set yourself wins. ShadowCode 1.0.0 does not handle this itself yet.
ShadowCode's first run can open in its light theme.
On the dark desktop its first run can open light and save “follow the system” as its appearance. Pick Dark in ShadowCode's settings. Unchanged in 1.0.0; reported upstream.
ShadowCode's local runtime needs Vulkan for the GPU.
ShadowCode needs glibc 2.39 or newer. Without a Vulkan-capable GPU its bundled llama.cpp falls back to the CPU, which is much slower for larger models.
Grok Bot needs an eligible cloud account and plan.
The installer verifies the native package and launcher. In earlier release testing the vendor app sometimes showed ‘Can’t Reach Grok Bot’s Computer’ and Retry before authentication; its cause has not been established. Account access and cloud task execution remain vendor-controlled states. API keys do not replace native sign-in. Setup, update and launch pause while the agent network is offline.
Mission recovery has a local boundary.
Review result files and tests. Local restore refuses newer workspace conflicts; it cannot reverse external effects from an approved network action. Interrupted work requires attention or retry, and a missing checkpoint cannot be restored automatically.
Secure Boot is not signed.
The ISO has no Microsoft-trusted shim. If the USB does not appear or refuses to boot, disable Secure Boot in firmware before installing. That is a firmware setting, not an installer checkbox.
Debian testing can move underneath us.
Most packages come from upstream Debian testing. Update behavior can change faster than on Debian stable. Fireproof reviews and simulates before it takes the dpkg lock; it does not make testing into stable.
Fireproof is a review-and-rollback path, not unattended updates.
It simulates the upgrade, flags risky removals, and relies on Phoenix/snapper snapshots on a Btrfs root. It will not download or install in the background. Rollback needs those snapshots and free space. An ext4 install does not get the same Phoenix Points.
Virtual graphics validation is not a hardware support matrix.
A virtual desktop screenshot and software-rendered GLX or Vulkan probe do not prove physical graphics performance. QXL guests can report no DRM render node (gpu-verify-failed); that is the known VM caveat, not an installed-desktop failure. NVIDIA, AMD, Intel, hybrid-laptop, and unusual-firmware performance can still need hardware-specific validation.
No model or cloud credential is bundled.
The ISO ships no model weights, API keys or account sessions. ShadowCode downloads a free local model only when you choose one. Mission Control's on-device provider reports installed-unavailable until you supply a model service. Grok Bot, Hermes Agent and OpenClaw are optional installs with their own sign-in or provider keys.
Heavy disk pressure affects task completion.
Earlier development stress runs exposed mission-review contention, container timeouts and vendor service failures under sustained disk pressure; those failed results remain in the historical evidence. In 5.0.0's two 45-minute stress runs the system stayed healthy, but mission commands hit “database is busy” (above) and in each run a podman run --rm client did not exit. The ordinary mission budget is 15 minutes. Checkpoints and durable state writes count toward that budget; the limit is checked cooperatively and is not a hard wall-clock termination guarantee.

The wider limits of what Shadowfetch does and does not claim are on thesecurity model page. Hardware notes that we can stand behind are on hardware.

Before reporting a bug

Record the exact ISO filename and whether the checksum matched.
Note UEFI vs legacy BIOS, Secure Boot state, CPU/GPU, RAM, and disk layout.
For install failures, include where Calamares stopped and whether the live session worked.
Run shadowfetch-health --json and attach the report after removing anything you consider private.
For browser migration problems, note the source browser, export format, and the assistant's validation result. Never attach a password CSV.

Then emaillinux@shadowfetchlinux.orgor open a GitHub issueon Shadowfetchapps/shadowfetch-linux. Please do not attach a password CSV.