git clone https://github.com/... fails with 'server certificate verification
failed. CAfile: none' because ubuntu:24.04 with just 'git' doesn't pull in
ca-certificates. Hit in 'Building NXP IW620 mwifiex driver' stage.
#20 added the distro directories but missed updating the dispatch choice
enum and the 'all' matrix expansion, so the three new distros couldn't
be triggered through CI.
linux-ps5 currently ships no wifi driver — the PS5 onboard wifi is NXP
IW620 (not the upstream mwifiex), which lives at ps5-linux/ps5-linux-
mwifiex as an out-of-tree patch against nxp-imx/mwifiex. Users have to
clone that repo + run install.sh on the target, which needs gcc + kernel
headers and is a manual step every kernel bump.
Build it in the kernel-builder container right after the kernel: clone
both repos, apply ps5-iw620.patch, make against the kernel src tree,
install mlan.ko+moal.ko into /out/staging/lib/modules/$KVER/extra/
ps5-iw620/ with the NXP modprobe options + autoload conf. depmod -b
refreshes the index. All package formats (.deb/.rpm/.pkg.tar.zst) then
include the driver automatically.
MWIFIEX_REPO / MWIFIEX_REF overridable via env in case downstream wants
to test a fork or specific commit.
Steam in -steamos3 mode polls for SteamOS atomic OS updates via
steamos-update, steamos-update-rauc, steamos-atomupd-client. CachyOS
ships none of these (pacman handles rolling updates), so every poll
fires "YieldingApplyUpdateOS: OS update result: 2" and the GamepadUI
shows "Updater apply error: 2: null".
That alone is just a banner, but the first-run OOBE blocks on the
"Software updates" step waiting for a successful update result, so
users can't get past initial setup. Field-reported.
Dropping -steamos3 keeps -gamepadui (controller-friendly UI) without
the SteamOS-mode update polling. OS updates: sudo pacman -Syu.
Polls ps5-linux/ps5-linux-patches for new kernel-X.Y.Z-<sha> tags at
04:00 UTC. If newer than build_image.sh's PATCHES_REF, bumps + pushes
to main; the push fires trigger-builds.yml which rebuilds all images
against the new kernel. Safe-skips if PATCHES_REPO has been forked.
The dispatch in #20 ran build-rootfs.sh without exporting $CHROOT, so
inside the script it was empty — meaning '/' expansions like
`mv "$UNPACK/rootfs"/* "$CHROOT/"` resolved to '/' and the bazzite
rootfs went into the build container's root. Container-contained, but
the build failed with a confusing 'Device or resource busy' on
/etc/resolv.conf.
Two fixes:
- entrypoint exports DISTRO/CHROOT/KVER/ROOT_LABEL/EFI_LABEL when
calling the per-distro script, and asserts $CHROOT non-empty.
- bazzite + batocera scripts have a top-of-file guard that bails if
$CHROOT is unset, missing, or '/'.
Co-authored-by: mia26MAjFm <mia26MAjFm@users.noreply.github.com>
Each distro ships with a self-contained build-rootfs.sh that the entrypoint
calls in place of distrobuilder. This keeps upstream's distrobuilder flow
untouched for the existing distros (ubuntu/arch/cachyos/fedora/etc.) and
isolates the new distros' build logic in their own dirs.
distros/bazzite/
build-rootfs.sh — skopeo+umoci on ghcr.io/ublue-os/bazzite:stable,
promote ostree /usr/etc -> /etc, install linux-ps5 RPM,
mask rpm-ostree services, set up grow-rootfs + DTM-TA
amdgpu reprobe.
image.yaml, grow-rootfs, grow-rootfs.service
distros/bazzite-deck/
Symlinks into distros/bazzite/ — bazzite-deck shares all build logic;
the case branch in build-rootfs.sh dispatches via $DISTRO.
distros/batocera/
build-rootfs.sh — download upstream batocera-x86_64-*.img.gz, mount,
extract /boot/batocera squashfs, swap in linux-ps5
kernel, patch libretroControllers.py, install first-boot
SHARE-partition creator (ps5-share-init).
docker/image-builder/entrypoint.sh
- detect_kver() helper from /kernel-debs/ package filenames
- dispatch to distros/$DISTRO/build-rootfs.sh when present (skips
distrobuilder for that distro)
- EFI assembly detects /boot/efi/ vs /boot/bzImage layouts so batocera
(which mounts FAT at /boot, not /boot/efi, for batocera-part SHARE
detection) works alongside the standard layout
build_image.sh
- IMG_SIZE defaults: bazzite* -> 24 GB, batocera* -> 16 GB
- FORMAT: bazzite* -> rpm (linux-ps5 RPM); batocera* stays deb
CI workflows are NOT modified — the upstream build-image.yml /
trigger-builds.yml continue to apply and will skip these distros unless
explicitly dispatched (they're not in MULTI_DISTROS). Local builds:
./build_image.sh --distro bazzite
./build_image.sh --distro bazzite-deck
./build_image.sh --distro batocera
Co-authored-by: mia26MAjFm <mia26MAjFm@users.noreply.github.com>
Both packagers copied the staged UAPI headers with:
cp -a /out/staging/headers/usr "$DEST/usr"
Because $DEST/usr already exists (modules live under $STAGING/usr/lib/modules,
and other files may be staged under $PKG/usr), cp placed the source directory
inside the destination, producing a nested usr/usr/include/ path. The headers
were therefore installed at the wrong location and not found by builds.
Merge the contents with cp -a .../usr/. "$DEST/usr/" so the headers land at
the expected /usr/include/linux/... path in both .deb and .pkg.tar.zst
packages.
Plain Debian 12 Bookworm with XFCE desktop, LightDM autologin, Firefox
ESR, and standard desktop utilities. Fills the gap between the heavier
Kali (Debian + security tools) and the headless Proxmox (Debian +
hypervisor) — a clean, lightweight Debian desktop for PS5.
Tested on PS5 hardware: XFCE displays over HDMI, boots to desktop.
[skip ci]
The release step now fetches the existing release body and merges the
new distro rows into it, instead of rebuilding the table from scratch.
This means a single-distro build (e.g. --distro fedora) only updates
that distro's row and checksum — all other distros stay in the table.
Previously, every single-distro CI run wiped the other distros from
the release page, requiring a manual API patch each time.
[skip ci]
Debian 12 Bookworm base with Proxmox VE 8.4 (pve-manager, pve-qemu-kvm,
qemu-server). Headless hypervisor managed via web UI at https://<ip>:8006.
Login: root/proxmox.
The PS5 kernel can't satisfy proxmox-ve's hard dependency on a Proxmox
kernel, so the recipe installs an equivs stub (ps5-proxmox-kernel-stub)
that Provides: proxmox-default-kernel before installing proxmox-ve. First
boot auto-bridges the PS5 ethernet into vmbr0 with DHCP. WiFi is not
included (Proxmox VM networking requires wired bridging).
Also wires proxmox into the CI matrix, entrypoint staging, and release
table.
[skip ci]
Ubuntu's apt umoci (0.4.7) crashes on the self-hosted arm64 runner with
"fatal error: lfstack.push invalid packing" while unpacking Fedora's OCI
base image. The image-builder is an amd64 image, so it runs under qemu on
the arm64 runner, and the emulated process inherits the host's 52-bit-VA
high addresses that the old Go in apt's umoci mis-packs in lfstack. Build
umoci v0.5.0 from source with the Go 1.25 toolchain already installed
(Go >=1.21 handles high virtual addresses correctly). Only Fedora uses
umoci (OCI base); the other distros use debootstrap/pacstrap.
[skip ci]
New fedora distro: distrobuilder fedora-http recipe with full GNOME
desktop (GDM autologin), the PS5 IW620 internal WiFi modules built from
nxp-imx/mwifiex + ps5-linux-mwifiex, and an RPM packaging path for the
shared PS5 kernel (docker/kernel-builder-rpm).
Notable PS5-specific fix: the kernel patches write into the
request_firmware() buffer to skip the firmware signature header
(gfx_v10_0_early_init, amdgpu_sdma_init_microcode). Fedora ships
firmware xz-compressed, and the kernel maps xz-decompressed firmware
read-only (fw_decompress_xz_pages -> fw_map_paged_buf -> vmap
PAGE_KERNEL_RO), so the write oopses amdgpu before /dev/dri exists and
the display never comes up. Distros with zstd or uncompressed firmware
decompress into writable buffers, which is why only Fedora was
affected. The recipe therefore ships the cyan_skillfish GPU firmware
uncompressed, materializing linux-firmware's dedup symlinks first
(unxz refuses symlinks).
Also installs umoci/skopeo in the image builder (Fedora 41+ bases ship
as OCI archives) and wires fedora into build_image.sh (FORMAT=rpm) and
the image-builder entrypoint.
Tested on PS5 hardware: GNOME displays over HDMI, internal WiFi scans
and connects.
[skip ci]
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
