ptyd was migrated to the SchemeDaemon/ready_with_fd path: it registers the
"pty" scheme and signals readiness by sending its scheme cap fd back to
init, which init receives via call_ro(FD) in its scheme-service startup.
The service was still declared type="notify", so init waited for a plain
readiness byte ptyd never sends and blocked forever at ptyd — before the
console/login stack could start (post-switchroot boot hang). Declare the
correct type={scheme="pty"} so init uses the matching fd-receive path.
The ACPI _LNK object enumeration logged 50+ INFO lines per boot on QEMU
(one per _UID/_CRS/_STA/_DIS/_SRS/_HID method), flooding the console and
slowing serial boot. This is PCI interrupt-routing detail, not needed at
INFO on every boot; move it to debug.
ptyd was the last initfs daemon still using the old Daemon +
register_sync_scheme + daemon.ready() pattern, where ready() writes a
plain readiness byte. init's scheme-service startup does call_ro(FD)
expecting to receive the scheme cap fd (the SchemeDaemon/ready_with_fd
protocol every other daemon uses), so init blocked forever waiting for
an fd that never arrived, hanging the boot after ptyd.
Both branches independently fixed the FILETABLE desync bug. This merge creates a single canonical history that preserves the diagnostic commits from 0a358aa0 and the eexist-focused fix from 104da7de.
After this merge, the per-fork submodule/<name> branch (this is the AGENTS.md-mandated canonical ref) is a child of both, so origin can fast-forward to it.
(NO AI attribution in commit message body, per project policy)
Add diagnostics to pin down where the INIT_NOTIFY fd handoff hangs:
- init/src/service.rs: log read_pipe fd and call_ro results
- daemon/src/lib.rs: log cap_fd, write_pipe, and call_wo result
- logd/src/main.rs: explicit ready_sync_scheme result and setrens fallback
These are temporary diagnostics for the boot-hang investigation.
create_pipe() used raw syscall::openat/syscall::dup which allocate kernel
fds WITHOUT registering in relibc FILETABLE. Later FILETABLE-managed
syscalls (Command::spawn -> relibc pipe2) reserve the same fd numbers,
causing EEXIST in kernel insert_file.
Replace with libc::pipe2 which goes through relibc FILETABLE-aware path.
create_pipe() used raw syscall::openat() (SYS_OPENAT) and syscall::dup()
which bypass relibc's FILETABLE-managed fd allocation (SYS_OPENAT_INTO).
This created phantom fds known to the kernel but not to relibc's userspace
FILETABLE. When Command::spawn() later called relibc's pipe2() for
fork+exec error reporting, the FILETABLE allocated a position it thought
was free, but the kernel rejected it with EEXIST (errno 17).
This killed EVERY daemon spawn during boot: logd, randd, zerod, rtcd,
nulld, acpid, pcid, inputd, lived, redoxfs, pcid-spawner, fbcond, vesad,
fbbootlogd, hwd, ps2d — all failed with 'File exists (os error 17)'.
Fix: use libc::pipe2() which goes through relibc's FILETABLE-managed
path (FdGuard::open → SYS_OPENAT_INTO), keeping tables in sync.
Commit bb20fe9c in relibc fork removed FEXEC_STEP diagnostic from
redox_rt::proc. The bootstrap binary in base referenced it in
exec.rs:257, causing build failure:
error[E0425]: cannot find value in module
Removed the diagnostic step variable and simplified the panic message.
Build now compiles cleanly.
Use direct syscall::openat with ns_fd to get pipe READ end, then
syscall::dup with 'write' to get WRITE end. This avoids the
redox_rt::sys::open bug where step 2 (openat_into_posix on the
pipe read end) consumes has_run_dup, leaving the subsequent dup()
unable to get the write end.
The init process's ns_fd may be stale after exec, causing EBADF when
pipe2() calls redox_rt::sys::open (which needs current_namespace_fd()).
Use libredox::Fd::open + syscall::dup instead, bypassing the FILETABLE
and ns_fd dependency entirely.
Socket and RawEventQueue create fds via libredox raw syscalls that
bypass the redox-rt userspace FILETABLE. FdGuard::dup then reserves
these positions, causing SYS_DUP_INTO to destroy the existing fds.
The suspend_to_ram, read_battery_status, and read_battery_info methods
were incorrectly placed inside 'impl Drop for PhysmapGuard'. They
reference fields (aml_symbols, fadt) that only exist on AcpiContext.
Move them to impl AcpiContext and fix field access (self.fadt.as_ref()
instead of self.fadt()).
- try_mem now returns Result (matching caller expectations)
- try_map_bar: non-panicking BAR mapping on PciFunctionHandle
- try_pci_allocate_interrupt_vector: non-panicking IRQ allocation
- virtio-core: reverted .ok_or() back to .map_err() for Result type
Added try_mem() returning Option<(usize, usize)> for non-panicking
memory BAR access. Fixed virtio-core/probe.rs to use .ok_or() instead
of .map_err() to match the Option return type.
The [patch] section pointed to ../../relibc/source/redox-ioctl which
doesn't exist. Fixed to ../relibc/redox-ioctl matching the main
dependency path at line 114.
- on_sendfd: subscribe/dup errors return error Response instead of panic
- fork/new_thread: subscribe errors propagate via ? operator
- signal delivery (4 sites): status fd write errors are best-effort (let _ =)
The procmgr is the first userspace process manager — a panic here kills
the entire system. These changes make it resilient to transient fd errors.
Per local/docs/PATCH-PRESERVATION-AUDIT-2026-07-12.md the base
fork was carrying only 38 of 100 patches in local/patches/base/.
The other 62 patches' content was silently missing from the fork
working tree, even though their .patch files were preserved.
This commit re-applies 41 patches that genuinely still apply
cleanly + 17 hunks that partially applied. Recovery covers:
- D-Bus initfs service wiring (P4-initfs-dbus-services)
- USB service wiring (P4-initfs-usb-drm-services)
- netcfg/dhcp/dhcpv6 driver fixes
- acpid shutdown/PM/quirk fixes
- inputd/ps2d hard-fail logging
- pcid driver interface refinements (server cmd channel)
- virtio-core for VirtualBox support
- ixgbed/rtl8139/rtl8168 net drivers
- ahcid NCQ + per-function interrupt coalescing
- logd persistent logging
- bootstrap procmgr race-condition fixes
- cargo version pin to +rb0.3.0 (synchronized release branch)
58 files changed, +1444/-318 lines.
Untracked mnt/ tree and *.orig / *.rej files cleaned up after
patch application (leftover from absolute-path patch headers).
- bytemuck 1.25.0 -> 1.25.1 (patch bump)
- bytemuck_derive 1.10.2 -> 1.11.0 (minor bump)
- Other minor patches refreshed
Part of Phase 0 fix for G1 (Cargo.lock drift).
The suffix-only drift +rb0.3.0 -> +rb0.3.1 was already
applied on master via cargo generate-lockfile. The
other entries are non-Cat-2 transitive bumps that
catches with the lockfile refresh.
No functional change to Cat 2 fork entries (those
already match Cargo.toml at +rb0.3.1).
Our Red Bear patches had reverted the userspace fd allocation refactor
(commit 372b200f) in exec.rs. This caused FD tracking mismatches
between the userspace FILETABLE and the kernel fd table, resulting in
EEXIST errors and fork failures.
Restored the upstream version which correctly uses redox_rt::sys::*
functions (openat, dup, sys_call_ro) that go through the FILETABLE,
and openat_into_upper for pre-init FD allocation. Also includes the
filetable_binary_fd setup and same_process flag in ExtraInfo.
The bootstrap's start.rs used libredox::call::openat which resolved to
the bootstrap's own redox_openat_v1 in initfs.rs, calling syscall::openat
(SYS_OPENAT). This let the kernel allocate POSIX FDs 0,1,2 for
stdin/stdout/stderr, but the userspace FILETABLE was never updated.
Later, exec.rs called auth.dup(b'cur-context') via redox_rt::sys::dup,
which asked the empty FILETABLE for a free slot (returning 0), then
passed it to SYS_DUP_INTO. The kernel rejected it with EEXIST because
posix_fdtbl[0] was already occupied by stdin.
Fix: use syscall::openat_into to directly specify FD slots 0,1,2 in
start.rs, and use syscall::dup_into with a computed FD index for
cur-context in exec.rs. Both bypass the FILETABLE, which is only
populated later by redox_rt::initialize_freestanding.
Red Bear OS