merge: pr31 — update 回滚安全(原子写 + 回读校验),解 19 处冲突

pr31 与 main 是**双向分叉**,不是单向落后。`ba281a8` 已把它的多数工作
在 main 上重新实现(dataDir 守卫、gc.go、dataDir 解析),但两边各自又
往前走了,所以 6 个文件 19 处冲突要逐条判。

## 合进来的(main 缺)

- **标记原子写**:main 是 `os.WriteFile` 直接覆写,掉电留半截标记;
  改为 `写 .tmp → fsync → close → rename → fsync 目录`
- **H4**:`publishResult` 里 `if errMsg != "" { _ = errMsg }` 把失败原因
  丢了,订阅方只看到 ok=false。现在 error 字段恒定存在
- **回读校验补最低可用性**:main 对无 digest 的旧 marker 只比"内容与备份
  一致",而**零字节备份内容也一致** ⇒ 判成回滚成功、不清 marker 的时机
  也错过了。补"非空 + 带可执行位",刻意**不**要求 `--version`
  (老内核没这个 flag,那正是 PR #31 的回归)
- `kernel_apply_test.go`(836 行,含 B2c `TestMarkPendingUpgrade_PreservesOldMarkerOnFailure`)

## 保留 main 的(pr31 在这几处是旧版或更差)

- **回滚校验用 digest**(`verifyRestored`)而不是 `--version`:
  pr31 要求回滚后能读版本,而 1.3.x 及以前没有 `--version`,
  而它们恰恰是最常见的回滚目标 ⇒ 从旧版升级失败后永久回滚不了
- **`restoreDepGraph` 三态**:原来有+备份有→还原、原来有+备份无→不算成功、
  原来无→删掉新装的。pr31 只处理第一种,会导致「旧 homed + 新 depgraph」
  的崩溃循环
- **marker 在还原完整后才清**:pr31 在还原前就清,还原失败即失去第二次自愈
- **CLI 不重启服务**:pr31 仍带 `restartUnit`,会杀掉整个 cgroup 连带 guard
- **`resolveDataDir`**:pr31 的 `upgradeDataDir` 是它的子集,多扫几个候选前缀

## 冲突处理中的三处重复声明

两边各加了同名函数,自动合并把它们都留下了:

- `readBinVersionStrict` —— 删 pr31 的(main 在 77 行有)
- `kernelDataDirMu/kernelDataDir/SetKernelDataDir/KernelDataDir` —— 删 kernel.go
  里那份(main 在 install.go)
- `newPkgRoot` —— pr31 的重命名 `newPkgRootFromBin`,两套测试各自可用
- rollback.go 里 `verifyRestored` 与 `readBinVersionStrict` 两段校验并存 —— 删后者

顺带修掉删除时误伤的 `ShortSum` 注释,并删掉 pr31 引入但无人调用的
`DataDirEnv`(main 明确不再拿 env 当 dataDir 来源)。

## 验证

    go build ./...                        ✓
    go vet ./...                          ✓
    go test ./... -count=1                62 ok / 0 fail
    go test -race ./internal/update/ ...  ✓
    gofmt -l                              干净
This commit is contained in:
JianFeeeee
2026-10-31 15:56:10 +08:00
9 changed files with 1111 additions and 106 deletions

View File

@ -54,6 +54,22 @@ func (Module) Init(ks *kernelboot.KernelState) error {
st := &upd.State{}
ks.Update = st
// ⓪ 把内核**真实**的 --data 注入 update 包。
//
// 进程内调用方(pluginmgr / webui)用 upd.KernelDataDir() 取值,
// 而不是自己推导路径。推导必错:生产是
//
// ExecStart=/usr/bin/homed --role=guard --data /var/lib/hologram
//
// 而“exe 同级 data”这种推导会得出 /usr/bin/data(只读目录,建备份必 EROFS;
// 且 pending 标记落到内核读不到的地方 ⇒ 静默不回滚)。
upd.SetKernelDataDir(ks.DataDir)
if ks.DataDir == "" {
// 不阻断启动(第 0 层职责是回滚判定,不是参数校验),
// 但必须响亮:此时任何升级都会被 Apply 的守卫拒绝。
log.Printf("[update] ks.DataDir 为空:内核升级将一律被拒绝(无回滚能力)")
}
bin := upd.KernelBinaryPath()
st.BinaryPath = bin
@ -70,6 +86,15 @@ func (Module) Init(ks *kernelboot.KernelState) error {
}
// ② 上一次升级的回滚判定
//
// ★ rerr != nil 必须中止启动:继续装配等于用一个**已知**回滚失败的
// 二进制(RollbackIfUnconfirmed 已保证只在"回滚成功且回读校验通过"时
// 返回 nil,其余失败均不清 marker)。
//
// ★ 但 marker **损坏**(掉电截断)不算失败:RollbackIfUnconfirmed
// 已经把坏 marker 改名留存并返回 (false,nil),它自己就吞掉了那种情形。
// 早前版本在这里 `if rerr != nil { return rerr }` 之前把解析错误原样
// 上抛 ⇒ 内核拒启动、且走不到回滚分支 ⇒ 既起不来也回滚不了。
rolled, from, to, rerr := upd.RollbackIfUnconfirmed(ks.DataDir, bin)
if rerr != nil {
// 回滚失败必须响亮:继续装配等于用一个已知起不来的版本