From 7ea54a84e5c627227252c3c8948ac516d62a7afa Mon Sep 17 00:00:00 2001
From: Daniel Samson <12231216+daniel-samson@users.noreply.github.com>
Date: Sun, 9 Aug 2026 17:06:13 +0100
Subject: [PATCH] file-system: mount-failure diagnostics go to the kernel ring,
 not std.log
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

V1 boundary review (4 reviewers converged): the extraction routed mount-
FAILURE logs through std.log where old fat used logging.write. That matters
precisely when the failed mount IS /system/logs — a std.log record would
then have nowhere to land. Restore the direct kernel-ring write for the
failure branch (generic prefix, since the harness is filesystem-agnostic
now); success stays std.log.info as before. Unexercised error path; fat-mount
still green. Everything substantive in the extraction verified neutral.
---
 library/kernel/file-system-harness.zig | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/library/kernel/file-system-harness.zig b/library/kernel/file-system-harness.zig
index 404795d..80d629f 100644
--- a/library/kernel/file-system-harness.zig
+++ b/library/kernel/file-system-harness.zig
@@ -307,7 +307,11 @@ pub fn Server(comptime Engine: type) type {
                 if (ok) {
                     std.log.info("mounted {s}", .{m.prefix});
                 } else {
-                    std.log.info("could not mount {s}", .{m.prefix});
+                    // The failure diagnostic goes to the kernel ring directly, not
+                    // through std.log — the mount that failed may be /system/logs
+                    // itself, and a routed record would then have nowhere to land.
+                    var line: [96]u8 = undefined;
+                    _ = logging.write(std.fmt.bufPrint(&line, "file-system: could not mount {s}\n", .{m.prefix}) catch "file-system: a mount failed\n");
                 }
             }
             mounted = true;