lightmem记忆系统实战存取.小浣熊一句话:从lightmem记忆中，取出FreeBSD linux仿真环境安装启动workbuddy的信息，整理成文档

skywalk81632026-11-02 12:31

直接让小浣熊到lightmem去找

从lightmem记忆中，取出FreeBSD linux仿真环境安装启动workbuddy的信息，整理成文档

小浣熊从lightmem找到的

关键发现：lightmem 里 没有 这条信息

我先说结论中最重要的部分，以免你被一份"看起来完整"的文档误导。

我对 lightmem 做了全量枚举 （并非只靠关键词命中）：语义召回、GDPR 导出三个作用域（dshteam/dsh-agent 91 条、dshteam/skywalk 28 条、dsh/dsh-agent 11 条）去重后共 130 条 。其中提到 workbuddy 的仅 8 条，全部属于三类无关内容：

  • WorkBuddy 作为 MCP 客户端接入 lightmem（001a149e...、001a149f...、001a152a...）
  • hive 中按 manual 模式登记为 GUI agent
  • SSH 用户名恰好叫 workbuddy（这点干扰最强，两条"workbuddy"命中其实是用户名）

没有一条 涉及 deb 安装、/opt/WorkBuddy 路径、--no-sandbox、X cookie、fcitx5 或桌面图标。

因此文档按证据等级分层

真正完整的安装与启动过程在本机证据里，我逐项实测核对后补齐：

证据 内容
apt/dpkg 日志 2026-10-22 14:39 使用 apt install -f，安装 5.6.2，14:48 配置完成，依赖膨胀约 1.8 GB
进程现场 pid 70110 已运行 9 天 5 小时 ，当前链路为 chroot → su → ime-run → 二进制
环境变量实测 从 /proc/70110/environ 确认 DISPLAY=:0、GTK_IM_MODULE=fcitx5、私有 bus
脚本 workbuddy-chroot、workbuddy-desktop、ime-run 原文

文档里每条都标了【记忆】【实测】【文档】，可回查。

两点值得你注意的核对结果

  1. 进程现场与脚本不一致 ：实际命令行多了一个 WB_SANDBOX_BACKEND=bwrap，而 ~/work/workbuddy-chroot 里没有。我在文中标注了"以进程现场为准"，脚本属于较早版本。
  2. 宿主侧启动器位置存疑 ：/usr/local/bin/workbuddy-desktop 和 workbuddy-chroot 在 chroot 内看不到（chroot 有自己的 /usr/local/bin），能确认的副本只在 ~/work/。而 /usr/share/applications/workbuddy.desktop 是包自带 那份（Exec=/opt/WorkBuddy/workbuddy %U），只在 chroot 内有效。两者别混为一谈。

另外，唯一与 linuxulator chroot 相关的记忆 001a18c6... 讲的是小浣熊而非 WorkBuddy；但它的"包装脚本硬编码安装路径导致升级后图标全挂"自愈方案对 WorkBuddy 完全适用，我把它单列进"可复用相邻记忆"。

文档位置：WorkBuddy-FreeBSD-linux仿真环境-安装与启动.md（工作目录下）。

如果要把这份知识回写进 lightmem 补齐缺口，我可以按现有 push_lightmem.py 的幂等键格式整理条目。

以下为文档:/home/skywalk/dswork/WorkBuddy-FreeBSD-linux仿真环境-安装与启动.md

WorkBuddy 在 FreeBSD Linux 仿真环境中的安装与启动

整理时间：2026-11-01

数据来源：lightmem 记忆库（本机 fb98 上的 lightmem-kernel :18443）+ 本机实测核对

目标机器：fb98（FreeBSD 15.1-RELEASE-p1 宿主 + Linuxulator chroot /compat/ubuntu）

摘要（结论先行）

  1. lightmem 里没有一条"在 FreeBSD linux 仿真环境安装 / 启动 WorkBuddy"的完整记忆。
    对该库可及范围内 130 条记忆做了全量枚举 （不是只靠关键词命中），其中提到 workbuddy 的仅 8 条，全部属于
    "接入 lightmem / 登记为 hive agent / 用户名恰好叫 workbuddy"三类，没有一条 涉及 deb 安装、/opt/WorkBuddy 路径、
    --no-sandbox、X cookie、fcitx5 或桌面图标。
  2. 真正完整的过程记录在 lightmem 之外的现实证据 里：本机实战文档 ~/work/workbuddy-csdn.md、
    启动脚本 ~/work/workbuddy-chroot、~/work/workbuddy-desktop、chroot 内 /usr/local/bin/ime-run、
    apt/dpkg 安装日志，以及 正在运行的进程现场。
  3. 因此本文档按 证据等级分层撰写：
标记 含义
【记忆】 lightmem 中的原始记忆，附 memory_id 与写入时间，可直接回查
【实测】 2026-11-01 在本机直接核验（命令输出 / 进程 / 文件 / 日志）
【文档】 来自本机既有实战文档与脚本，与【实测】互相印证
  1. 环境形态一句话 ：内核是真 FreeBSD，用户态是真 Ubuntu 22.04.5；WorkBuddy 是真 Linux ELF ，跑在 Linux
    ABI 兼容层上，而桌面、X server、宿主输入法都在 FreeBSD 侧------所有"装好了但用不了"的问题都出在这条边界上。

一、lightmem 中的原始记录（逐条）

1.1 检索方法与覆盖范围

为避免"关键词没命中就断言没有"的误判，采用三条互补路径：

复制代码 
# ① 语义召回（返回结构在 recalled[].candidates[].memory.fact）
python3 recall_lightmem.py "workbuddy 安装 启动" 30

# ② 全作用域导出后本地全文过滤（GDPR export，绕开语义召回偏差）
POST /api/v1/gdpr/export  {"tenant_id":"dshteam","user_id":"dsh-agent"}   → 91 条
POST /api/v1/gdpr/export  {"tenant_id":"dshteam","user_id":"skywalk"}     → 28 条
POST /api/v1/gdpr/export  {"tenant_id":"dsh","user_id":"dsh-agent"}       → 11 条

# ③ 全文检索端点复核
GET /search?q=workbuddy&tenant_id=dshteam

合计 130 条去重记忆。命中的 8 条如下。

1.2 命中条目（全部与"接入"有关，与"安装/启动"无关）

# memory_id 写入时间 写入方 内容要点
1 001a149e0d6d5e232fa1b019aed93 2026-10-17 20:40 agent=workbuddy R21 逐家接入实证：WorkBuddy（agent_id=workbuddy）经自身通道写入共享记忆大脑
2 001a149fc6cee95c81a7dae39e4bf 2026-10-17 21:10 agent=workbuddy 同上（半小时后复验一次，两条内容一致）
3 001a152a07d961319a19e41e454aa 2026-10-19 13:26 deepseek-harness 接入状态盘点：4 个客户端连上 :18444，其中 ③WorkBuddyAI ；判据是 13 个 MCP 工具可用 + save→recall 闭环 + netstat 见 ESTABLISHED
4 hive-agent-register-20261026 2026-10-27 23:57 hive-mcp-session hive agent 登记现状，列出 workbuddy、workbuddyai-win 等 agent
5 001a180394b943b0de1fbcae8f1b3 2026-10-28 09:56 trae fb98 SSH 用户名是 workbuddy（与 WorkBuddy 应用同名，属同名误报）
6 001a1520e5595a7664a529810a7c7 2026-10-19 10:47 deepseek-harness token 表 /usr/local/lightmem/agent-tokens.json 属主为 workbuddy（同样是用户名）
7 001a1485d68091d2219a31e2b62ef 2026-10-17 13:37 deepseek-harness R21 计划：为 lightmem 内建 MCP，接入含 WorkBuddy 在内的全部 AI Agent
8 001a1486db8262dcaf6faecf12906 2026-10-17 13:55 deepseek-harness R21 E 线：su -m workbuddy 编译（用户名，非应用）

1.3 唯一涉及 linuxulator chroot 的记忆，讲的是小浣熊而非 WorkBuddy

memory_id 时间 内容要点
001a18c583a427cc2848acc092c29 2026-10-30 18:25 小浣熊（raccoon-ai，Electron）升级后，在 FreeBSD 15.1 linuxulator chroot（/compat/ubuntu）点图标/终端都启动失败，报 /usr/local/bin/ime-run: 行 45: /opt/office-raccoon/raccoon-ai: 没有那个文件或目录；根因是新 deb 换安装目录而包装脚本仍硬编码旧路径
001a18c61902151b3f89d25224489 2026-10-30 18:36 同一问题的自愈机制上线：包装脚本改为运行时解析 readlink -f /usr/bin/raccoon-ai，并按 SingletonLock 里的 pid 清理"锁在进程亡"的残留

这两条的方法论价值高于事实价值 ：它与 WorkBuddy 同属 Electron + linuxulator chroot + 桌面图标拉起这一类问题，

其中"包装脚本硬编码安装路径""SingletonLock 残留""--no-sandbox 必须保留"三条经验对 WorkBuddy 完全适用。

1.4 明确的缺口

lightmem 中缺失下列全部内容（这些才是"安装与启动"的实体知识）：

  • deb 包版本、安装时间、apt install -f 的实际命令与依赖膨胀
  • 可执行文件真实路径 /opt/WorkBuddy/workbuddy 及其大小写陷阱
  • root/沙箱限制与 --no-sandbox
  • 宿主 .desktop → workbuddy-chroot → chroot 内二进制的三段式结构
  • X cookie（/var/run/sddm/xauth_*）同步与 DISPLAY/XAUTHORITY 显式传递
  • 无终端启动时的 fd 关闭与日志重定向
  • 中文输入（chroot 内私有 D-Bus + fcitx5）与三条失败路径

结论：这些知识当时没有回写进 lightmem，只落在本机文档、脚本和进程现场里。 下文即据此补齐。

二、环境形态（先分清"哪一侧"）

2.1 三层结构【实测】

复制代码 
FreeBSD 15.1-RELEASE-p1 宿主（fb98）
  └─ Linuxulator（Linux ABI 兼容层，不是虚拟机）
       └─ chroot /compat/ubuntu  =  Ubuntu 22.04.5 LTS 用户态
            └─ /opt/WorkBuddy/workbuddy   ← 真 Linux ELF，Electron GUI
宿主侧同时持有：Xorg :0（SDDM + XFCE）、fcitx5、D-Bus 会话

判定指纹（在内层执行）：

复制代码 
$ uname -a
Linux fb98 7.0.11 FreeBSD 15.1-RELEASE-p1 releng/15.1-n283582-... x86_64 GNU/Linux
$ cat /proc/version
Linux version 7.0.11 (des@freebsd.org) (gcc version FreeBSD Clang 19.1.7 ...) #4 ...
$ head -2 /etc/os-release
PRETTY_NAME="Ubuntu 22.04.5 LTS"

uname 报 Linux、/proc/version 的作者串却是 des@freebsd.org ------ 这就是"内核 FreeBSD + 用户态 Linux"的典型指纹。

2.2 兼容层开关【文档】

宿主侧需要（~/work/installdebian.sh 的落地逻辑，Debian/Kali 镜像安装器同款）：

复制代码 
sysrc linux_enable=YES && service linux start     # 启用 linux 内核模块 + 服务
sysctl compat.linux.emul_path="/compat/ubuntu"     # 用户态根目录
sysctl compat.linux.osrelease=7.0.11               # 关键：否则 chroot 报 "FATAL: kernel too old"

三项都要同时写进 /etc/sysctl.conf，否则重启后回退。osrelease 不设是最常见的"镜像明明解压好了却进不去"原因。

三、安装【实测 + 文档】

3.1 实际安装记录

dpkg 与 apt 日志给出了确定的时间线：

复制代码 
$ grep workbuddy /var/log/apt/history.log
Start-Date: 2026-10-22  14:39:27
Commandline: apt install -f /tmp/workbuddy.deb
Requested-By: skywalk (1001)
Install: ..., imagemagick:amd64, ghostscript:amd64, netpbm:amd64, fonts-urw-base35, poppler-data, ...
End-Date: 2026-10-22  14:48:07

$ grep workbuddy /var/log/dpkg.log
2026-10-22 14:40:51 install workbuddy:amd64 <none> 5.6.2
2026-10-22 14:48:01 status unpacked workbuddy:amd64 5.6.2
2026-10-22 14:48:03 status installed workbuddy:amd64 5.6.2

$ dpkg -l workbuddy
ii  workbuddy  5.6.2  amd64

安装耗时约 8 分钟（14:40:51 解包 → 14:48:03 配置完成），绝大部分时间花在触发器上。

判成功的标志是看到 正在处理用于 ... 的触发器 后干净回到提示符 ；出现 dpkg: 错误 / E: 才算失败。

3.2 依赖膨胀是正常的，不是装错

该包拖进 imagemagick、ghostscript、netpbm、poppler-data、fonts-urw-base35、libheif1、libaom3、

libdav1d5、libx265-199 等一整套图像/PDF 处理链，额外约 1.8 GB 。原因是它把图片与 PDF 能力内置了，

Depends 写得很重。看到这个体积不必怀疑装错包。

3.3 安装后的落点【实测】

项目 位置
主程序 /opt/WorkBuddy/workbuddy（约 200 MB，ELF x86-64）
包名 / 版本 workbuddy / 5.6.2（amd64）
内置 CLI /opt/WorkBuddy/resources/app.asar.unpacked/cli/bin/codebuddy
自带 Node 运行时 /opt/WorkBuddy/resources/runtime/node/bin/node（实测 v22.22.2）
图标 /usr/share/icons/hicolor/{16,24,128}x*/apps/workbuddy.png
包自带 desktop /usr/share/applications/workbuddy.desktop（Exec=/opt/WorkBuddy/workbuddy %U）
用户数据目录 ~/.workbuddy/（含 settings.json、sessions/、plugins/、memory/）
启动记录 ~/.workbuddy/last-launch.json：{"version":"5.6.2","build":"c7b525f3...","timestamp":"2026-10-23T05:46:11.826Z"}

四、启动：为什么"装上了"起不来

4.1 三个必踩的坑

坑 1：命令敲不出来。 包名是 workbuddy，二进制却在 /opt/WorkBuddy/workbuddy------大小写不同，且 /opt/... 不在 PATH。

复制代码 
$ workbuddy
bash: workbuddy: 未找到命令
$ dpkg -L workbuddy | grep -E '/(bin|sbin)/|\.desktop$'

坑 2：root 下 Electron 直接拒绝启动。

复制代码 
$ /opt/WorkBuddy/workbuddy
[FATAL:electron_main_delegate.cc:312] Running as root without --no-sandbox is not supported.

这是 Chromium 的沙箱限制，与包无关。补 --no-sandbox 即可；末尾的"追踪或断点陷阱"是进程吃 SIGTRAP 并 core dump 的正常收尾。

坑 3：.desktop 写在宿主侧，指向只存在于 chroot 的路径。

复制代码 
Exec=/opt/WorkBuddy/workbuddy      # ✗ 宿主没有这个路径，点了必然无反应

4.2 正确结构：两段式（宿主 → chroot）

复制代码 
FreeBSD 桌面
  └─ workbuddy.desktop        Exec=/usr/local/bin/workbuddy-desktop   ← 宿主侧
       └─ workbuddy-desktop   单实例守卫 + 日志重定向                   ← 宿主侧
            └─ workbuddy-chroot   同步 X cookie、chroot 进去、切用户      ← 宿主侧
                 └─ /opt/WorkBuddy/workbuddy --no-sandbox               ← chroot 内

三个关键点，缺一个就是黑屏或"点击无反应"：

  1. X cookie ：真正的 cookie 在 /var/run/sddm/xauth_*（600，属主 sddm），要用 sudo 读出来拷进
    chroot 内 ~/.Xauthority；X 重启/重登后 cookie 轮换，脚本每次重新同步即可。
  2. DISPLAY / XAUTHORITY 显式传入 ：su 会重置环境，不显式带就丢。
  3. 输出重定向 ：桌面点图标没有终端，子进程 fd 可能被关，Electron 往已关 fd 写日志会抛 EBADF 把进程挂死。

4.3 workbuddy-chroot（宿主侧，转 chroot）【文档】

复制代码 
#!/bin/sh
set -e
CHROOT=/compat/ubuntu
XUSER=skywalk
APP=/opt/WorkBuddy/workbuddy

SDDM_XA=$(ls -1 /var/run/sddm/xauth_* 2>/dev/null | head -n1)
[ -n "$SDDM_XA" ] || { echo "ERROR: 找不到 /var/run/sddm/xauth_*，主机 X 会话未运行" >&2; exit 1; }

sudo cp "$SDDM_XA" /tmp/sddm.xa
sudo cp /tmp/sddm.xa "$CHROOT/home/$XUSER/.Xauthority"
sudo chown "$XUSER:$XUSER" "$CHROOT/home/$XUSER/.Xauthority"
sudo chmod 600 "$CHROOT/home/$XUSER/.Xauthority"

exec sudo chroot "$CHROOT" /bin/bash -c \
  'exec su '"$XUSER"' -c "cd /home/'"$XUSER"' || exit 1; \
   DISPLAY=:0 XAUTHORITY=/home/'"$XUSER"'/.Xauthority \
   exec /usr/local/bin/ime-run '"$APP"' --no-sandbox $@"' \
  _ "$@"

细节：cd /home/$XUSER 必须写绝对路径 。写成 cd ~，~ 会先被外层 root shell 展开成 /root，

应用的工作目录与配置就全跑到 /root 去了（这是第 4 个坑）。

4.4 workbuddy-desktop（宿主侧，桌面入口）【文档】

复制代码 
#!/bin/sh
set -e
CHROOT=/compat/ubuntu
XUSER=skywalk
LOGDIR="$CHROOT/home/$XUSER/.local/share/workbuddy"
LOG="$LOGDIR/desktop-launch.log"
mkdir -p "$LOGDIR"

# 单实例守卫：必须 ^ 锚定行首，否则 grep 会匹配到自己的命令行参数
if ps -axo args= | grep -qE '^/opt/WorkBuddy/workbuddy --no-sandbox'; then
    echo "$(date '+%F %T') already running, skip" >>"$LOG"
    exit 0
fi

echo "=== $(date '+%F %T') launching workbuddy ===" >>"$LOG"
exec /usr/local/bin/workbuddy-chroot >>"$LOG" 2>&1

ps | grep 自匹配 是这里最隐蔽的坑：不加 ^ 时，grep 自己的命令行就含目标字符串，于是日志永远只有

already running, skip，看起来像"应用起不来"，实际是守卫把自己拦住了。日志里 2026-10-23 09:39--09:41 连续三条

already running, skip 正是这个阶段的现场。

4.5 当前实际运行的进程链【实测 2026-11-01】

复制代码 
$ ps -axo pid,etime,args= | grep '/opt/WorkBuddy/workbuddy'
70088  9-05:44:33  sudo chroot /compat/ubuntu /bin/bash -c exec su skywalk -c "cd /home/skywalk || exit 1;
                   DISPLAY=:0 XAUTHORITY=/home/skywalk/.Xauthority WB_SANDBOX_BACKEND=bwrap
                   exec /usr/local/bin/ime-run /opt/WorkBuddy/workbuddy --no-sandbox $@" _
70107  9-05:44:33  su skywalk -c cd /home/skywalk || exit 1; DISPLAY=:0 XAUTHORITY=/home/skywalk/.Xauthority
                   WB_SANDBOX_BACKEND=bwrap exec /usr/local/bin/ime-run /opt/WorkBuddy/workbuddy --no-sandbox
70110  9-05:44:33  /opt/WorkBuddy/workbuddy --no-sandbox

主实例已稳定运行 9 天 5 小时 （对应 last-launch.json 的 2026-10-23T05:46:11Z）。

进程环境核对：

复制代码 
$ tr '\0' '\n' < /proc/70110/environ | grep -E 'DISPLAY|XAUTHORITY|GTK_IM_MODULE|DBUS_SESSION|LANG|WB_SANDBOX'
GTK_IM_MODULE=fcitx5
XAUTHORITY=/home/skywalk/.Xauthority
DISPLAY=:0
LANG=zh_CN.UTF-8
DBUS_SESSION_BUS_ADDRESS=unix:path=/home/skywalk/.cache/chroot-dbus
WB_SANDBOX_BACKEND=bwrap

与 4.3 脚本的一处差异：实际命令行多了 WB_SANDBOX_BACKEND=bwrap。

说明线上启动链在脚本基础上又加了一层 bwrap 沙箱后端选择；文档脚本是较早版本，以进程现场为准。

4.6 判断"真的起来了"的四个判据【实测】

复制代码 
# ① 进程在，且是主实例（不是 zygote / codebuddy 子进程）
ps -axo args= | grep -E '^/opt/WorkBuddy/workbuddy --no-sandbox'
# ② 环境变量带进去了
tr '\0' '\n' < /proc/<pid>/environ | grep -E 'DISPLAY|GTK_IM_MODULE|DBUS_SESSION'
# ③ 窗口真的在 X 上（宿主侧）
xdotool search --class workbuddy 2>/dev/null
# ④ 日志没有 EBADF / X 相关致命项
tail -40 ~/.local/share/workbuddy/desktop-launch.log

五、中文输入：为什么"怎么配都打不出来"

主机上跑着的 fcitx5，救不了 chroot 里的程序。三条路都试过，全部堵死：

路径 做法 实测结果 根因
A. 复用宿主 GTK 模块 GTK_IM_MODULE=fcitx5 指向宿主 im-fcitx5.so 加载失败 那个 .so 是 FreeBSD ELF ，Linux 进程 dlopen 不了
B. 复用宿主 D-Bus 会话 指 DBUS_SESSION_BUS_ADDRESS 到宿主 socket Failed to open connection to "session" message bus: Did not receive a reply. 连接能建，但凭据传递/对端校验跨不过 Linuxulator
C. XIM 协议桥接 xprop -root XIM_SERVERS 显示 @server=fcitx，XOpenIM 测试 XOpenIM=FAILED XIM_SERVERS 实际类型是 ATOM 而非标准要求的 STRING，libX11 取不到，等于"没有 XIM 服务器"

5.1 有效解：在 chroot 里再养一套

链路变成纯 Linux → Linux，不跨任何边界：

复制代码 
Linux 应用（GTK_IM_MODULE=fcitx5）
   └─ D-Bus（unix:path=$HOME/.cache/chroot-dbus，chroot 内）
        └─ chroot 内 fcitx5（拼音、候选窗）

chroot 内已装（dpkg 实测）：fcitx5 5.0.14-1、fcitx5-chinese-addons 5.0.11-1、

fcitx5-frontend-gtk3/gtk4、fcitx5-frontend-qt5、dbus 1.12.20，装于 2026-10-22 23:44--23:46。

中文字体另有 fonts-noto-cjk（2026-07-24）、fonts-noto-cjk-extra + fonts-wqy-*（2026-10-22 23:42）。

5.2 ime-run：没有就拉起，有就复用【实测存在】

chroot 内 /usr/local/bin/ime-run（1276 字节，root:wheel 755）核心逻辑：

复制代码 
RUNDIR="${HOME:-/tmp}/.cache"
SOCK="$RUNDIR/chroot-dbus"
export DISPLAY="${DISPLAY:-:0}"
export DBUS_SESSION_BUS_ADDRESS="unix:path=$SOCK"
export GTK_IM_MODULE=fcitx5  QT_IM_MODULE=fcitx5  XMODIFIERS=@im=fcitx5
export LANG="${LANG:-zh_CN.UTF-8}"

bus_up(){ dbus-send --session --dest=org.freedesktop.DBus --type=method_call \
          / org.freedesktop.DBus.Peer.Ping >/dev/null 2>&1; }

bus_up || { rm -f "$SOCK"; nohup dbus-daemon --session --address="unix:path=$SOCK" \
            --nofork >"$RUNDIR/dbus-chroot.log" 2>&1 & sleep-and-retry; }
fcitx5-remote >/dev/null 2>&1 || { nohup fcitx5 -d >"$RUNDIR/fcitx5-chroot.log" 2>&1 & sleep 1.5; }

exec "$@"

三个值得记的细节：

  • socket 别放 /tmp ：/tmp 在宿主与 chroot 间共享，一旦某次用 root 起过，普通用户就 rm 不掉
    （Operation not permitted）。放 $HOME/.cache 一了百了。当前 socket 实测为
    ~/.cache/chroot-dbus（srwxrwxrwx，2026-10-23 05:46 创建）。
  • --nofork + nohup & 比 --fork 稳，进程不会随父 shell 退出被带走。
  • fcitx5-remote 的返回值 才是"有没有在跑"，比 pgrep 可靠------chroot 的 /proc 能看到宿主进程，
    pgrep fcitx5 会误判。

实测现场：fcitx5 主进程 pid 38770（/usr/local/bin/fcitx5）、私有 dbus-daemon pid 70115

（--address=unix:path=/home/skywalk/.cache/chroot-dbus），与 WorkBuddy 主进程同代（均 10-23 05:46 起）。

5.3 验证输入法真的通了

不看界面、直接自动化敲键：chroot 内跑一个 9 秒后打印输入框内容的 GTK 程序，宿主侧用 XTest 发

Ctrl+Space → n i h a o → Space，输出 TEXT=[你好] 即整条链路成立。

若要查某个进程是否真的加载了输入法模块：

复制代码 
APP=$(pgrep -f '/opt/WorkBuddy/workbuddy' | head -1)
sudo procstat -e "$APP" | tr ' ' '\n' | grep -E 'GTK_IM_MODULE|DBUS_SESSION_BUS_ADDRESS'
sudo procstat -v "$APP" | grep im-fcitx5     # 有 im-fcitx5.so = 模块加载成功

六、坑位速查表

# 现象 根因 修法
1 workbuddy: 未找到命令 二进制在 /opt/WorkBuddy（大小写），不在 PATH 绝对路径 / wrapper
2 Running as root without --no-sandbox Chromium 沙箱限制 加 --no-sandbox
3 点图标无反应 .desktop 在宿主侧，路径只存在于 chroot 加一层 chroot 启动器
4 工作目录变成 /root ~ 在外层 root shell 先被展开 写死 /home/$USER
5 日志永远 already running, skip `ps grep` 匹配到 grep 自己
6 无终端启动后挂死 fd 被关，electron-log 写 EBADF stdout/stderr 重定向到日志
7 中文打不出（模块法） Linux 进程加载不了 FreeBSD .so chroot 内另装 fcitx5
8 中文打不出（D-Bus 法） D-Bus 跨不过 Linuxulator chroot 内起私有 session bus
9 中文打不出（XIM 法） XIM_SERVERS 类型是 ATOM，XOpenIM 失败 放弃 XIM
10 dbus socket 删不掉 /tmp 共享，属主不一致 socket 移到 $HOME/.cache
11 升级后图标全挂 包装脚本硬编码旧安装目录 运行时解析真实路径（同 001a18c6... 小浣熊自愈方案）
12 副实例与主实例互抢 SingletonLock 残留"锁在进程亡" 按 lock 内 pid 判活后清理

第 11、12 条直接借用 lightmem 001a18c61902151b3f89d25224489 中小浣熊的自愈设计：

包装脚本用 readlink -f /usr/bin/<app> 解析 alternatives 链路 → 校验可执行且旁边有 resources/app.asar

→ 失败再扫 /opt/*/<app> → 仍失败才回退默认路径并打 WARNING；同时按 SingletonLock 里的 pid 清理残留锁。

七、当前状态核对（2026-11-01）

检查项 结果
包安装 workbuddy 5.6.2 amd64，ii 状态正常
主程序 /opt/WorkBuddy/workbuddy 可执行、约 200 MB
主实例 pid 70110，运行 9 天 5 小时，--no-sandbox + WB_SANDBOX_BACKEND=bwrap
启动链 sudo chroot → su skywalk → ime-run → 二进制，链条完整
显示 DISPLAY=:0，/tmp/.X11-unix/X0 存在，~/.Xauthority（600）就位
输入法 fcitx5 5.0.14 在跑，私有 bus ~/.cache/chroot-dbus 存在
字体 Noto CJK + 文泉驿已装
自带 Node /opt/WorkBuddy/resources/runtime/node/bin/node → v22.22.2（dsh-exec 正是用它跑 dsh-headless）

一处需注意的不一致 ：/usr/local/bin/workbuddy-desktop、/usr/local/bin/workbuddy-chroot 这两个

宿主侧 启动器在 chroot 内不可见（chroot 有自己的 /usr/local/bin），当前能确认的脚本副本在

/home/skywalk/work/（/home 为 nullfs 共享，宿主与 chroot 同路径可见）。

/usr/share/applications/workbuddy.desktop 是包自带 的那份（Exec=/opt/WorkBuddy/workbuddy %U），

它只在 chroot 内部有效；宿主桌面的自定义入口需要另行放置，验证时不要把这两者混为一谈。

八、复现清单（从零到可用）

复制代码 
# ── 宿主侧：兼容层 ─────────────────────────────────────────
sysrc linux_enable=YES && service linux start
sysctl compat.linux.emul_path=/compat/ubuntu
sysctl compat.linux.osrelease=7.0.11
# 上述两项同时写入 /etc/sysctl.conf

# ── chroot 内：装包 ───────────────────────────────────────
apt install -f /tmp/workbuddy.deb
apt install -y fcitx5 fcitx5-chinese-addons fcitx5-frontend-gtk3 \
               fcitx5-frontend-gtk4 fcitx5-frontend-qt5 dbus
apt install -y fonts-noto-cjk fonts-wqy-zenhei fontconfig
dpkg -l workbuddy            # 期望 ii  workbuddy 5.6.2 amd64

# ── chroot 内：装 ime-run，并确认可执行 ────────────────────
sudo install -m 755 ime-run /usr/local/bin/ime-run

# ── 宿主侧：装两个启动器 + 桌面项 ─────────────────────────
sudo install -m 755 workbuddy-chroot  /usr/local/bin/workbuddy-chroot
sudo install -m 755 workbuddy-desktop /usr/local/bin/workbuddy-desktop
# workbuddy.desktop 里 Exec=/usr/local/bin/workbuddy-desktop，Icon=workbuddy

# ── 验收 ─────────────────────────────────────────────────
/usr/local/bin/workbuddy-desktop            # 桌面等价
ps -axo args= | grep -E '^/opt/WorkBuddy/workbuddy --no-sandbox'
tr '\0' '\n' < /proc/$(pgrep -f '^/opt/WorkBuddy/workbuddy' | head -1)/environ \
  | grep -E 'DISPLAY|GTK_IM_MODULE|DBUS_SESSION'
tail -40 ~/.local/share/workbuddy/desktop-launch.log

排障顺序（图标点了没反应时）：

  1. 先在终端跑 workbuddy-chroot，报错直接可见；
  2. 看日志 ~/.local/share/workbuddy/desktop-launch.log；
  3. 确认路径在 chroot 里存在 sudo chroot /compat/ubuntu ls -l /opt/WorkBuddy/workbuddy；
  4. 确认 cookie 有效 （X 重启后旧 cookie 失效，workbuddy-chroot 每次重新同步，通常自动解决）；
  5. 确认 sudo 免密 ：桌面图标没有终端，sudo 一要密码就静默失败------
    id -nG | grep wheel，并确认 sudoers 里有 %wheel ALL=(ALL) NOPASSWD: ALL 一类的免密规则。

附录 A：证据索引

证据 位置
lightmem 全量导出（130 条） dshteam/dsh-agent 91 条、dshteam/skywalk 28 条、dsh/dsh-agent 11 条
实战长文（安装/图标/输入法/通用启动器） ~/work/workbuddy-csdn.md
宿主侧 chroot 启动器 ~/work/workbuddy-chroot
宿主侧桌面启动器 ~/work/workbuddy-desktop
桌面项模板 ~/work/workbuddy.desktop
chroot 内输入法包装 /usr/local/bin/ime-run
兼容层安装器（Debian/Kali 版） ~/work/installdebian.sh
安装日志 /var/log/apt/history.log、/var/log/dpkg.log
启动日志 ~/.local/share/workbuddy/desktop-launch.log
hive 侧接法（manual 模式） ~/dswork/hive/docs/CHROOT_GUI_AGENTS.md

附录 B：lightmem 里可复用的相邻记忆

memory_id 可复用点
001a18c583a427cc2848acc092c29 Electron 应用在 linuxulator chroot 下升级后图标全挂的完整排查范式
001a18c61902151b3f89d25224489 启动路径自愈机制（readlink 解析 + SingletonLock 清理 + 启动器钩子）
001a152a07d961319a19e41e454aa "接好了"的判据：13 工具可用 + save→recall 闭环 + ESTABLISHED 连接
hive-agent-register-20261026 WorkBuddy 作为 GUI agent 的登记形态（manual，abilities 含 gui/chroot/linux）

说明：hive-agent-register-20261026 等条目在库中存有中文乱码（??），

已知根因是 Windows 端 MCP 服务端 print(json.dumps(..., ensure_ascii=False)) 受 cp936 影响的编码缺陷

（另有 001a17e2f5bda41f57c7b3ca0fa5d 记录该修复），引用时以语义为准。

相关推荐
Solange__1 小时前
在线3D预览器、Blender和游戏引擎怎么选？按5类任务比较格式、隐私与编辑性
人工智能·游戏·3d·游戏引擎·blender·1024程序员节·关卡设计
镜子AI1 小时前
镜子AI 内容方法论：GEO 到底怎么起作用，以及一份四步操作清单
人工智能·dubbo
小oo呆1 小时前
【自然语言处理与大模型】自然语言处理的漫漫长路之文本向量化
人工智能·自然语言处理
薛定谔的猫-菜鸟程序员2 小时前
从 SEO 到 GEO：生成式引擎优化的原理、证据与骗局
人工智能·seo·geo
sunshine22 girl2 小时前
copilot vscode 使用技巧
人工智能·vscode·编辑器
雨后的天空2 小时前
周末花两天手撸了一个车牌识别，CCPD 上 99%，换张手机照片就翻车了 🚗
人工智能
蒲公英eric2 小时前
元胞自动机：从森林火灾到交通流
人工智能·数学建模·元胞自动机·数学建模模型
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02历年考研数学一、数学二、数学三真题试卷及答案PDF03GitHub 镜像站点04如何新建文件夹？ 电脑新建文件夹的4种方法05几个好用的ip纯净度检测网站06苹果iPA游戏软件资源下载网站07蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接08昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战09微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新10CVE-2026-91403 高危漏洞预警：Java JSSE 信任链被攻破 全场景修复方案与Linux系统级彻底清理实操