r1 评审 verdict=p2-3items,三条均已按评审给的修法修掉,且都补了可证伪的回归断言。 P2-1 SIGTERM 后遗留孤儿 ntpd,之后每次静默 skip 且 rc=0 - attempt() 把子进程记进全局 NTPD_CHILD 并落盘 <锁目录>/ntpd.pid; 新增 cleanup()(EXIT trap)先收尸子进程再释放锁;新增 on_signal() (INT/TERM/HUP)清理后 exit 143——旧代码的 TERM trap 只清锁、不 exit, 被杀后还会继续跑完看门狗。 - 取代原来的 "pidof ntpd 就 skip":新增 reap_or_skip_ntpd(),用 /proc/<pid>/cmdline 是否含本锁目录来区分「我们自己遗留的孤儿」(收尸) 与「别人的常驻 ntpd」(让路)。崩溃后留下的 ntpd.pid 也据此校验, pid 被复用时不会误判成外部 daemon(不会永久 skip)。 - S45 stop 不再按陈旧 pid 文件盲杀:只从 <锁目录>/<pid> 取持有者, 再核对 /proc/<pid>/cmdline 含 meow_ntpsync 才 kill。 P2-2 日志重定向失败导致 hwclock 根本不执行 - persist_rtc 改 ">/dev/null 2>>$LOG_FILE":hwclock 的 rc 与日志写入解耦。 - 新增 prepare_log():启动时在子 shell 里试写日志,不可写就整体退化 /dev/null。 必须用子 shell——`:` 是 POSIX 特殊内建,它的重定向失败会让 dash 直接 退出整个脚本(本单自测先踩到了,rc=2)。 P2-3 锁 mkdir→写 pid 有窗口,并发抑制非原子 - 锁的持有者改由 <锁目录>/<pid> 子目录自证(mkdir 原子),不再写 pid 文件; 读到空锁时给 3s 宽限而不是立刻判死。 - 清失效锁改用 mv 到 <锁目录>.stale.$$(rename 原子),并发清锁时只有 一个能成功,避免「抢锁失败方删掉胜方的锁」。 - 退出只删自己的锁:没有自己的 <pid> 子目录就不动锁目录。 验证 - 新增回归断言 11-16(run_tests.sh):SIGTERM 收尸/锁释放、遗留孤儿收尸、 日志不可写仍写 RTC、锁被占用不抢、死锁可接管、pid 复用不阻断。 - 可证伪性:新套件跑旧代码(c9f0cba 的 meow_ntpsync)→ 6 条 FAIL (孤儿 alive、日志不可写 rc=1 且 hwclock 未执行、抢锁并发调 ntpd×3)。 再跑「仅回退 STALE_NTPD 硬化」的变体 → pid 复用那条 FAIL (rc=0 但 RTC 未写,正是评审指出的静默失效)。 - dash 与 busybox ash 各 41/41 PASS,rc=0;dash -n / busybox sh -n 均 0 错。 - 时间断言放宽为负载容忍(宿主是多 agent 共享机,实测 sleep 5 能跑成 85s), 假 ntpd 改为挂 3600s,保证上界仍能证明是看门狗掐断而非自然退出。 fw_content.conf: meow_ntpsync md5 ad324e3f→f3c3abe4, S45meow_ntpsync md5 25454a3f→115e7592(50meow_ntpsync 未改,md5 不变)。
MeowOS 固件打包脚本使用说明(scripts/build/)
本目录是 MeowOS 固件打包的唯一入口。核心思想:只改配置文件,不改脚本。 新增/更新固件内容 → 改
fw_content.conf;打包 → 跑build_fw_apps.sh。 本文档防遗忘,覆盖常见场景与踩坑记录。
1. 文件一览
| 文件 | 作用 |
|---|---|
build_fw_apps.sh |
通用打包脚本(配置驱动)。读清单 → 组树 → repack → 校验 → 出固件。不要改它的逻辑,除非打包流程本身要变。 |
fw_content.conf |
固件内容清单(默认配置)。每行一条 ` |
README.md |
本说明。 |
曾有一批独立脚本
build_fw_apps_m2xx.sh(每版复制一个、内部硬编码 md5),已清理删除,不再使用。它们的问题:需每版改脚本、且共享fw_apps/目录互相清空。现统一走"一个通用脚本 + 一个配置文件"。
2. 用法
cd /home/Aska/Project/R3ProII
# 用默认配置打包,版本号 0.7.68,输出 r3proii_m2_73.upt
bash scripts/build/build_fw_apps.sh -v 0.7.68 -o r3proii_m2_73.upt
# 用指定配置(并存多套调试/场景配置时)
bash scripts/build/build_fw_apps.sh -c scripts/build/fw_content.conf -v 0.7.68 -o r3proii_m2_73.upt
# 指定基线目录(默认 fw_ssh/squashfs-root)
bash scripts/build/build_fw_apps.sh -v 0.7.68 -o r3proii_m2_73.upt -b fw_ssh/squashfs-root
参数
| 参数 | 必填 | 说明 |
|---|---|---|
-c, --config |
否 | 清单路径,默认 scripts/build/fw_content.conf。传别的路径即用另一套配置(互不覆盖)。 |
-v, --version |
是 | 版本号(如 0.7.68),写入固件 /etc/meowos_version。 |
-o, --out |
是 | 输出 .upt 路径(如 r3proii_m2_73.upt)。若指向仓库内 fw_apps/ 下(非 out/),自动并入 fw_apps/out/ 归档。 |
-b, --base |
否 | 基线根文件系统目录,默认 fw_ssh/squashfs-root。 |
产物去哪
- 工作区(每次清理重建):
fw_apps/build/—— 组装 squashfs-root 树,用后即弃。 - 产物归档(不受清理影响):
fw_apps/out/—— 打包好的.upt固定放这,多次打包互不覆盖、不会误删。
重要:
-o给相对路径时按"文件命名"即可(如-o r3proii_m2_73.upt),脚本会自动归档到fw_apps/out/r3proii_m2_73.upt。
3. 修改固件内容(只改配置)
固件里加/换一个组件,只需在 fw_content.conf 加/改一行:
<src>|<dst>|<md5>|<desc>
<src>:仓库内相对路径(相对项目根ROOT),如patch_v2/meow_launcherd/meow_launcherd。<dst>:目标绝对路径(装入固件),如/usr/bin/meow_launcherd或/etc/init.d/S90meow_bootmenu。<md5>:可空 = 不校验;填了 = 打包前对<src>做强校验,不一致即exit 1(防呆:源被改/路径错)。改了源码后要更新这里的 md5(md5sum <src>)。<desc>:注释说明(可省略,出现会保留)。
规则:
#开头为注释,空行忽略。- 目标目录自动创建;每条条目装入后一律
chmod 755(usr/bin/etc/init.d/etc/profile.d之外同理,例如 udhcpc 钩子usr/share/udhcpc/default.script.d/*必须可执行才会被调用)。 - 多重配置并存:复制
fw_content.conf改名,用-c指定,互不干扰。
覆盖基线已有文件(清单 <dst> 与基线同名)
清单条目对目标目录是无条件 cp -f 覆盖:不校验基线原文件的 md5、也不跳过「已存在」的文件,只要
<dst> 命中就行。脚本里唯一的基线校验是第 2 步的 usr/bin/hiby_player(stock a73f2c49…),与清单条目无关。
因此覆盖类条目要自己在 <desc> 里写清「覆盖基线 xxx(基线 md5 …)」,便于复盘对照基线。例(M21 开机亮度链):
patch_v2/bootmenu/S11jpeg_display_shell|/etc/init.d/S11jpeg_display_shell|<md5>|覆盖基线 S11(基线 md5 249220f2…)…
patch_v2/bootmenu/S22brightness|/etc/init.d/S22brightness|<md5>|新增:…(S21mount_ubifs 之后按用户设置恢复背光)
覆盖基线 init 脚本时,顺序仍由文件名决定(
rcS按/etc/init.d/S??*自然序执行),不能靠清单顺序。
常见:更新某个二进制后改 md5
md5sum patch_v2/meow_launcherd/meow_launcherd
# → 9ca4c5e8a919f59cb2cdd6326da23065
把 fw_content.conf 里对应行 md5 替换成新值即可。
4. 打包流程做了哪些事(通用步骤)
脚本读清单之外,还会自动做这些固定动作(无需在清单里声明):
- 建树:复制基线
$BASE→fw_apps/build/squashfs-root。 - 校验基线:
usr/bin/hiby_player必须是 stock(md5a73f2c49…),否则中止(防 stock 被改坏)。 - 解析清单:逐条(md5 若有则强校验)→
cp -f→chmod 755,目录自动建。 - 写版本:
echo $VERSION > $DST/etc/meowos_version(单点版本号来源)。 - 外围 CLI 瘦身:从
/usr/bin移除白名单工具(curl socat tmux jq rsync nano htop ncdu file xxd——已迁 TF 卡MeowOS/opt/bin/)。 - 启动图/背包/关机 logo:从
bootlogos/拷logo_new→logo.jpeg、logo1_new→logo1、logo2_new→logo2、boot_anim_0.png→etc/boot_animation/0.png、shutdown_logo.jpeg→etc/。 S99ssh→S84ssh:改名(内容不变),校验一致后删S99ssh(清单不含 S84)。- repack:
hiby_os_crack/scripts/repack.sh -i $DST -k unpacked_v14/xImage -o $OUT。 - 体积核对:rootfs 分区 ≤ 45,088,768 字节,超限中止。
- unpack 回验:把打包产物解回到官方 squashfs,与
$DST比对 0 diff,发现差异即中止并打印 diff。
清单里不要加的东西(通用步骤已处理)
/etc/meowos_version(由-v写入)/etc/logo*、/etc/boot_animation/0.png、/etc/shutdown_logo.jpeg(由 bootlogos/ 拷贝)/etc/init.d/S84ssh(由基线S99ssh改名而来)usr/bin外围 CLI 瘦身(按白名单移除)
易混淆:
/etc/shutdown_logo.jpeg是图片(通用步骤从bootlogos/shutdown_logo.jpeg拷);/etc/init.d/S95shutdown_logo是启动/停止脚本(清单里单独一条S95shutdown_logo,负责关机时显示该图)。二者不同,别混。
5. 踩坑记录(重要)
- 脚本共享目录互相清空:早期每个版本一个脚本、都
rm -rf fw_apps,并行跑会删掉彼此的.upt产物。→ 已改为fw_apps/build/(工作区)+fw_apps/out/(归档)分离,且删光独立脚本。 - 改源码忘更新 md5:清单里 md5 是强校验,源变了但 md5 没改 → 打包直接失败。凡是动了清单里列的源文件,先
md5sum更新对应行。 - SDK 库(
meow_ui.a)不入固件:它由 APP(如 hello)链接,走 TF 卡MeowAPPs/热更新,不要加进清单。 fw_apps/被 gitignore:固件产物与组装树都是构建产物,勿提交。scripts/build/根目录 gitignore:构建产物与组装树勿提交。但本目录的README.md/build_fw_apps.sh/fw_content.conf已git add -f入库(这三个是仓库侧应保留的脚本/配置/说明);其余(fw_apps/产物等)不入库。
6. 每次打固件的最小步骤
# 1. 确认要进的组件 md5 无变化(若改了源码先更新 fw_content.conf)
md5sum patch_v2/meow_launcherd/meow_launcherd patch_v2/meow_svc_power/meow_svc_power
# 2. 打包(版本号 + 输出名)
bash scripts/build/build_fw_apps.sh -v 0.7.68 -o r3proii_m2_73.upt
# 3. 看结果:0 diff、体积 ≤ 上限、最终固件 md5
# 产物在 fw_apps/out/r3proii_m2_73.upt
# 4. 推卡升级:scp 到设备卡根 /usr/data/mnt/sd_0/r3proii.upt(先备份当前为 prevNx)
7. 相关权威文档
- 固件/升级细节:
docs/MEOWOS_SPEC_REF.md(版本单点/etc/meowos_version、rootfs 上限 45088768、mtd 分区、升级=写 mtd5)。 - 组件来源:
patch_v2/(launcher/bootmenu/svcd/sysui/mdns/nyai/svc_power/svc_perf 等)。 - 专项服务/电源 CLI:
devdocs/plan/SYSTEM_FRAMEWORK_SERVICES.md。