rob thijssen 755031ac16
Some checks failed
build image / build (push) Has been cancelled
Remove the custom motd, and stop asserting a guess as the cause
Two problems, one of them mine twice over.

The motd is gone entirely. It had been wrong in a way that mattered — telling
anyone who logged in that onboard WiFi worked when it does not — and a login
banner is a bad place to keep claims that need revising every time we learn
something.

The worse issue is what it and the docs said about why the modem fails. I
inferred from the WOA-Project repository being named "Qualcomm-Reference-
Drivers" that its modem image was a generic reference build unsuited to this
machine's radio, and wrote that up as the explanation. That was a guess resting
on a repository name, and the naming is about redistribution rather than the
contents. Removed from both README and docs/firmware.md.

What is actually established stays: the modem boots, loads mpss, and dies at
"RF stuck in QLINK start state", roughly every 42 seconds. The cause is not
known. The machine has a SIM slot and its modem worked under Windows, so the
radio hardware is present — and the same cabinets supply the GPU, DSP and venus
firmware, all of which work, so whatever is wrong is specific to the modem.
The docs now say that and stop there.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01XWRjNJMistCy6ngXH5aJLS
2026-07-28 08:25:26 +03:00

Fedora for the Lenovo Yoga C630 13Q50

Builds a ready-to-write Fedora aarch64 disk image for the Lenovo Yoga C630 (model 81JL, Qualcomm SDM850), using Gitea Actions.

The approach is borrowed from aarch64-laptops/build, but the heavy lifting that project had to do in 2019 is now unnecessary: mainline Linux has carried sdm850-lenovo-yoga-c630.dts since 5.5, and Fedora ships it in kernel-core. There is no kernel to patch and no GRUB to compile. What is left is assembling a disk image that boots on hardware whose firmware hands Linux no device tree.

What you get

output/fedora-44-<variant>-lenovo-yoga-c630-<date>-<ref>.img.zst — a GPT disk image with an ESP, a /boot partition and an ext4 root. Decompress, write it to a USB stick or microSD card, and boot. The root filesystem grows to fill the medium on first boot.

Two variants:

Variant Size Contents
minimal 8 GiB Console, sshd, and enough tools to debug the machine
workstation 16 GiB GNOME desktop

Default login is fedora / fedora, and the password must be changed at first login. Root is locked.

Hardware status

Works Works once you supply firmware Does not work
UFS storage, USB, keyboard, touchpad, touchscreen Adreno 630 initialises — see mesa note below Audio — kernel driver, not firmware
Display (unaccelerated), battery, charging Sensor hub — accelerometer, auto-rotate Onboard WiFi — loaded by the modem, which does not stay up
USB WiFi dongles, USB phone tethering Hardware video decode (venus, /dev/video0-3) LTE modem — crashes at RF init, cause unknown

Verified on hardware. docs/firmware.md has the evidence for each, including the things that look like they should help and do not.

Graphics comes with a caveat. With qcdxkmsuc850.mbn in place the GPU genuinely initialises — gpu-initialized: 1, revision 630, executing submissions. But mesa's freedreno EGL path then segfaults in dri2_drm_swap_buffers, taking gnome-shell down in a login loop. Until that is fixed upstream, the desktop needs software rendering:

echo 'MESA_LOADER_DRIVER_OVERRIDE=kms_swrast' | sudo tee /etc/environment

Note LIBGL_ALWAYS_SOFTWARE=1 does not work here — mutter uses EGL, which ignores it.

Getting the firmware: see docs/firmware.md. The cabinets from WOA-Project are the easiest route; sudo c630-firmware works if the Windows partition survives.

Building

CI does this on every push to main. To run it yourself:

./build/build-image.sh --variant minimal

You need podman and, on an x86_64 host, aarch64 emulation:

sudo dnf install -y qemu-user-static-aarch64
sudo systemctl restart systemd-binfmt

build/build-image.sh runs on the host and only sets up the container. build/stage2.sh runs inside an aarch64 Fedora container and does everything else: dnf --installroot, the overlay, dracut, and the disk assembly. It builds filesystems from directory trees with mke2fs -d and mcopy rather than mounting loop devices, so it does not need /dev/loop-control — which CI runners generally will not hand out.

Iterating

Every aarch64 binary runs under emulation, and the dnf transaction is essentially all of the cost — 500-odd packages' worth of rpm scriptlets for minimal, four times that for workstation. Everything after it takes minutes. Since getting this machine to boot will take a few attempts, the build is arranged so you only pay that once:

  • The post-dnf root filesystem is staged under <work>/base, keyed on a hash of the package lists, release and variant. Editing config/device.env, overlay/, or the bootloader config reuses it. Editing config/packages/ invalidates it automatically.
  • The working copy is made with cp --reflink=auto, so on btrfs or xfs it is a copy-on-write clone rather than a real copy.
  • Downloaded rpms live in .cache/dnf, outside the staged tree, so even --fresh re-runs the scriptlets without re-downloading.

In practice a kernel-command-line change rebuilds in a few minutes.

./build/build-image.sh --variant minimal            # reuses the staged base
./build/build-image.sh --variant minimal --fresh    # forces a reinstall
./build/build-image.sh --variant minimal --keep-rootfs   # keep the tree to poke at

CI points --work and --cache at /var/tmp/c630-build so both survive between jobs. That is per-runner, so the first build on a given runner is cold.

The build container defaults to git.lair.cafe/gongfoo/build-fedora-44-aarch64, which ships the assembly tooling so it does not have to be installed under emulation on every run. If that image is not reachable the build falls back to stock Fedora and installs the tooling itself — slower, but it works.

Repository layout

config/device.env            C630 parameters: DTB path, kernel command line, geometry
config/packages/*.pkgs       Package lists — base plus one file per variant
overlay/                     Files copied into the root filesystem (*.in are templated)
build/build-image.sh         Host driver: emulation checks, podman invocation
build/stage2.sh              The actual build, inside an aarch64 container
firmware/local/              Optional drop-in for firmware you extracted yourself (gitignored)
.gitea/workflows/            CI
docs/                        Installation, firmware, runner setup

Documentation

Boot status

Confirmed on hardware, from a USB stick:

  • GRUB loads the kernel and the device tree
  • The kernel comes up and probes the SDM850 — UFS controller, display subsystem, WiFi and IPA all appear as platform devices, so DEVICE_CMDLINE and the DTB are right
  • The framebuffer console works (simple-framebuffer, 240x67)
  • The root filesystem mounts, systemd starts, and it reaches a login prompt
  • Networking works over a USB WiFi dongle, and sshd is reachable
  • build/install-to-disk.sh copies it onto the internal UFS, and it boots from there with the stick removed — 18s to multi-user, no failed units

The RTC cannot be set on this machine and reads 1970 at every boot, so chrony is installed and corrects the clock once the network is up. Until it does, rpm rejects package signatures dated after the (wrong) current time and reports installed packages as missing — see docs/install.md.

With the per-model firmware supplied, the GPU initialises, the ADSP, CDSP and SLPI all run, sensors appear as IIO devices and venus registers /dev/video0-3. Audio and onboard WiFi remain broken for reasons unrelated to firmware — see docs/firmware.md, which records both the evidence and the several plausible fixes that turn out not to work.

The internal drive needs build/install-to-disk.sh rather than dd: its UFS uses 4096-byte logical sectors, which the 512-byte image geometry cannot be written onto directly. See docs/install.md.

SELinux is shipped permissive — see below.

SELinux

The build labels the filesystem offline with setfiles, so enforcing should work. It ships permissive anyway, because the failure mode is unusually punishing: an unlabelled root takes PID 1 down with Failed to allocate manager object before anything can be logged into and repaired, and /.autorelabel cannot save it because nothing survives long enough to act on the flag.

Once the machine is up and you are happy with it:

sudo setenforce 1                 # try it for this boot
sudo sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config

Or set SELINUX_MODE=enforcing in config/device.env and rebuild.

Caveats

The kernel command line and firmware layout are taken from Fedora's Snapdragon WoA documentation and the aarch64-laptops project; the parts specific to the C630's older SDM850 are reasoned from those rather than derived from documentation for this machine. Findings belong in this README.

Description
No description provided
Readme 399 KiB
Languages
Shell 100%