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.
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.
- 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).
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.
This can be done using rmdir /scheme/my_scheme. Scheme implementations
do not yet exit when all fds are closed, but you can now kill the
service and restart it after you removed its scheme.
This sets PATH, LD_LIBRARY_PATH and runs init scripts for the new root.
In the future this could replace the entire set of services that should
run, restarting any services for which a newer executable is available
in the new root and stopping any services which don't exist in the new
root. This behavior could also be useful for soft-reboots in the future
to handle updates without rebooting the entire system.
Red Bear OS