First off, I want to say a huge thank you to the developers behind noob404's kernel, psxitarch, and better-initramfs. What has been achieved here is incredible engineering. I’ve spent the last few weeks digging deep into the stack to get a headless Baikal setup running, and in the process of submitting some PRs, I put together some thoughts on how we can make the ecosystem even more resilient for everyone.
I’ve successfully achieved headless SSH on my PS4 Baikal. The journey involved hitting 7 distinct bugs, submitting upstream fixes, and over 30 hours of "blind-debugging" via log-dumping to a FAT32 partition.
The takeaway from those 30 hours wasn't that the problems were inherently "hard", it was the realization that every layer of the PS4 Linux boot chain silently assumes a human is watching a screen.
This post isn't just a bug report. It’s an architectural critique of the underlying assumptions in our current stack and a proposal for how we can evolve. As a security engineer, when I look at the PS4 Linux ecosystem through a systems-integrity lens, several structural weaknesses become apparent.
1. The "Silent" Boot Contract
The current boot chain is a hand-off between five distinct stages: kexec payload → initramfs → rootfs → init → systemd.
In a robust system, each layer has a "contract" with the next. Currently, those contracts are undocumented and frequently violated:
Every one of my "bugs" was actually a violated assumption between layers. We need a formal Boot Contract a single-page specification defining what each layer MUST provide and MAY assume.
2. Failure Modes: The "Display-Only" Fallback
The deepest issue is that the ecosystem treats "no screen" as an impossible state.
Proposal: Implement a
3. Defaulting to Zero Observability
Currently, there is no standardized way to verify if a headless PS4 has even reached the kernel. We are forced to SSH and pray or pull the USB to read logs.
Proposal: A machine-parseable Boot Telemetry File at a known location (e.g.,
4. Lack of CI in Kernel Forks
Great work has been done on kernel forks (like noob404’s), but the lack of CI means regressions slip through easily. For example, modern GCC 13 identifies tautological NULL checks in the MT7668 driver as errors.
Proposal: Basic GitHub Actions for kernel repos. We don't need full boot testing just compile-testing against GCC 12, 13, and 14. I have already submitted the GCC 13 fixes and would be happy to provide the CI workflow PR as well.
5. Fragmented Configuration Surface
Right now, configuring a system requires touching 6+ files across 3 different filesystems (FAT32, cpio, ext4). This is a nightmare for reproducibility.
Proposal: A unified
6. Reproducible Rootfs Builds
Distributing the rootfs as a tarball leads to "warm" configuration errors like the missing
A Shift in Perspective
The community has done the impossible by getting Linux running on this hardware. But the current mental model assumes a user is sitting at a TV with a controller.
By adopting these SRE-style principles like contracts, observability, and reproducible builds we make the PS4 Linux experience more reliable for everyone.
I’ve successfully achieved headless SSH on my PS4 Baikal. The journey involved hitting 7 distinct bugs, submitting upstream fixes, and over 30 hours of "blind-debugging" via log-dumping to a FAT32 partition.
The takeaway from those 30 hours wasn't that the problems were inherently "hard", it was the realization that every layer of the PS4 Linux boot chain silently assumes a human is watching a screen.
This post isn't just a bug report. It’s an architectural critique of the underlying assumptions in our current stack and a proposal for how we can evolve. As a security engineer, when I look at the PS4 Linux ecosystem through a systems-integrity lens, several structural weaknesses become apparent.
1. The "Silent" Boot Contract
The current boot chain is a hand-off between five distinct stages: kexec payload → initramfs → rootfs → init → systemd.
In a robust system, each layer has a "contract" with the next. Currently, those contracts are undocumented and frequently violated:
- []The initramfs expects
root=on the kernel cmdline; the payload fails to set it.[]moveDevexpects/newroot/devto exist; psxitarch doesn't ship it.[]Systemd expects shared libraries inld.so.conf; psxitarch leaves it unconfigured.[]The wrapper init expectseth0; the stock kernel lacks the RTL8153 driver.
Every one of my "bugs" was actually a violated assumption between layers. We need a formal Boot Contract a single-page specification defining what each layer MUST provide and MAY assume.
| Layer | Guarantees | Assumes |
|---|---|---|
| Payload | Kernel loaded, cmdline/bootargs set, VRAM allocated | GoldHEN jailbreak active |
| Initramfs | /newroot mounted RW, /dev /proc /sys exist, networking attempted | Kernel booted, USB enumerated |
| Rootfs | /sbin/init present, systemd libs in LD path, essential dirs exist | Mounted RW at / |
| Init wrapper | Standard mounts active, SSH on :22, watchdog running | Root mounted RW |
2. Failure Modes: The "Display-Only" Fallback
The deepest issue is that the ecosystem treats "no screen" as an impossible state.
- []The
musthave rootcheck drops to a rescue shell that requires a physical console.[]Systemd and GPU drivers spam errors to a framebuffer that may not exist.
Proposal: Implement a
headless=1 parameter to trigger "blind-friendly" behavior:- []Initramfs: Dump diagnostics to USB and reboot on failure rather than hanging in a dead shell.[]Network: Implement a UDP Broadcast Beacon. Every 5 seconds, broadcast
hostname|ip|stageto port 9999.
nc -lu 9999 on your PC would immediately show where the boot process is hanging. This alone would have saved me 20 hours of debugging.3. Defaulting to Zero Observability
Currently, there is no standardized way to verify if a headless PS4 has even reached the kernel. We are forced to SSH and pray or pull the USB to read logs.
Proposal: A machine-parseable Boot Telemetry File at a known location (e.g.,
/mnt/PS4LINUX/status.json). This allows each stage to log its status, IP address, and errors in a format that can be audited by pulling the drive or via a local agent.4. Lack of CI in Kernel Forks
Great work has been done on kernel forks (like noob404’s), but the lack of CI means regressions slip through easily. For example, modern GCC 13 identifies tautological NULL checks in the MT7668 driver as errors.
Proposal: Basic GitHub Actions for kernel repos. We don't need full boot testing just compile-testing against GCC 12, 13, and 14. I have already submitted the GCC 13 fixes and would be happy to provide the CI workflow PR as well.
5. Fragmented Configuration Surface
Right now, configuring a system requires touching 6+ files across 3 different filesystems (FAT32, cpio, ext4). This is a nightmare for reproducibility.
Proposal: A unified
ps4linux.conf on the FAT32 partition. The initramfs can parse this early and propagate networking, SSH, and debug settings across the rest of the stack. One file to edit, one file to back up.6. Reproducible Rootfs Builds
Distributing the rootfs as a tarball leads to "warm" configuration errors like the missing
/dev or stale ld.so.conf mentioned earlier. We shouldn't be shipping snapshots; we should be shipping build scripts. A simple mkrootfs.sh ensures that the Boot Contract is enforced at build-time, not discovered (and failed) at runtime.A Shift in Perspective
The community has done the impossible by getting Linux running on this hardware. But the current mental model assumes a user is sitting at a TV with a controller.
By adopting these SRE-style principles like contracts, observability, and reproducible builds we make the PS4 Linux experience more reliable for everyone.
