ion pulls nix 0.23.1 (git), which has the Redox SaFlags_t=c_ulong bug
(relibc/libc use c_int) and fails to compile on a clean rebuild with the
`kill`/signal feature. ion was only a bundled initfs recovery shell that
nothing execs (init runs daemons then switchroots to /usr, where the
interactive login shell is brush). Per operator directive, drop ion rather
than hold nix back on an ancient pinned version for its sake.
nix 0.30.1 wrongly types Redox's sigaction SaFlags_t as c_ulong, but
relibc and the libc crate both declare sa_flags/SA_* as c_int (nix 0.31
already uses c_int for Redox). With the `kill` feature the nix signal
module is compiled and the u64-vs-i32 mismatch breaks the SaFlags
bitflags (E0308). This was latent (uutils built from cache); the relibc
epoll rebuild forced a clean recompile and surfaced it.
Patch the nix Redox branch before cookbook_cargo, with cargo fetch first
so the registry source exists before patching.
Mini now boots (q35/KVM) all the way to the getty "Red Bear login:" prompt
on VT2 with zero kernel panics. Root-cause fixes across submodules + config:
- config: 00_base.service zsh->mkdir (a full shell startup hangs an init
oneshot; the earlier 'echo/mkdir also hang' result was a silent config
override running zsh). 00_ptyd.service notify->{scheme=pty} (ptyd signals
readiness via its scheme fd; notify made init block on a byte forever).
- kernel: wrmsr_safe/rdmsr_safe #GP recovery so /scheme/sys/msr can't panic
the kernel (cpufreqd's P-state MSR write #GP'd on KVM, halting the boot
before login). base: ptyd scheme type + hwd ACPI enum -> debug (noise).
installer: warn on config [[files]] override. relibc/bootloader: prior
getrlimit + warning-demotion pointers.
- build-redbear.sh: fix host-fstools staleness (installer/redoxfs never
rebuilt on source change), prefix rebuild-every-build (touch libc.a), add
concurrent-build flock.
Submodule pointers: base 8aa8616d, installer 460d9530, kernel 155d01b1,
relibc a7663b3a, bootloader 6e119641.
Multiple fixes to make redbear-bare actually build and progress
through boot:
config/redbear-bare.toml:
- filesystem_size: 96 -> 192 MiB. The bare image packages ~153 MiB
of installed content (zsh, base, base-initfs, kernel, relibc,
userutils, libgcc, libstdcxx, plus coreutils/extrautils/etc.),
so 96 MiB triggers installer ENOSPC during commit.
- Override 31_debug_console.service with postinstall=true so the
override wins over minimal.toml's version that uses
/scheme/debug/no-preserve (which busy-loops when the debug
scheme returns ENODEV in the bare initfs).
recipes/core/base-initfs/recipe.toml:
- bare_initfs() now only references BINS in the base workspace
(init, logd, ramfs, randd, zerod, ptyd). getty is removed from
BINS because it lives in userutils, not base.
- Copy getty from the sysroot into the initfs after the cargo
build (analogous to the existing redoxfs/ion/driver-manager
sysroot copies).
- Filter the init.d copy under REDBEAR_BARE_INITFS to keep only
services for binaries we actually built (logd, randd, zerod,
runtime.target, ramfs@.service, 90_initfs.target, 50_rootfs).
The mainline 23 services reference fbcond/vesad/acpid/pcid/
fbbootlogd/hwd/inputd which aren't in the bare BINS, so
init would try to start them and busy-loop.
- Synthesize minimal 00_ptyd.service and 30_getty.service units
in the initfs since they're built/copied but not in the
mainline init.initfs.d.
- Override 00_runtime.target to add ptyd and getty as weak
requires (the mainline target references nulld/rtcd which we
filtered out).
Address 4 gaps in the new redbear-bare target per review:
Gap 1: add REDBEAR_BARE_INITFS env var to base-initfs recipe. When
set, BINS=init logd ramfs randd zerod ptyd getty instead of 22+
daemons/drivers. The bare target can now opt into the truly-minimal
initfs via the env var.
Gap 2: add ptyd and getty to the cp case-list so they go to /initfs/bin
not /initfs/lib/drivers. Without this, the getty 2 service cannot
start because ptyd (which it requires) isn't in the initfs.
Gap 3: add /etc/issue (pre-login banner) and /etc/motd (post-login
message) to the bare config. Standard Unix login surface polish.
Gap 4: trim packages in the bare config. Override ca-certificates,
pkgutils, kibi (from minimal.toml) to empty. Bare only needs:
zsh, coreutils, base, base-initfs, kernel, relibc, userutils,
libgcc, libstdcxx.
Build invocation:
REDBEAR_BARE_INITFS=1 make live CONFIG_NAME=redbear-bare
(NO AI attribution)
Comprehensive fix — not a fallback. Each recipe now has explicit
[package] section with name and version. Version inference:
- Git-source recipes without rev/branch: '0.1.0' (Red Bear convention)
- Tar/git recipes with version in URL or dir name: extracted version
- Sysroot-copy recipes: matched to toolchain version
Affected: 250+ recipes across all categories (core, libs, dev, system,
kde, qt, drivers, gpu, drm, kernel, userspace, etc.) Every recipe
in the redbear-mini build chain that was missing [package] now has
explicit version metadata. Cookbook can now always determine a version
at packaging time, eliminating 'cannot guess version' failures.
No cookbook fallback hack — the source of truth is recipe metadata.
netdb: git source with no rev/branch — added explicit version 0.1.0.
Reverted the 'guess_version -> 0.1.0' cookbook fallback — masking
missing versions is not a fix, proper recipe metadata is.
Phase 4.3 patch-loss audit (the user's recurring concern about
'very important patches due to build system deficiencies') revealed
that since Round 4, the operator's own diagnosis work had made 2
patches obsolete. Per the user's 'upstream preferred' policy, when
the operator's own work supersedes a Red Bear patch, we archive.
P0-canary (operator-superseded):
- Original: Phase 1.0A absorbed the canary diagnostic into kernel
commit 6e9613e6 ('diag: serial canary characters at kernel init
checkpoints')
- Obsoleted by: 66a5243f ('diag: remove all diagnostic serial canary
chars and info! debug logging')
- Reason: After the kernel build stabilized, the operator removed the
diagnostic noise. The canary's purpose (early-boot serial output)
is no longer needed.
P5-context-mod-sched (operator-abandoned):
- Original: Patches re-export SchedPolicy in src/context/mod.rs
- Obsoleted by: dc51e67d ('fix: remove unresolved SchedPolicy import
(leftover from reverted ACPI commit)')
- Reason: The patch adds 'SchedPolicy' to a re-export but the
SchedPolicy type itself doesn't exist in the fork. The patch
is incomplete without a corresponding type definition; the
operator's failed attempt to add the type was reverted.
Both moves follow AGENTS.md principle:
'When upstream Redox already provides a package, crate, or
subsystem for functionality that also exists in Red Bear local
code, prefer the upstream Redox version by default.'
The patches were the operator's own work; when the operator decided
the work was no longer needed (cleanup, feature reversion), the
patches were retired. 'Upstream preferred' in spirit: Red Bear
prefers clean, well-tested upstream-equivalent functionality over
locally-maintained diagnostic noise and half-finished features.
After this commit:
Active patches: 119 (was 121)
Archived: 96 in legacy-superseded-2026-07-12/
All forks: 0 orphans
Per AGENTS.md § 'Local Fork Recipe Directories Must Not Carry Patch
Files', the symlinks under recipes/core/{base,kernel,relibc,
bootloader,installer}/ pointing at the canonical local/patches/<comp>/
patches were violations. The recipes use path = '...' source so the
cookbook would never apply these patches; the symlinks were a
navigation aid only.
This commit moves all 137 valid symlinks (and the redox.patch
counterparts) to local/docs/legacy-recipe-patches/<comp>/ with a
README explaining the rationale and pointing readers at the canonical
patch location.
The patches themselves (local/patches/<comp>/*.patch) are NOT
modified — they remain git-tracked at their canonical location.
Per AGENTS.md 'NEVER DELETE' policy the patches stay in their
canonical home; only the navigation aid symlinks are relocated.
Breakdown:
base (61) - legacy-recipe-patches/base/
kernel (26) - legacy-recipe-patches/kernel/
relibc (46) - legacy-recipe-patches/relibc/
bootloader (3) - legacy-recipe-patches/bootloader/
installer (1) - legacy-recipe-patches/installer/
After this commit, recipes/core/<comp>/.patch references all show
zero matches per AGENTS.md rule.
Phase 0 stop-the-bleeding fixes:
1. ROOT COOKBOOK VERSION DRIFT (G2)
Cargo.toml was at 0.2.5 while branch is 0.3.1. Now matches.
Added inline comment explaining the sync-versions.sh invariant
to prevent the next fork bump from re-introducing drift.
2. SILENT TODO FALLBACK (G3)
src/cook/package.rs:199 used .unwrap_or("TODO".into()) which
emitted literal "TODO" into pkgar metadata when a recipe had
no parseable version. Now fails fast with a precise error
message that names the offending recipe and suggests a fix.
Replaces silent metadata lie with actionable diagnostic.
3. CARGO.LOCK DRIFT (G1)
After 0.3.0 -> 0.3.1 fork version sync, four Cargo.lock files
were regenerated to match the new +rb0.3.1 suffix:
- root Cargo.lock
- local/sources/libredox/Cargo.lock
- local/sources/userutils/Cargo.lock
- local/sources/base/Cargo.lock (also accumulated bytemuck
and bytemuck_derive patch bumps as a side effect)
- local/sources/bootloader/Cargo.lock
- local/sources/installer/Cargo.lock
Used 'cargo generate-lockfile' per fork with their path-dep
+ [patch.crates-io] config preserved. Verified each lockfile
now contains the correct Cat 2 fork versions matching their
Cargo.toml at +rb0.3.1.
4. BOOTLOADER VERSION OVERSIGHT
local/sources/bootloader/Cargo.toml was still at
1.0.0+rb0.3.0 after sync-versions.sh --check passed for
everything else. Manual fix applied. Also regenerated its
Cargo.lock to match.
5. COLLISION DETECTION HONESTY (G9)
AGENTS.md and local/AGENTS.md claimed a CollisionTracker
module existed in src/cook/collision.rs and was wired
through the installer at runtime. A whole-tree search
confirmed NO such code exists anywhere. Removed the false
promises and linked to local/docs/COLLISION-DETECTION-STATUS.md
which documents the actual current state (lint-config-only
init-service detection works; general package-vs-config
detection does NOT).
Verified:
- bash -n on all touched scripts: clean
- cargo check --bin repo: clean (redbear_cookbook v0.3.1 now)
- sync-versions.sh --check: clean (75 Cat 1 + 10 Cat 2)
- verify-fork-versions.sh: 1 pre-existing FAIL (bootloader
fork genuinely diverges from upstream tag 1.0.0 — out of
scope for Phase 0; documented for Phase 1 upgrade-forks work)
All submodules (kernel, bootloader, redoxfs, userutils, installer, base)
use path = '../libredox', '../syscall', '../redox-scheme' to reference
sibling forks. When the cookbook copies these to recipes/core/<name>/source/,
Cargo resolves the relative paths from the copy location, not the symlink
target. Added symlinks at the recipe level so all resolutions go through
the same path: recipes/core/<name>/<dep> → local/sources/<dep>.
- Add redox-scheme symlink in recipes/core/base/ to resolve path collision
when daemon workspace resolves ../redox-scheme from the recipe copy location
- Remove redundant libredox direct dep from redox-drm Cargo.toml
(arrives transitively through daemon; direct dep creates lockfile collision)
- Align redox-drm's redox-scheme path to recipes/core/base/redox-scheme
symlink to match daemon's workspace resolution path
- Fix missing ENOTTY import in relibc src/header/sys_ioctl/redox/mod.rs
Added redundant mkdir -pv "${COOKBOOK_STAGE}/usr/bin" before cp
in the base recipe's BINS install loop. The initial mkdir at line 159
creates the staging directory, but during multi-package builds the
staging area may be cleaned or the build directory context may shift.
This fixes the 'cp: cannot create regular file .../stage.tmp/usr/bin:
No such file or directory' error during base package build.
Updates the local/sources/base submodule pointer to pick up the
PIIX4 IDE BAR quirk + vgaarb logging + archiso loop_mnt, and
updates the base-initfs recipe to cross-compile loop_mnt before
the redox-initfs-ar archive step.
See local/sources/base commit 2055dcd for the individual
changes.
After cooking relibc, copy the freshly built libc.a and libc.so to both
the prefix toolchain and the redoxer toolchain (the latter is what
'make live' actually consumes for cross-recipe builds).
Without this, recipes that link against the dynamic libc.so see a stale
copy (no eventfd, no __fseterr, ...) and fail with 'undefined reference'
at link time. 'make prefix' does this sync via its sysroot rule, but
'make r.relibc' alone does not — covering both paths prevents the
first recipe that needs a new symbol from breaking the build.
- recipes/dev/python312/recipe.toml: use COOKBOOK_TOOLCHAIN for
--with-build-python instead of /tmp/python312, which the build system
never stages. Add [ -x ] guard for clear failure on missing dev-dep.
- recipes/core/userutils/recipe.toml: switch from upstream git URL to
local fork (local/sources/userutils/) per the local fork model. The
upstream source opens /scheme/pty/ptmx which the ptyd scheme does not
recognize; the local fork opens /scheme/pty correctly and avoids the
getty PTY panic.
- local/scripts/build-preflight.sh: warn when a recipe build script
references /tmp/<known-package>/, since the cookbook does not stage
host dev-deps under /tmp/<name>. Points authors at COOKBOOK_TOOLCHAIN.
- local/scripts/build-redbear.sh: replace 'tail -1 || true' on pre-cook
failures with proper error capture, last-50-lines tail on failure, and
exit-1. Verify the pkgar exists after a successful cook.
- Add x11proto to redbear-full.toml package list
- libxau recipe updated with x11proto dependency and custom build script
- Fixes libxau build failure: 'Package xproto was not found'
The old patch symlinks (P0-*.patch through P17-*.patch, redox.patch,
redbear-consolidated.patch) were leftover from the git+patches model.
With path = "../../../local/sources/kernel", the cookbook creates a
symlink to the local fork and does NOT apply any patches. The patches
are preserved in local/patches/kernel/ for reference only.
Use local/sources/kernel/ as path source instead of git+patches.
The fork is synced to upstream b93260ed and has all Red Bear changes
squash-merged. Old patches preserved in local/patches/kernel/ for
reference only.
Author: vasilito <adminpupkin@gmail.com>
Use local/sources/installer/ as path source instead of git+patch.
The fork is synced to upstream 142b2d6. The ext4/GRUB patch will
be re-applied to the fork as a follow-up.
Author: vasilito <adminpupkin@gmail.com>
After several rounds of patch alignment issues with the overlay-patches
approach, switching to the local Red Bear base fork. The local fork is
the durable source of truth (already at d0ca0d5f with 14 unused-var
fixes). Future work will import upstream redox-os/base commits into the
fork and re-apply any necessary Red Bear deltas as patches on top.
This matches the existing pattern: kernel and relibc are also built
from local forks (local/sources/kernel, local/sources/relibc).
The old overlay patches in local/patches/base/ are preserved for
reference and will be re-applied to the fork during the next
synchronization pass.
The P0-redox-ioctl-syscall-0.8.1.patch only bumped the redox-ioctl
sub-crate's pin. The relibc main workspace still pinned
redox_syscall = 0.7.4, causing relibc itself to fail to compile
with redox-rt errors when the path-override in base pulled in
the now-0.8.1 redox-ioctl.
Bump the relibc workspace's redox_syscall to 0.8.1 to match.
The previous P0-redox-ioctl-syscall-0.8.1.patch on relibc was useless
because base uses `redox-ioctl = { git = ... relibc.git }` which
bypasses the relibc recipe's local source.
Add a [patch] override in base/Cargo.toml to use the local relibc
source's redox-ioctl instead, which has the syscall 0.8.1 pin.
Base build was failing with:
error[E0277]: `?` couldn't convert the error to `syscall::error::Error`
--> drivers/graphics/driver-graphics/src/lib.rs
because relibc's redox-ioctl sub-crate pins `redox_syscall = "0.7"`
which uses one syscall::Error type, but the rest of the build
(redox-scheme 0.11.1, base workspace redox_syscall 0.8.1) uses
another. Two versions of the same type can't unify across crate
boundaries.
Bump the pin in relibc/redox-ioctl/Cargo.toml to 0.8.1 to match.
The previous daemon patches (P0-daemon-init-notify-graceful, P0-daemon-fix-init-notify-unwrap,
P0-daemon-silence-init-notify) were conflicting with each other and with
the upstream daemon code. The result was either:
1. get_fd returns RawFd (-1) but Daemon.write_pipe is Option<PipeWriter>
(from P0-daemon-init-notify-graceful) — broken
2. get_fd returns Option<RawFd> but Daemon::new uses io::PipeWriter::from_raw_fd
(no .map()) — broken
This single comprehensive patch applies all needed changes atomically:
- get_fd returns Option<RawFd> with full error handling
- Daemon.write_pipe: Option<PipeWriter>
- Daemon::new uses .map(|fd| unsafe { from_raw_fd(fd) })
- Daemon::ready handles Option
- SchemeDaemon.write_pipe: Option<PipeWriter>
- SchemeDaemon::new uses same closure pattern
- ready_with_fd handles Option
Replaces: P0-daemon-init-notify-graceful, P0-daemon-fix-init-notify-unwrap,
P0-daemon-silence-init-notify
The previous commit (d86bcb24a) added this patch which assumed a
different state of daemon/src/lib.rs than what P0-daemon-fix-init-notify-unwrap.patch
produces. The original P0-daemon-fix-init-notify-unwrap.patch ALREADY
fixes the same lines using a proper closure:
unsafe { get_fd("INIT_NOTIFY").map(|fd| io::PipeWriter::from_raw_fd(fd)) }
vs my (broken) version:
unsafe { get_fd("INIT_NOTIFY").map(io::PipeWriter::from_raw_fd) }
The original uses a closure which makes the unsafe call syntactically
valid. My version passes the function directly which Rust 2024 rejects
because from_raw_fd is unsafe fn.
Removing the redundant patch and relying on P0-daemon-fix-init-notify-unwrap
which is already in the recipe.
Earlier we over-included workspace patches. After closer inspection:
- Upstream Cargo.toml ALREADY has `exclude = ["bootstrap"]` at the end
of the workspace members list (line 72). No need to add another.
- Upstream bootstrap/Cargo.toml ALREADY has `[workspace]` declaration.
No need to add another.
The only real gap was the missing driver members (i2c, gpio, intel-thc-hidd,
acpi-resource, amlserde, thermald, ucsid). The P0-add-missing-driver-members.patch
fixes that alone.
Removed the redundant P0-bootstrap-workspace-{fix,exclude,standalone} patches.
The base build was failing with:
error: package ID specification `amd-mp2-i2cd` did not match any packages
error: package ID specification `dw-acpi-i2cd` did not match any packages
... (15+ missing drivers)
because the upstream base Cargo.toml workspace members list is missing
drivers that the recipe's BINS list tries to build (e1000d-rtl8139d
succeeded but amd-mp2-i2cd, i2c-*, gpio-*, intel-thc-hidd, ucsid, etc.
failed). Earlier Red Bear session must have had a more comprehensive
patch.
The new P0-bootstrap-workspace-exclude.patch:
- Adds `exclude = ["bootstrap"]` to the parent workspace
- Adds missing drivers to members: i2c/*, gpio/*, input/i2c-hidd,
input/intel-thc-hidd, acpi-resource, amlserde, thermald, usb/ucsid
The new P0-bootstrap-workspace-standalone.patch:
- Adds `[workspace]` to bootstrap/Cargo.toml so it can be standalone
(matches the parent workspace's exclude)
The base build was failing with:
error[E0277]: expected a `FnOnce(i32)` closure
--> daemon/src/lib.rs:67:61
error[E0308]: mismatched types
--> daemon/src/lib.rs:119:63
arguments to this function are incorrect
because P0-daemon-fix-init-notify-unwrap.patch changed `unsafe fn
get_fd(var: &str)` to return `Option<RawFd>` instead of `RawFd`,
but the upstream daemon code in SchemeDaemon::new still treated the
return value as `RawFd` (not `Option<RawFd>`).
This patch updates the SchemeDaemon code to handle the Option<RawFd>:
- Change `write_pipe` field to `Option<PipeWriter>`
- Use `.map(io::PipeWriter::from_raw_fd)` in new()
- Handle None case in ready_with_fd (return Ok early)
This matches the Daemon struct above and the Red Bear base fork at
local/sources/base.
Base build was failing with:
error[E0277]: the trait `From<libredox::error::Error>` is not implemented for `syscall::Error`
error: could not compile `scheme-utils` (lib) due to 13 previous errors
error: could not compile `daemon` (lib) due to 6 previous errors
because the workspace pinned redox-scheme 0.11.0 (libredox 0.1.12) and
redox_syscall 0.7.4. The newer libredox 0.1.16/0.1.17 has a different
Error API. Bump both to versions compatible with libredox 0.1.17:
redox-scheme 0.11.0 -> 0.11.1 (requires libredox 0.1.17)
redox_syscall 0.7.4 -> 0.8.1 (requires libredox 0.1.17)
This matches the Red Bear base fork at local/sources/base.
bison build was failing with:
undefined reference to `__fseterr\'
in function `rpl_fprintf'
in function `rpl_vfprintf'
because the relibc recipe was missing P3-stdio-fseterr.patch, which
implements `__freadahead` and `__fseterr` in src/header/stdio/ext.rs
and adds the stdio_ext.h prototypes needed by gnulib (which m4, bison,
and flex all rely on).
The patch file was already present in local/patches/relibc/ with a
symlink at recipes/core/relibc/P3-stdio-fseterr.patch, but the recipe
never listed it. Without these symbols, any gnulib-using package that
links rpl_fprintf/rpl_vfprintf fails to link.
This is the same fix that was already applied to local/sources/relibc
fork at commit f45729d4 but not mirrored into the recipe patch chain
for upstream builds.
vasilito