The Windows backups never turned up, which looked terminal. It is not, because
these blobs are signed per model rather than per machine — a copy from any
other Yoga C630 works.
The evidence is in linux-firmware itself, which already ships the exact
analogous set for the ThinkPad X13s under qcom/sc8280xp/LENOVO/21BX: the zap
shader, ADSP, CDSP, SLPI and venus firmware, one copy serving every unit of
that model. So redistribution is a licensing question rather than a technical
one, and qcom/sdm850/LENOVO/81JL/ has simply never been contributed. It will
not arrive in a linux-firmware update.
Record two routes: Lenovo's Digital Download Recovery Service, which builds a
Windows recovery image against a machine's serial for its owner and carries the
whole DriverStore; and other C630 owners, where these have circulated before.
Reconcile two earlier claims that this contradicts — that nobody can
redistribute them, and that a backup or surviving Windows partition were the
only routes. Both were wrong in the same way: they described this machine's
situation as though it were a property of the files.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
Tested on the machine. With the generic Adreno firmware reachable from the
initramfs and the model-signed blob absent, the GPU gets two files in and stops:
loaded qcom/a630_sqe.fw from new location
loaded qcom/a630_gmu.bin from new location
*ERROR* Unable to load qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn
*ERROR* gpu hw init failed: -2
That settles a question the docs had been hedging: the zap shader is a hard
requirement, not an optimisation, and the generic pieces are necessary but not
sufficient. Getting past sqe and gmu only to die at zap is about as clean a
demonstration as the hardware will give.
Two things fall out of the same trace and are worth writing down, because
nothing upstream documents them for this machine. The driver never falls back
to the installed sdm845/a630_zap.mbn — the device tree pins the model-specific
path — and a fallback would not help anyway, since the shader is signed against
this device's own secure-boot chain. And the display survives the failure
entirely: msm_dpu still binds the panel, so a dead GPU costs acceleration
rather than a picture, and a desktop runs on llvmpipe.
Also record why these files have to travel in the initramfs at all: msm_dpu
probes around six seconds in, while the initramfs is still root, and never
retries.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
It boots from the internal drive with the stick removed — 18s to multi-user,
no failed units.
The first thing tried on it was `dnf install net-tools`, which failed with:
Transaction failed: Rpm transaction failed.
- systemd is needed by net-tools-2.0-0.77.20160912git.fc44.aarch64
systemd is obviously installed; the machine had just booted. The cause is the
clock. This machine's RTC cannot be set at all — ioctl(RTC_SET_TIME) returns
"No such device" — and reads 1970 every boot, so systemd advances it to its own
build date. That is close enough to look plausible and early enough that rpm
treats package signatures created after it as not yet valid, skips those
headers outright, and reports the packages as absent:
Signature created at Sat Jul 25 18:33:30 2026 invalid: signature is not alive
error: rpmdbNextIterator: skipping h# 282
package systemd is not installed
chrony was already added to base.pkgs for the drift; it turns out to be load
bearing rather than a nicety, and it syncs within about five seconds of the
network appearing. Documented, because the symptom points nowhere near the
cause.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
Validated by running it on the machine, twice, and inspecting the result.
Two properties of this laptop rule out the obvious approach, and the script
exists mainly to encode them. Its internal UFS reports 4096-byte logical
sectors, so the image — built with 512-byte geometry — cannot be dd'd onto it;
the GPT header and every partition offset would land in the wrong place. And
there are no EFI runtime variables, so efibootmgr cannot register a boot entry
and GRUB has to sit at the removable-media path where the firmware looks
unprompted.
Three things the validation runs caught that review would not have:
rsync is not in the image. I had put it in the build container and never in
the package list, so the first run died at the copy. It now falls back to tar
(--xattrs-include='*', or SELinux labels are silently dropped and the result
does not boot), and rsync is in base.pkgs for the progress output.
Copying a live root makes tar exit non-zero — files change underneath it, and
this machine's clock is wrong besides, so every mtime looks like it is in the
future. With pipefail that aborted the install after the root filesystem and
before /boot, leaving a half-installed disk that looked plausible. Warning-level
exits are now tolerated and only a fatal exit 2 stops the run.
systemd-machine-id-setup keeps an existing valid id, and one had just been
copied off the stick, so the installed system was a clone. The file is removed
first now.
Also: msm_dpu probes ~6s in, while the initramfs is still root, and asks for
qcom/a630_sqe.fw before the real filesystem carrying it is reachable. It never
retries. Adding the Adreno firmware to the initramfs is a few tens of
kilobytes. c630-firmware does the same for the DSP blobs once they exist, since
dracut rejects install_items globs that match nothing.
chrony, because the RTC reads 1970 and nothing was correcting it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
The first real run took 100 minutes. Roughly 60 of those were spent doing
things that either did not need doing or did not need doing under emulation.
dracut ran three times. The kernel's %posttrans runs kernel-install, which
builds an initramfs, and dracut-config-rescue makes it build a second, rescue
one — both before this build has written /etc/dracut.conf.d/10-c630.conf and
before /proc is bind-mounted, so both are wrong as well as expensive. stage2
then builds the real one. Setting initrd_generator=none in the install root for
the duration of the transaction suppresses both: 50-dracut.install and
51-dracut-rescue.install each bail when KERNEL_INSTALL_INITRD_GENERATOR is not
"dracut". Excluding dracut-config-rescue also spares the laptop a rescue
initramfs on every future kernel update, which on this hardware is not cheap.
That file must not ship. With it in place the machine would boot fine and then
fail to come back after its next kernel update — a bug that surfaces weeks
later looking nothing like an image problem. It is removed from the working
copy, and asserted absent again immediately before the root filesystem is
built.
Compression was running as an aarch64 binary under qemu-user for no reason;
zstd does not care what architecture it runs on. It now runs on the host when
the host has zstd, falling back to in-container otherwise so the build never
depends on it. Measured ~20 minutes against ~2.
Add BASE_RECIPE to the staged-base stamp. Excluding a weak dependency changes
what the base contains without changing the package list it hashes, so without
this the next build would happily reuse a stale base.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
I had this wrong. The claim that accelerated graphics works on the firmware
Fedora ships does not survive contact with the device tree.
Fedora does package an sdm845/a630_zap.mbn, which is what led me astray, but
that is the generic Snapdragon 845 zap shader. The C630's node in
sdm850-lenovo-yoga-c630.dts names qcom/sdm850/LENOVO/81JL/qcdxkmsuc850.mbn
specifically — model-signed, present only in the machine's Windows partition.
Until it is supplied the display is unaccelerated.
Also add qcslpi850.mbn and qcvss850.mbn, which were missing entirely, and
attribute the sensor hub to slpi_pas rather than cdsp_pas. The list is now
every firmware-name property in the mainline device tree rather than a
recollection of forum posts, so it should be complete: eight files, not five.
WiFi and Bluetooth are unaffected — ath10k WCN3990 including wlanmdsp.mbn is
genuinely redistributable and genuinely shipped.
Add a section on locating the blobs on an old backup, for the case where
Windows is long gone from the machine.
Only comments changed in config/packages/base.pkgs, so the package set hashes
identically and the staged base stays valid.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
The dnf transaction is essentially the whole cost of a build — emulated rpm
scriptlets for 502 packages on minimal, 1929 on workstation. Everything after
it is minutes. Getting this laptop to boot will take several attempts at the
kernel command line and the dracut driver list, and paying for a reinstall each
time is not tenable.
Stage the post-dnf tree under <work>/base, keyed on a hash of the package
lists, release and variant, and copy it per build with --reflink=auto (a CoW
clone on btrfs). Config and overlay edits now reuse it; package list edits
invalidate it on their own, so --fresh is only needed to force the issue.
Keep downloaded rpms in a cachedir outside the install root, so even --fresh
re-runs the scriptlets without re-downloading. keepcache=0 was exactly the
wrong setting for a build meant to be run repeatedly.
Add --work so CI can put both outside the job workspace, which is wiped between
runs, and default the build container to the gongfoo aarch64 build base so the
assembly tooling is not installed under emulation every time. That image is a
speedup, not a dependency: fall back to stock Fedora when it is unreachable.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
Assembles a ready-to-write disk image via Gitea Actions. Mainline has carried
sdm850-lenovo-yoga-c630.dts since 5.5 and Fedora ships it in kernel-core, so
unlike aarch64-laptops/build there is no kernel or GRUB to compile — what is
left is producing an image that boots on firmware which hands Linux no device
tree.
The build runs in an aarch64 container under qemu-user and builds filesystems
from directory trees with mke2fs -d and mcopy rather than mounting loop
devices, so it works on runners that will not hand out /dev/loop-control.
A kernel-install hook writes the devicetree line into each BLS entry; without
it the first `dnf update kernel` would produce an unbootable system.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
