3 Commits

Author	SHA1	Message	Date
JianFeeeee	ca956f69bf	fix(update): 升级后第一次启动被误回滚（真机 OTA 实测）+ 关闭期 nil 解引用 ... ## 一、★★★ 升级永远无法生效（rollback.go） 真机跑 OTA 闭环时暴露： -apply 输出：✅ 升级完成：1.4.0dev (commit ca5b1b1) 重启后日志：ROLLED BACK kernel 1.4.0dev → 1.4.0dev（上一次升级未能确认启动） 原因：pending 标记是在**替换之前**写的（这是对的，见下），所以升级后的 **第一次启动必然看到它**。而原实现"只要标记在就回滚"，从不比对当前运行的 是哪个版本 ⇒ 每次升级都在第一次启动时被自己撤销。 正确语义（两段式确认的本意）是比对版本： 当前版本 == 标记里的 To ⇒ 新版本**已经跑起来了** ⇒ 确认、清标记、继续 当前版本 != To（或读不到） ⇒ 新版本没能成为运行版本 ⇒ 回滚到备份 标记仍然必须写在替换**之前**：反过来（替换后才写）会在"替换成功但没来得及 写标记就崩了"时丢标记，那时就不知道该回滚了。 两条判据（用真能执行 `--version` 的脚本做假二进制 —— 原来那些用例写死字节、 根本读不出版本，只覆盖了"读不到 ⇒ 回滚"这一条分支，所以抓不到本缺陷）： TestRollback_ConfirmsWhenRunningTargetVersion 跑的是 To ⇒ 不回滚 + 清标记 TestRollback_RollsBackWhenRunningOldVersion 跑的是 From ⇒ 必须回滚 ## 二、每次重启必现两条 panic（proc/host.go） [stage] tool xxx handler panic: invalid memory address or nil pointer dereference github.com/.../proc.(*unifiedRegion).generation(...) 关机/重启时 SharedRef 统一段先被拆掉，而在途的工具调用（stage handler / cleaner proxy）仍会走到 Host.Generation() ⇒ 解引用 nil。panic 虽被 recover， 但把"正常关闭"伪装成故障，并刷屏掩盖真问题。加 nil 守卫（连 h 一起判）。 ## 三、下载客户端 20s 总超时（release.go） `DownloadLatestRelease` 复用了查询用的 kernelHTTPClient（Timeout=20s， 那是**整条请求**上限，含读完 body）。而发行包近 900MB ⇒ 必然 `context deadline exceeded ... while reading body`，"从 Release 自动更新" 永久失败，且错误看起来像网络问题。 改为独立下载客户端：建连/TLS/响应头仍分层设超时（卡住能失败）， 读 body 不设总时长。	2026-10-26 14:03:05 +08:00
JianFeeeee	6dc87965ad	feat(update): support release and local package OTA sources	2026-10-26 11:16:38 +08:00
JianFeeeee	475aac867b	refactor(update): 内核与插件更新合并为 update 子系统（三端共享一个底层） ... ## 为什么合并（用户口径：更新部分应独立为子系统） 之前 kernelupgrade / pluginupdate 两个包，但它们共享三样东西， 分开写就要各复制一份，然后慢慢不一致： ① **版本比较** —— 合并前共 6 个函数做同一件事： kernel 侧 ParseSemver / CmpSemver / versionNewer / trimTagV plugin 侧 trimV / isNewer / semverNums（还自带一份正则） 且**行为不一致**：kernel 侧只挡 len<2，"1.4" 漏过去被填成 1.4.0； plugin 侧的正则要求两段所以也漏。两份都把 "1.4" 当合法版本。 ② **两阶段交互**（检查 → 确认 → 执行）—— 同一套用户口径。 ③ **失败要响亮** —— 都不静默降级。 ## 收敛结果 internal/update/ doc.go 子系统头：职责边界、三端共享契约、为何不分家 semver.go ParseSemver / CmpSemver / Newer / TrimTag（**唯一一份**） kernel.go 内核升级闭环（解包→校验→备份→替换→重启→复核→回滚） release.go GitHub Release 查询 plugin.go 插件升级（查仓库→拉源码→hmapdev 编译→产物） 三端共享： agent 工具（plugin_update / kernel_update） ┐ WebAPI（/plugins/update、/kernel/update） ├─ internal/update CLI（homed-upgrade） ┘ 入口层只做参数解析与结果呈现，不含业务逻辑 —— 否则会出现 "agent 说没有新版、WebUI 却升了级"的分裂状态。 ## 合并时抓到的两个真实 bug ① **ParseSemver 只挡 len<2** ⇒ "1.4" 被零值填成 1.4.0， 「1.4 → 1.4.0」被判完全相同（说"无需升级"），而两者内容未必相同。 现在要求恰好三段。 ② **不认 v 前缀** ⇒ GitHub release tag 全是 v1.4.0 形态， CLI 对"当前 v1.4.0 vs 包内 v1.4.0"判不可比、只能退回字符串比较。 现在 TrimTag 去 v 前缀后再比。 ## 新增入口 · plugin_update（agent 工具）+ GET/POST /plugins/update —— 两阶段：apply=false 只检查（列出 updatable / no_repo 两类， 后者是"未声明仓库、无法自动更新"的内置/私有插件）； apply=true 需显式 plugins=all 或名单（不默认全升） · kernel_update（agent 工具）+ GET/POST /kernel/update —— 两阶段同构；apply 只收本机包路径（URL 下载是 CLI 职责， agent 不该在推理中发起长下载） 判据： · internal/update: Newer / TrimTag / ParseSemver 的边界（含上述两个 bug 的回归） · pluginmgr 入口层 5 条：检查形状、apply 必须显式给范围、 kernel apply 必须给 pkg 且指向 homed-upgrade、拒绝目录当包	2026-10-26 01:05:09 +08:00