OS 18.0 升级避坑指南老设备能不能升装完先做这三件事【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/coreHome Assistant 的年度大版本又来了。与 Core 每月一更的节奏不同Operating SystemOS镜像的版本号独立演进而 OS 18.0 这一次把“安装速度”和“系统稳定性”放到了发布说明的核心位置——社区转载的标题直言“优化安装速度、提升系统稳定性”这也意味着大批把 HA 跑在树莓派、Odroid、x86 小主机上的老设备用户正面临一轮“升不升、怎么升、升完做什么”的抉择。但 OS 升级与 Core 升级完全是两码事它动的是整个宿主系统、Supervisor 容器编排层与附加组件Add-on的运行底座一旦升级中断或数据未备份恢复成本远高于一次普通的 Core 更新。本文不炒版本号只从代码层面拆解三件事升级前怎么自查、OS 18.0 提速改动的实际影响面、以及装完后必须验证的三项动作。一、升级前自查清单你的设备在不在官方支持名单里第一件事永远是确认机型。HA 官方 OS 镜像并非“万能刷”每套镜像都有对应的板卡定义。在当前仓库的 machine/ 目录下可以看到官方维护的全部目标平台树莓派系列raspberrypi3-64、raspberrypi4-64、raspberrypi5-64Odroid 系列odroid-c2、odroid-c4、odroid-m1、odroid-n2官方硬件green、yellow通用平台generic-x86-64、qemux86-64、qemuarm-64以及khadas-vim3注意两点。其一这份名单里已经没有老树莓派 1/2 的 32 位镜像了仍在用这类板子的用户基本不具备升级 OS 18.0 的前提继续停留在旧版本或迁移到generic-x86-64才是正路。其二generic-x86-64虽然覆盖绝大多数 x86 小主机但 OS 升级的引导boot层对固件有强依赖建议在官方论坛核对你的主板型号是否已被社区验证过而不是只看“能装就说明支持”。机型确认之后第二步是附加组件Add-on。OS 升级会重载整个 Supervisor 运行环境第三方社区仓库的附加组件往往是兼容性风险的高发区。升级前建议打开「设置 → 附加组件」把所有附加组件的更新状态跑一遍有可用的先升到最新避免“OS 大版本 老组件”的组合拳。若某个附加组件长期处于未维护状态优先在升级前移除或记录其配置而不是把赌注押在“升级后再说”。第三步是备份。这一步在 HA 的代码里是半自动化的当你通过update实体触发 OS 升级时hassio 集成会调用update_os()而该函数在请求 Supervisor 执行更新前会先走一遍备份流程async def update_os(hass: HomeAssistant, version: str | None, backup: bool) - None: Update OS. Optionally make a core backup before updating. client get_supervisor_client(hass) if backup: from .backup import backup_core_before_update # noqa: PLC0415 await backup_core_before_update(hass) ...实现见 homeassistant/components/hassio/update_helper.py。注意两点关键细节OS 升级的“自动备份”备份的是Core 与数据库backup_core_before_update()会把include_databaseTrue、include_homeassistantTrue一并打进备份包见 homeassistant/components/hassio/backup.py。但这份自动备份不包含附加组件的数据也不包含tts/、*.log、.cache等目录——备份组件的排除清单写得很明确homeassistant/components/backup/const.pyEXCLUDE_FROM_BACKUP [ **/__pycache__/*, *.log, backups/*.tar, tts/*, .cache/*, ] EXCLUDE_DATABASE_FROM_BACKUP [ home-assistant_v2.db, home-assistant_v2.db-wal, ]EXCLUDE_DATABASE_FROM_BACKUP这条尤其值得留意数据库之所以被“排除”是因为它走的是单独的并行备份通道避免复制过程中的 WAL 写坏主库不是真的不备份。但附加组件不在 Core 自动备份范围内是确定的——如果你的 Node-RED 流程、Z-Wave JS 配对数据、ESPHome 配置非常重要请在升级前用「设置 → 系统 → 备份」手动创建一个包含附加组件的完整备份并确认它落在本地或网络挂载的备份代理上。代码里备份代理Agent的注册逻辑支持本地存储与所有usagebackup的网络挂载homeassistant/components/hassio/backup.py 的async_get_backup_agents()升级前顺手看一眼「备份」页里能看到多少条历史备份、目标在哪比任何检查都实在。二、OS 18.0 的“安装提速”对老硬件意味着什么OS 18.0 的宣传点集中在安装速度与稳定性上。社区流传的说法是官方重写了部分镜像装配与首次启动流程让整盘刷写和首启初始化更快。对老设备用户这带来的实际变化要分两层看。第一层是安装介质侧提速主要发生在镜像写入与系统初始化阶段受益的是“正在装系统”的人而不是“已经在跑”的人。老设备机械硬盘的 x86 小主机、低速 SD 卡的树莓派在这个阶段提速幅度通常比 NVMe/SSD 平台更明显因为瓶颈恰恰在存储介质上。但反过来说如果你用的还是那种几十 MB 写入速度的杂牌 SD 卡提速救不了硬件升级后更要用下面的验证动作确认系统盘没有掉速。第二层是升级路径侧HA 对 OS 更新提供了细粒度的控制面。在 homeassistant/components/hassio/update.py 中OS 更新实体声明的能力是_attr_supported_features ( UpdateEntityFeature.INSTALL | UpdateEntityFeature.SPECIFIC_VERSION | UpdateEntityFeature.BACKUP | UpdateEntityFeature.RELEASE_NOTES )SPECIFIC_VERSION意味着你可以回滚到指定旧版本——这正是大版本升级的“后悔药”。策略建议很明确不要抢首发。等 18.0 发布后社区反馈稳定通常 1~2 周再在「设置 → 系统 → 更新」里选择安装若升级后发现问题利用SPECIFIC_VERSION能力把 OS 降回 17.x而不是硬扛着新版本 debug。另外提醒一个代码级事实当前 Core 主干的版本号已经是2026.11.0.dev0且要求 Python 3.14.2 起步homeassistant/const.py。OS 版本与 Core 版本虽然是两套号但 OS 18.0 对应的是一套较新的 Core/Supervisor 运行栈。老设备升级 OS 后如果发现部分集成报“依赖不满足”多半是 Core 侧运行时依赖链整体抬高了先去「系统 → 系统信息」核对运行版本再决定是回退 OS 还是升级前先把 Core 更新到位。三、装完先做这三件事升级完成、系统回到控制台先别急着把设备接回来。按照代码给出的线索按顺序做这三件事。1. 重启一次确认更新真正生效这不是废话。在 OS 更新实体的代码里写着一条明确的提示常量OS_UPDATE_REBOOT_NOTICE ( A reboot is required after install for the update to take effect. )见 homeassistant/components/hassio/update.py。OS 是宿主机镜像安装完成后新内核与系统分区未必在本次启动时加载官方 UI 也会在安装后提示需要重启。务必在 Supervisor 状态正常后执行一次彻底重启ha os reboot或 UI 中的重启重启回来后再确认「设置 → 系统」里显示的 OS 版本号已经变成 18.0。老设备用户尤其不要跳过分区切换若在异常断电时进行有概率回到旧版本引导重启后版本号没变就说明安装实际未生效。2. 验证附加组件与备份系统OS 大版本最容易踩的坑是附加组件起不来。重启后打开「设置 → 附加组件」逐项检查运行状态是否running、日志里有没有权限或内核相关报错。重点看两类一是依赖 Docker 挂载或设备直通/dev/*、USB 设备的组件内核或容器运行时的变化最容易影响它们二是社区仓库组件如前所述它们不跟随官方 QA 流程。随后回到「设置 → 系统 → 备份」确认三件事备份列表里升级时自动生成的 Core 备份存在且时间戳正确附加组件的完整备份如果你手动创建了可以正常列出恢复流程可用——备份组件同时提供了完整的 WebSocket 与 REST 接口用于触发恢复homeassistant/components/backup/websocket.py、homeassistant/components/backup/http.py并且 Supervisor 侧在恢复时会注入SUPERVISOR_RESTORE_JOB_ID环境变量以追踪任务homeassistant/components/hassio/backup.py。不需要真去恢复但“能列出、能发起恢复任务”这个验证动作能提前暴露备份损坏问题——而备份损坏是升级后才发现的话代价就大了。3. 检查 Supervisor 健康状态与修复项最后让系统自检说话。hassio 集成内置了一套问题Issue与修复Repairs机制Supervisor 上报的问题会通过get_issues_info()同步到 HA并在「设置 → 系统 → 问题」中展示带有可直接执行的修复建议homeassistant/components/hassio/repairs.py。升级后打开该页面重点看三类条目OS/内核相关警告Supervisor 对新版本运行环境的告警通常第一时间出现在这里数据盘/挂载状态备份挂载、/config所在分区是否健康弃用提示大版本升级常伴随配置项或附加组件 API 的弃用通知尽早按建议迁移避免被下一个版本强制移除。顺手在「系统 → 系统信息」里核对 Supervisor 与 Core 版本是否与 OS 18.0 配套日志页有无持续的红色错误。三条全部通过这次升级才算真正落地。小结OS 大版本升级的本质是换宿主系统风险集中在“机型支持、附加组件兼容、备份可恢复”三点。升级前对照machine/名单确认机型、把附加组件升到最新、做一份包含附加组件的完整备份理解 18.0 的提速主要惠及安装与初始化阶段老设备不必因此抢首发用好SPECIFIC_VERSION的回滚能力升级后依次完成重启验证、附加组件与备份双检查、Supervisor 修复项确认——这组动作下来无论你的设备是树莓派 4、Odroid N2 还是服役多年的 x86 小主机都能把大版本升级的风险控制在可接受范围内。【免费下载链接】core:house_with_garden: Open source home automation that puts local control and privacy first.项目地址: https://gitcode.com/GitHub_Trending/co/core创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考