![\"Mac](\"/assets/images/posts/mac-mini-m4-cutaway.png\")
这次迁移主要做了两件事：先修复 Debian 12 上 Docker 端口映射失败的问题，再把 new-api 从 SQLite 迁移到 MySQL。过程里踩到的坑不少，尤其是 iptables/nftables 兼容性和 SQLite 到 MySQL 的语法差异。
\n\nnew-api 原本运行在 Docker 中，默认使用 SQLite 数据库。随着日志、用户和渠道数据越来越多，SQLite 数据库体积已经接近 200MB，继续放在容器数据卷里不太适合长期维护。
\n我的目标是：
\n生产迁移里最重要的一点是：不要直接停旧服务。先把新环境跑起来，确认没问题以后再切流量。
\n在 1Panel 安装 MySQL 容器时，容器可以创建成功，但启动阶段失败，错误类似：
\niptables: No chain/target/match by that name.进一步看 Docker 相关日志，可以看到 nftables 后端不兼容的问题：
\niptables v1.8.9 (nf_tables): chain `DOCKER' in table `filter' is incompatible, use 'nft' tool.Debian 12 bookworm 默认使用 iptables-nft，也就是 nftables 后端。Docker 需要维护自己的 DOCKER 链做端口映射，但当前环境下 filter 表里的链状态和 nft 后端不兼容。
这个问题有个容易误判的地方：已有容器的端口映射可能仍然正常，因为 NAT 表没有立即受影响；真正失败的是新建容器或新增端口映射。
\n先备份当前 iptables 规则：
\nmkdir -p /root/backup-iptables-$(date +%Y%m%d)\niptables-save > /root/backup-iptables-$(date +%Y%m%d)/iptables-all.txt然后把 iptables 和 ip6tables 切换到 legacy 模式：
\nupdate-alternatives --set iptables /usr/sbin/iptables-legacy\nupdate-alternatives --set ip6tables /usr/sbin/ip6tables-legacy最后重启 Docker：
\nsystemctl restart docker如果容器设置了 restart: always 或 unless-stopped，Docker 重启后容器会自动恢复。使用 host 网络模式的容器，例如 openresty，一般不受这个端口映射问题影响。
new-api 使用 GORM，首次连接 MySQL 时可以自动建表，但这不等于会自动迁移 SQLite 数据。真实迁移还需要把 SQLite dump 转成 MySQL 可导入的 SQL。
\n直接转换会遇到几类问题：
\nTEXT 字段参与主键或索引，MySQL 会报 ERROR 1170。WHERE deleted_at IS NULL，MySQL 不能直接照搬。X'...'，MySQL 的 JSON 列无法直接接受。TEXT 或 BLOB 字段设置默认值。所以这一步不能只靠简单的搜索替换，更适合写转换脚本处理结构和数据。
\n我最后使用脚本生成了一份 MySQL 可导入 SQL，主要做了这些处理：
\nTEXT 字段改成 VARCHAR(191)LONGTEXTDATETIME(6) 字面量utf8mb4_bin 排序规则，尽量保持 SQLite 的大小写敏感行为迁移时不要把真实数据库密码、root 密码和 DSN 明文写进公开文章或仓库。下面命令里的敏感字段都用占位符代替。
\n整体流程是先导入数据，再启动新容器测试，最后切换反向代理。
\n先创建目标数据库和用户，并授予权限：
\nCREATE DATABASE `one-api` CHARACTER SET utf8mb4 COLLATE utf8mb4_bin;\nCREATE USER 'one-api'@'%' IDENTIFIED BY '<mysql-user-password>';\nGRANT ALL PRIVILEGES ON `one-api`.* TO 'one-api'@'%';\nFLUSH PRIVILEGES;然后导入转换后的 SQL：
\nmysql -u one-api -p one-api < /root/one-api-mysql-importable.sql如果已经让 new-api 连接过空 MySQL，GORM 可能已经插入默认数据。这种情况下需要先清空默认数据，避免导入时出现主键或唯一键冲突。
\n新容器先监听 3001，旧容器继续监听 3000：
docker run -d --name new-api-mysql \\\n --network 1panel-network \\\n --restart unless-stopped \\\n -p 3001:3000 \\\n -e SQL_DSN=\"one-api:<mysql-user-password>@tcp(<mysql-host>:3306)/one-api?charset=utf8mb4&parseTime=True&loc=Local\" \\\n -e TZ=Asia/Shanghai \\\n -e ERROR_LOG_ENABLED=true \\\n -e BATCH_UPDATE_ENABLED=true \\\n -v /home/ubuntu/data/new-api-mysql:/app/data \\\n calciumion/new-api:latest --log-dir /app/logs这里要注意两点：
\nSQL_DSN 里建议带上 charset=utf8mb4&parseTime=True&loc=Local先用接口确认服务状态：
\ncurl http://localhost:3001/api/status正常情况下会返回 success: true。然后再检查用户、渠道、配置项、日志等核心表的数据量是否和 SQLite 对得上。
我这次迁移后的数据量大致如下：
\n| 表 | 行数 |
\n|
在 Debian 12 服务器上用 1Panel 安装 Docker 应用时，遇到过一个很典型的问题：容器可以创建成功，但启动时端口映射失败。表面看是 Docker 报错，实际原因是 iptables 后端和 Docker 链不兼容。
\n\nDocker 容器创建完成后，启动阶段报错：
\nError response from daemon: failed to set up container networking:\ndriver failed programming external connectivity on endpoint ...\nUnable to enable OPEN PORT rule:\niptables: No chain/target/match by that name. (exit status 1)这个报错容易误导人。容器本身不是不能创建，而是在 Starting 阶段设置端口映射失败。
Debian 12 bookworm 默认使用 iptables-nft，也就是 nftables 后端。Docker 会在 iptables 里维护自己的 DOCKER 链，用于 bridge 网络和端口映射。
当 filter 表中的 DOCKER 链与 nft 后端状态不兼容时，就会出现类似错误：
iptables v1.8.9 (nf_tables): chain `DOCKER' in table `filter' is incompatible, use 'nft' tool.一个关键细节是：NAT 表里的 DOCKER 链可能还是正常的，所以已有端口映射不一定会立刻坏。真正受影响的是新建容器或新增端口映射。
先看当前 iptables 使用的后端：
\nupdate-alternatives --query iptables | grep -E 'Status|Value'再检查 filter 表里的 Docker 链：
\niptables -L DOCKER -n如果这里出现 incompatible 或链不存在，再看 NAT 表状态：
iptables -t nat -L DOCKER -n最后确认当前容器和端口映射：
\ndocker ps --format 'table {{.Names}}\\t{{.Status}}\\t{{.Ports}}'如果已有容器还在正常运行，但新容器起不来，基本就可以锁定在 Docker 端口映射和 iptables 后端兼容性上。
\n修网络规则前先备份，后面出问题才有回滚依据：
\nmkdir -p /root/backup-iptables-$(date +%Y%m%d)\niptables-save > /root/backup-iptables-$(date +%Y%m%d)/iptables-all.txt\niptables-save -t nat > /root/backup-iptables-$(date +%Y%m%d)/iptables-nat.txt\ndocker ps --format '{{.Names}} {{.Image}} {{.Status}}' > /root/backup-iptables-$(date +%Y%m%d)/containers.txt把 IPv4 和 IPv6 的 iptables 都切到 legacy：
\nupdate-alternatives --set iptables /usr/sbin/iptables-legacy\nupdate-alternatives --set ip6tables /usr/sbin/ip6tables-legacysystemctl restart docker如果容器配置了 restart: always 或 unless-stopped，Docker 重启后会自动拉起。
检查 DOCKER 链是否能正常显示：
iptables -L DOCKER -n确认容器状态：
\ndocker ps检查关键端口是否监听：
\nss -tlnp | grep -E ':80 |:443 |:3000 '如果是 1Panel 里安装失败的应用，这时重新安装或重新启动应用，一般就可以恢复。
\n这次遇到问题的环境大致如下：
\n| 项目 | 值 |
\n|
使用 Systems Manager Patch Manager 扫描 Windows Server 2019 补丁时，如果 SSM Agent、网络和权限都正常，但 WindowsUpdate.log 里显示微软更新服务返回 503，根因可能在微软侧，而不是 AWS 侧。
\n\n执行 AWS-RunPatchBaseline 扫描失败，返回类似：
The find operation did not complete successfullyHResult 可能是：
\n-2145107934同一网络环境下 Windows Server 2016 正常，Windows Server 2019 失败。
\nTest-NetConnection ssm.<region>.amazonaws.com -Port 443\nTest-NetConnection ssmmessages.<region>.amazonaws.com -Port 443\nTest-NetConnection ec2messages.<region>.amazonaws.com -Port 443如果使用中国区或 VPC Endpoint，需要替换为对应域名。
\nTest-NetConnection sls.update.microsoft.com -Port 443\nTest-NetConnection download.windowsupdate.com -Port 80同时检查是否配置 WSUS：
\nGet-ItemProperty \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\" -ErrorAction SilentlyContinue\nGet-ItemProperty \"HKLM:\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate\\AU\" -ErrorAction SilentlyContinueGet-WindowsUpdateLog如果日志出现：
\nThe server returned HTTP status code '503'\nThe service is temporarily overloaded\n*FAILED* [80244022] Web service call说明 Windows Update 客户端已经连到微软服务，但服务端返回不可用。
\nWindows Server 2019 可能访问的是某个特定微软更新服务域名，例如：
\nfe3.delivery.mp.microsoft.com如果该服务端临时过载，就会返回 HTTP 503，对应错误码：
\n0x80244022同一时间 Windows Server 2016 正常，可能是因为它访问的是另一组更新服务域名，未受影响。
\n如果确认网络、SSM、WSUS 配置都正常，且错误明确是 503，最直接的方式是等待服务恢复后重试。
\n从 Microsoft Update Catalog 下载 .msu，再通过脚本或 SSM Run Command 安装：
https://www.catalog.update.microsoft.com/Patch Manager 本身不提供“只下载不安装”的标准模式。可以使用自定义 SSM 文档提前下载补丁，在维护窗口再执行安装。
\n对补丁窗口要求严格的环境，可以部署内网 WSUS，把补丁提前同步到本地服务器，降低对公网微软更新服务的依赖。
\nSSM Patch Manager 扫描失败不一定是 SSM 问题。排查时要分层：
\n如果日志已经明确 0x80244022 和 HTTP 503，通常应按微软更新服务临时不可用处理，考虑重试、手动补丁、提前缓存或 WSUS。
Windows Server 2016 安装累积更新后，如果重启阶段提示 “We couldn't complete the updates”，并反复回滚，根因不一定是磁盘空间或组件存储损坏，也可能是历史用户配置文件异常导致 per-user registry 阶段失败。
\n\n补丁安装阶段看似成功，重启时出现：
\nWe couldn't complete the updates\nUndoing changes\nDon't turn off your computer进入系统后发现 OS Build 没有提升，再次安装仍然重复回滚。
\nWindowsUpdate.log 可能出现：
\nPost-reboot status ... 0x800f0922CBS.log 中可见：
\nCBS_E_INSTALLERS_FAILED\nPer-User Registry Installer ... 0x80070002CSI 日志里还能看到历史用户 NTUSER.DAT 卸载失败。
先排除常规原因：
\nsfc /scannow\nDISM /Online /Cleanup-Image /RestoreHealth同时检查：
\n如果这些都正常，就要看 CBS/CSI 日志中是否集中出现在 Per-User Registry Installer 阶段。
\n案例中问题集中在历史用户配置文件。服务器上存在多个历史用户目录、Unknown Profile，甚至体积异常大的用户配置文件。更新在重启阶段需要加载或卸载用户注册表 hive，某些 NTUSER.DAT 无法正常卸载，导致补丁事务失败并触发回滚。
生产环境操作前先创建 AMI 或快照。用户 Profile 清理有数据风险，不能直接在生产上盲删。
\n图形界面方式：
\nsysdm.cpl。谨慎打开注册表：
\nHKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ProfileList对照 C:\\Users 目录和 ProfileList 中的 SID，清理失效项。执行前应导出注册表备份。
清理后重启，再重新安装目标累积更新。
\n如果不能立即清理 Profile，且后续月度补丁已发布，可以测试直接安装更新的累积补丁。Windows 累积更新通常包含前月安全内容，但这只能作为临时规避，根本问题仍应清理。
\nWindows 补丁重启阶段回滚时，不要只盯着 Windows Update。CBS/CSI 里如果指向 Per-User Registry Installer 和用户 hive 卸载失败，就要重点检查历史用户配置文件。
\n服务器长期多人登录后，Profile 堆积很常见。建议定期清理废弃 Profile，避免在补丁窗口才暴露问题。
\n", "date_published": "2026-05-13T00:00:00.000Z", "date_modified": "2026-06-04T13:54:51.000Z", "authors": [], "tags": [ "AWS", "Windows" ] }, { "title": "FSx ONTAP SMB 共享权限排查", "url": "https://blog.checo.cc/posts/AWS/12.html", "id": "https://blog.checo.cc/posts/AWS/12.html", "summary": "给 FSx ONTAP SMB 共享添加了 NTFS 安全权限后，用户仍然无法访问共享。这个问题的关键是：Windows SMB 最终权限是共享权限和 NTFS 权限的交集，而且 Kerberos 票据不会在用户保持登录时自动刷新组成员关系。", "content_html": "\n给 FSx ONTAP SMB 共享添加了 NTFS 安全权限后，用户仍然无法访问共享。这个问题的关键是：Windows SMB 最终权限是共享权限和 NTFS 权限的交集，而且 Kerberos 票据不会在用户保持登录时自动刷新组成员关系。
\n\n用户访问 SMB 共享路径时提示没有权限。管理员已经在“安全”选项卡里给目标域组添加了权限，但访问仍失败。
\nSMB 共享访问同时受两层权限控制：
\n最终生效权限是两者交集。只配置 NTFS 权限，不配置共享权限，用户仍可能被拒绝。
\n使用域管理员登录一台已加入域的 Windows 机器，打开：
\ncompmgmt.msc连接到 FSx SVM DNS 名称，然后进入：
\n系统工具 -> 共享文件夹 -> 共享找到目标共享，打开属性，检查“共享权限”选项卡。确认目标用户或组至少有读取权限。
\n再检查“安全”选项卡，确认文件系统权限也包含目标用户或组。
\n如果用户刚刚被加入某个域组，当前登录会话里的 Kerberos TGT 可能仍是旧组成员信息。
\n最稳妥方式是让用户完全注销后重新登录，而不是锁屏或断开 RDP。
\n也可以尝试清票：
\nklist purge但生产排障中，完整注销重登更直观可靠。
\nWindows 用户登录后会拿到包含组成员关系的 Kerberos 票据。如果管理员在用户登录期间修改组成员关系，用户现有票据不会立刻自动变成新权限。FSx 看到的仍然是旧身份信息，导致权限判断失败。
\nFSx ONTAP SMB 共享访问被拒时，建议按这个顺序查：
\n只看“安全”选项卡是不够的，这是 SMB 权限排查里最常见的误区。
\n", "date_published": "2026-04-06T00:00:00.000Z", "date_modified": "2026-06-04T13:54:51.000Z", "authors": [], "tags": [ "AWS", "Windows" ] }, { "title": "FSx for Windows 创建失败：自建 AD 的 TCP 9389 不通", "url": "https://blog.checo.cc/posts/AWS/13.html", "id": "https://blog.checo.cc/posts/AWS/13.html", "summary": "使用自建 Active Directory 创建 FSx for Windows File Server 时，如果 Single-AZ 2 或 Multi-AZ 文件系统创建失败，并且报 Get-ADComputer: Unable to contact the server，要重点检查 FSx 子网到域控 TCP 9389 的连通性。", "content_html": "\n使用自建 Active Directory 创建 FSx for Windows File Server 时，如果 Single-AZ 2 或 Multi-AZ 文件系统创建失败，并且报 Get-ADComputer: Unable to contact the server，要重点检查 FSx 子网到域控 TCP 9389 的连通性。
FSx 创建失败，后台或错误信息中出现：
\nsetupFileServerRole failed\nGet-ADComputer : Unable to contact the server.\nThis may be because this server does not exist, it is currently down,\nor it does not have the Active Directory Web Services running.这个错误通常发生在 FSx 设置文件服务器角色、加入或查询 AD 对象的阶段。
\nGet-ADComputer 依赖 Active Directory Web Services，也就是 ADWS。ADWS 默认使用：
TCP 9389对于 FSx for Windows 的 Single-AZ 2 和 Multi-AZ 类型，FSx 需要能访问域控制器的 TCP 9389。如果该端口被安全组、NACL、企业防火墙或跨区域网络策略阻断，文件系统创建会失败。
\n在与 FSx 相同子网、相同安全组的加域 EC2 Windows 实例上运行 AD 验证工具。
\nInstall-WindowsFeature RSAT-AD-PowerShell\n\nInvoke-WebRequest `\n \"https://docs.aws.amazon.com/fsx/latest/WindowsGuide/samples/AmazonFSxADValidation.zip\" `\n -OutFile \"AmazonFSxADValidation.zip\"\n\nExpand-Archive -Path \"AmazonFSxADValidation.zip\"\nImport-Module .\\AmazonFSxADValidation\n\n$Credential = Get-Credential\n$Args = @{\n DomainDNSRoot = \"example.com\"\n DnsIpAddresses = @(\"DC_IP_1\", \"DC_IP_2\")\n SubnetIds = @(\"subnet-xxxxxxxx\")\n Credential = $Credential\n}\n\n$Result = Test-FSxADConfiguration @Args\n$Result.Failures如果输出中有 TCP 9389 失败项，就能确认是 ADWS 端口连通性问题。
\nSingle-AZ 1 对 TCP 9389 的要求不同，可能在同一环境下创建成功。这可以帮助判断服务账号权限、DNS 和基础 AD 端口是否正常。
\n如果 Single-AZ 1 成功，而 Single-AZ 2 / Multi-AZ 失败，排查重点应转向 TCP 9389。
\n放行 FSx 子网到全部域控的 TCP 9389：
\n放行后重新运行验证工具，确认没有失败项，再重新创建 FSx。
\nFSx for Windows 加入自建 AD 失败时，不要只查 389、445、88 这些常见端口。对于 Single-AZ 2 和 Multi-AZ，TCP 9389 同样关键。
\n看到 Get-ADComputer 或 ADWS 相关错误时，优先验证 FSx 子网到全部 DC 的 9389 连通性。
Amazon EC2 High Availability for SQL Server 可以为符合条件的 SQL Server HA 备用节点减免许可费用。但这个减免有严格前提，尤其是备用节点不能承载活动工作负载，也不能作为可读辅助副本提供查询。
\n\n启用 SQL Server HA 许可节省前，先确认环境满足要求：
\n如果环境还是 Windows Server 2016，或集群超过两个节点，就不满足该功能前提。
\n备用节点要获得许可减免，必须保持被动：
\n核心判断很简单：只要这个节点在提供数据服务，就不再是纯 standby。
\nAlways On 可用性组里启用 Readable Secondary 后，辅助副本可以被应用、报表或人工查询访问。按许可逻辑，这已经属于活动使用，需要完整 SQL Server 授权。
\n因此，如果目标是拿 standby 节点许可减免，不应启用可读辅助副本。
\n不需要。SQL Server 支持在不可读的辅助副本上执行某些备份场景。也就是说，为了全量备份和日志备份，不必把辅助副本设置为 readable。
\n实际配置前应结合 SQL Server 版本和可用性组备份首选项验证。
\naws ssm describe-instance-information实例应显示 PingStatus: Online。
给实例配置文件附加：
\nAmazonSSMManagedInstanceCoreAWSEC2SqlHaInstancePolicy默认可以使用 NT AUTHORITY\\SYSTEM 读取 SQL Server HA 元数据。如果环境限制了该账户，则需要把 SQL Server 凭证放入 Secrets Manager，并在启用时指定。
在 EC2 控制台选择 HA 集群相关实例，进入：
\nActions -> Instance settings -> Modify SQL High Availability settings检查前置条件，通过后启用 license savings。
\n启用后应能看到：
\nActive / Full license includedStandby / WaivedSQL Server HA 备用节点许可减免不是简单开关。真正关键的是 standby 节点必须保持被动。
\n如果为了查询、报表或应用读取启用 readable secondary，就会失去减免资格。备份场景应优先使用 SQL Server 支持的辅助副本备份能力，而不是把备用节点变成可读工作负载节点。
\n", "date_published": "2026-06-03T00:00:00.000Z", "date_modified": "2026-06-04T13:54:51.000Z", "authors": [], "tags": [ "AWS", "Windows" ] }, { "title": "EC2 Windows 卸载 .NET 后 Server Manager 失效恢复", "url": "https://blog.checo.cc/posts/AWS/15.html", "id": "https://blog.checo.cc/posts/AWS/15.html", "summary": "Windows Server 上不要把 “.NET Framework 4 Features” 当成普通应用卸载。它是很多管理组件的依赖，包括 Server Manager、PowerShell 模块、IIS/WCF 相关功能。误关后可能导致 Server Manager 和 Install-WindowsFeature 一起失效。", "content_html": "\nWindows Server 上不要把 “.NET Framework 4 Features” 当成普通应用卸载。它是很多管理组件的依赖，包括 Server Manager、PowerShell 模块、IIS/WCF 相关功能。误关后可能导致 Server Manager 和 Install-WindowsFeature 一起失效。
在 Server Manager 的 “Remove Roles and Features” 中取消 .NET Framework 4 后，重启实例出现：
ServerManager 提示命令不存在。Install-WindowsFeature 报 feature 名称不存在。示例错误：
\nServerManager : The term 'ServerManager' is not recognizedWindows Server 的 Server Manager 和相关 PowerShell 模块依赖 NetFx4-OC-Package。在图形界面取消 .NET Framework 4 Features，实际会把一批依赖 NetFx4 的 OC 包一起 disable。
这和 .NET Framework 4.8 运行时版本不是一回事。注册表里仍可能显示 .NET 4.8 存在，但 Windows 可选组件层面的 NetFx4 已被关闭。
另外，NetFx3 不能替代 NetFx4。执行：
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All无法恢复依赖 .NET 4 的 Server Manager。
\n操作前建议创建 AMI 备份，所有命令以管理员身份运行。
\nDISM /Online /Enable-Feature /FeatureName:NetFx4 /AllDISM /Online /Enable-Feature /FeatureName:Server-Gui-Mgmt /Allshutdown /r /t 0重启后再验证。
\n如果业务用到 IIS、WCF、PowerShell ISE 或 DSC，可以按需启用：
\nDISM /Online /Enable-Feature /FeatureName:NetFx4Extended-ASPNET45 /All\nDISM /Online /Enable-Feature /FeatureName:WCF-HTTP-Activation45 /All\nDISM /Online /Enable-Feature /FeatureName:WCF-TCP-PortSharing45 /All\nDISM /Online /Enable-Feature /FeatureName:IIS-ASPNET45 /All\nDISM /Online /Enable-Feature /FeatureName:IIS-NetFxExtensibility45 /All\nDISM /Online /Enable-Feature /FeatureName:MicrosoftWindowsPowerShellISE /All\nDISM /Online /Enable-Feature /FeatureName:DSC-Service /AllServerManager\nGet-Command Install-WindowsFeature\nDISM /Online /Get-Features | findstr /I \"NetFx4 Server-Gui PowerShell\"为了满足 .NET 版本合规，正确方式是安装 .NET 累积更新，而不是关闭 .NET Framework 4 Features。后者不会让 .NET 从系统中“安全消失”，反而会破坏 Windows Server 管理工具链。
恢复时仅启用 NetFx4 还不够，必须同时启用 Server-Gui-Mgmt 并重启。
在 EC2 Windows 实例上启用 BitLocker 系统盘加密是可行的，但风险比物理机更高。关键问题是 EC2 通常没有传统 TPM，系统盘加密后启动阶段需要输入密码，而普通控制台未必能提供可靠输入通道。
\n\n如果直接对 C 盘启用 BitLocker 并重启，可能出现：
\n因此必须先验证 EC2 串行控制台可用。
\n在管理员 PowerShell 中执行：
\nbcdedit /ems '{current}' on\nbcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200\n\nbcdedit /set '{bootmgr}' displaybootmenu yes\nbcdedit /set '{bootmgr}' timeout 15\nbcdedit /set '{bootmgr}' bootems yes\n\nshutdown -r -t 0重启后，在 EC2 控制台通过“连接 -> EC2 串行控制台”确认可以进入启动界面。如果串行控制台不可用，不要继续加密系统盘。
\n通过 Server Manager 添加 BitLocker，或使用 PowerShell：
\nInstall-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools\nRestart-Computer运行 gpedit.msc，进入：
计算机配置 -> 管理模板 -> Windows 组件 -> BitLocker 驱动器加密 -> 操作系统驱动器启用“启动时需要附加身份验证”，并勾选“没有兼容的 TPM 时允许 BitLocker”。
\n数据盘建议先测试：
\n如果没有自动解锁，每次重启后业务可能因为数据盘锁定而不可用。
\n启用 C 盘 BitLocker，选择密码解锁，保存恢复密钥，并运行 BitLocker 系统检查。
\n重启后：
\nEC2 Windows 上做 BitLocker 的关键不是点击“启用加密”，而是启动阶段能否解锁。
\n必须做到：
\n如果只是为了云上 EBS 静态加密，优先使用 EBS encryption；BitLocker 更适合 BYOL 或特定合规场景。
\n", "date_published": "2026-03-28T00:00:00.000Z", "date_modified": "2026-06-04T13:54:51.000Z", "authors": [], "tags": [ "AWS", "Windows" ] }, { "title": "EC2 Windows 无法通过 RDP 登录：内存耗尽导致 Winlogon 异常", "url": "https://blog.checo.cc/posts/AWS/17.html", "id": "https://blog.checo.cc/posts/AWS/17.html", "summary": "EC2 Windows 实例状态检查正常、能 ping 通，但 RDP 连接不上，Stop & Start 后又恢复。遇到这种情况不要只看网络，Windows 内部资源耗尽也可能让 Winlogon 等关键进程崩溃。", "content_html": "\nEC2 Windows 实例状态检查正常、能 ping 通，但 RDP 连接不上，Stop & Start 后又恢复。遇到这种情况不要只看网络，Windows 内部资源耗尽也可能让 Winlogon 等关键进程崩溃。
\n\n这种现象很像网络问题，但日志可能指向系统资源不足。
\n事件日志中可能出现：
\nNot enough storage is available to process this command.以及：
\nSystem.OutOfMemoryException还可能看到 Winlogon 相关事件，例如 Winlogon 崩溃或无法正常创建登录会话。
\n这里的 “storage” 不一定指磁盘，Windows 错误码上下文中也可能指内存或系统资源不足。
\n实例内存和分页文件资源耗尽后，系统无法为关键进程分配资源。RDP 登录依赖的 Winlogon、LSASS、远程桌面服务等组件可能无法正常工作。
\nStop & Start 会清空内存状态，所以故障临时消失，但如果实例规格或应用内存占用不解决，问题还会复发。
\n重点看故障发生前后的：
\n关注：
\nOutOfMemoryExceptionNot enough storage is available确认当前实例内存是否满足业务峰值。如果长期接近上限，应升级实例规格或优化应用。
\nCloudWatch 默认不采集 Windows 内存指标。需要安装 CloudWatch Agent，采集：
\n并设置告警，例如内存使用率超过 85% 提醒。
\nStop & Start 可以释放内存，临时恢复登录能力。但这不是根治。
\n排查占用内存高的应用、监控代理、安全软件，确认是否存在内存泄漏或配置过重。
\n如果业务峰值确实需要更多内存，应升级到更大规格。升级前先创建 AMI，确认实例类型兼容 ENA/NVMe。
\nRDP 登录失败不一定是 3389、安全组或 NACL 问题。只要实例仍可 ping、状态检查通过，就应同时查看 Windows 事件日志。
\n如果日志里出现 OOM、系统资源不足和 Winlogon 异常，根因很可能是内存耗尽。Stop & Start 只能临时恢复，长期需要监控内存并调整实例规格或应用配置。
\n", "date_published": "2026-04-25T00:00:00.000Z", "date_modified": "2026-06-04T13:54:51.000Z", "authors": [], "tags": [ "AWS", "Windows" ] }, { "title": "EC2 Windows 无法挂载 SMB：EDR 拦截与 Workgroup 认证", "url": "https://blog.checo.cc/posts/AWS/18.html", "id": "https://blog.checo.cc/posts/AWS/18.html", "summary": "两台同 VPC 的 EC2 Windows 实例通过 SMB 访问共享失败，安全组和 NACL 都放行，Windows 防火墙也关闭，但 net use 报 1792，抓包看到 STATUS_NETLOGON_NOT_STARTED。最终根因不是 VPC 网络，而是安全软件拦截了 SMB 认证流程。", "content_html": "\n两台同 VPC 的 EC2 Windows 实例通过 SMB 访问共享失败，安全组和 NACL 都放行，Windows 防火墙也关闭，但 net use 报 1792，抓包看到 STATUS_NETLOGON_NOT_STARTED。最终根因不是 VPC 网络，而是安全软件拦截了 SMB 认证流程。
客户端访问：
\n\\\\<server-private-ip>\\share无法打开，也不弹出认证窗口。命令行执行：
\nnet use Z: \\\\<server-private-ip>\\share报错：
\n发生系统错误 1792\n试图登录，但是网络登录服务没有启动之后甚至出现 445 端口连接超时、ping 不通等现象。
\n确认：
\n抓包可以看到 SMB 协议已经开始协商：
\nSMB2 Negotiate Protocol Request\nSMB2 Negotiate Protocol Response\nSMB2 Session Setup Request\nSMB2 Session Setup Response: STATUS_NETLOGON_NOT_STARTED这说明流量已经到达服务端，不是 AWS 底层网络丢包。
\nWorkgroup 环境下，Netlogon 服务默认不运行是正常的。本地账户 SMB 认证通常通过本地 SAM + NTLM 完成，不应该因为 Netlogon stopped 就必然失败。
如果返回 STATUS_NETLOGON_NOT_STARTED 后又出现所有流量被阻断，应该怀疑安全软件或 EDR 对 SMB 认证流量做了拦截。
在变更窗口内临时停用安全软件，验证 SMB 是否恢复。如果停用后 445 和 ping 都恢复，基本可以确认根因。
\n在 Workgroup 环境中，不要依赖隐式凭据。使用服务器本地账户：
\nnet use Z: \\\\<server-private-ip>\\share /user:<server-computer-name>\\Administrator注意 <server-computer-name> 必须是服务端计算机名，不是客户端。
联系安全软件厂商或安全团队，把正常 SMB/NTLM 认证流量加入白名单，避免误拦截。
\n如果多台 Windows 实例频繁共享文件，建议加入 Active Directory，使用域账户和组权限统一管理，减少 Workgroup + 本地账户认证的复杂度。
\nEC2 Windows SMB 不通时，不能只看安全组。抓包如果已经看到 SMB 协议协商和认证阶段错误，就说明问题进入 OS 或安全软件层。
\nSTATUS_NETLOGON_NOT_STARTED 在 Workgroup 场景下不一定代表 Netlogon 本身是根因。结合后续流量被阻断，EDR 或安全软件拦截是重点排查方向。
从 AWS 公有 Windows AMI 启动的 EC2 实例不能直接通过 VM Import/Export 导出为 VMDK，因为包含 AWS 授权软件。替代方案是停机后块级读取 EBS 根卷，用 qemu-img 转换，并离线启用 Windows 通用存储驱动，避免在 VMware 中蓝屏。
执行 create-instance-export-task 时可能报：
An error occurred (NotExportable) when calling the CreateInstanceExportTask operation:\nThe image ID (ami-xxxxxxxx) provided contains AWS-licensed software and is not exportable.这是产品限制，不是 IAM 权限问题。从 AWS 公有 AMI 启动的 Windows / SQL Server / Marketplace 镜像通常不可导出。
\n可选方案：
\n本文记录第三种方案。
\nEC2 Windows 通常运行在 NVMe 设备上。导出到 VMware 后，控制器可能变成 LSI Logic SAS、SATA 或 IDE。如果 Windows 注册表中这些驱动没有设置为 Boot 加载，启动时会蓝屏：
\nUNMOUNTABLE_BOOT_VOLUME所以转换前要离线修改 SYSTEM hive，把常见存储驱动 Start 值设为 0。
\naws ec2 stop-instances --instance-ids <instance-id>\naws ec2 wait instance-stopped --instance-ids <instance-id>\n\naws ec2 detach-volume --volume-id <volume-id>\naws ec2 wait volume-available --volume-ids <volume-id>\n\naws ec2 attach-volume \\\n --volume-id <volume-id> \\\n --instance-id <helper-instance-id> \\\n --device /dev/sdg操作前建议先给卷创建快照。
\nsudo lsblk -o NAME,SIZE,SERIAL,MOUNTPOINT,FSTYPENitro 实例上 EBS 会显示为 /dev/nvmeXn1，可以通过 SERIAL 对应卷 ID。
sudo mkfs.xfs -f /dev/nvme1n1\nsudo mkdir -p /mnt/work\nsudo mount /dev/nvme1n1 /mnt/work工作盘大小要大于目标卷实际输出大小。
\nsudo dnf install -y qemu-img gcc make perl如果仓库没有 hivex，需要从源码安装，用于编辑 Windows 注册表 hive。
\nsudo modprobe ntfs3\nsudo mkdir -p /mnt/windows\nsudo mount -t ntfs3 -o rw /dev/nvme2n1p1 /mnt/windows\n\nsudo cp /mnt/windows/Windows/System32/config/SYSTEM /mnt/work/SYSTEM_BACKUP\nsudo cp /mnt/windows/Windows/System32/config/SYSTEM /tmp/SYSTEM_EDIT需要把这些服务的 Start 设置为 0：
| 服务 | 用途 |
\n|
在内网 ALB 上配置 HTTPS 后，客户端访问域名时报 curl: (60) SSL certificate problem: unable to get local issuer certificate。这个错误不一定是网络问题，更常见的是 ALB 绑定的 ACM 证书链不完整，或者证书 SAN 没覆盖访问域名。
访问内网服务时报错：
\ncurl https://service.example.internal/api/v1/healthcurl: (60) SSL certificate problem: unable to get local issuer certificate架构大致是：
\n客户端 -> 内网 ALB 443 -> 后端目标 443如果绕过 ALB，直接访问后端目标可以成功，就说明后端服务本身大概率不是根因。
\n如果域名在 Route 53 私有托管区里解析到内网 ALB，公网 SSL checker 看到的可能是另一条公网解析记录。公网检查结果无法代表内网 ALB 实际下发的证书。
\n在内网客户端执行：
\nopenssl s_client -showcerts \\\n -connect <alb-dns-name>:443 \\\n -servername service.example.internal </dev/null重点看两件事：
\n证书链断裂和域名不匹配是两个不同问题：
\n两者任何一个存在，HTTPS 都可能失败。
\n案例中站点证书由某个 DV 中间 CA 签发，但导入 ACM 时附带的是另一个 OV 中间 CA。ALB 因此向客户端下发了不匹配的中间证书链，curl 无法构建完整信任链。
\n同时，ALB 绑定证书的 SAN 也没有覆盖实际访问域名。也就是说，即使证书链修好，仍然会因为域名不匹配继续失败。
\n重新导入原 ACM 证书，上传正确的中间证书链：
\naws acm import-certificate \\\n --certificate-arn <certificate-arn> \\\n --certificate fileb://site.crt \\\n --private-key fileb://site.key \\\n --certificate-chain fileb://correct-chain.crt使用 reimport 的好处是保留原 ARN，ALB 侦听器不需要重新选择证书。
\n检查证书 SAN 是否包含实际使用的域名：
\nopenssl x509 -in site.crt -noout -text | grep -A1 \"Subject Alternative Name\"如果不包含，需要申请或导入一张覆盖目标域名的新证书，并绑定到 ALB HTTPS 侦听器。
\n如果 ALB 上挂了多张证书，建议清理不再使用的证书，避免 SNI 匹配和运维判断混乱。
\nALB HTTPS 报 unable to get local issuer certificate 时，排查重点是 ALB 实际下发的证书链，而不是后端 Nginx 或公网 SSL 检查结果。
推荐固定排查顺序：
\nopenssl s_client -showcerts 看 ALB 下发证书。有时需要临时统计一个 S3 桶中某类文件的数量和容量，例如 .jpg、.png 图片对象。如果桶开启了版本控制，还要把历史版本也算进去。这种需求不一定适合等 S3 Inventory，AWS CLI 直接流式统计更快。
目标是统计某个开启版本控制的 S3 桶内：
\n如果业务要求“现在就要结果”，S3 Inventory 不一定合适，因为它是异步报表，首次生成通常有延迟。
\n普通 list-objects 只看当前对象版本，不能覆盖历史版本。开启版本控制的桶应使用：
aws s3api list-object-versions再通过 --query 'Versions[*].[Key, Size]' 只取对象 Key 和 Size，减少后续处理成本。
下面示例统计 .jpg 和 .png：
aws s3api list-object-versions \\\n --bucket <bucket-name> \\\n --region <region> \\\n --query 'Versions[*].[Key, Size]' \\\n --output text |\ngrep -Ei \"\\.(jpg|png)[[:space:]]+[0-9]+$\" |\nawk '\nBEGIN {\n fmt = \"图片对象总数（含历史版本）: %d\\n\"\n}\n{\n count++;\n size += $NF;\n}\nEND {\n print \"======================\";\n printf fmt, count;\n printf \"总容量（含历史版本）: %.2f GB\\n\", size/1024/1024/1024;\n print \"======================\";\n}'示例输出：
\n======================\n图片对象总数（含历史版本）: 120446\n总容量（含历史版本）: 56.33 GB\n======================list-object-versions，改用 list-objects-v2。紧急统计 S3 桶中特定扩展名对象时，list-object-versions + grep + awk 是一个简单有效的方案。它的优点是实时、轻量、无需等待 Inventory；缺点是更偏一次性统计，不适合长期周期报表。
在 AD + SAML 联合身份场景下，用户可能通过同一个高权限 IAM Role 登录 AWS 控制台。如果只想限制其中一部分用户不能使用 Session Manager 或 EC2 Instance Connect 登录实例，可以用 aws:userid 条件键做显式 Deny。
客户环境中大量域用户通过 SAML AssumeRole 登录 AWS 控制台，使用的可能是 PowerUser 或 Administrator 这类高权限 Role。
出于合规要求，需要限制某些用户不能通过控制台进入 EC2 实例，主要涉及两类能力：
\nssm:StartSessionec2-instance-connect:SendSSHPublicKeySAML 联合登录后，IAM 会生成会话标识。策略判断时更稳定可用的是全局条件键 aws:userid。它通常包含角色 ID 和会话名称，形式类似：
<role-id>:<session-name>因为 role ID 部分会随 Role 变化，不适合硬编码，所以可以用通配符匹配会话后缀：
\n*:user-or-ou-id在目标 IAM Role 上增加一个显式 Deny：
\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Sid\": \"DenyEC2LoginForSpecificFederatedUsers\",\n \"Effect\": \"Deny\",\n \"Action\": [\n \"ssm:StartSession\",\n \"ec2-instance-connect:SendSSHPublicKey\"\n ],\n \"Resource\": \"*\",\n \"Condition\": {\n \"StringLike\": {\n \"aws:userid\": [\n \"*:<user-or-ou-id>\"\n ]\n }\n }\n }\n ]\n}显式 Deny 优先级高于 Allow，所以即使 Role 里已有高权限策略，匹配条件的用户仍会被拦截。
\n如果 Deny 生效，目标用户会在调用相关 API 时被拒绝。
\n基于 aws:userid 硬编码用户后缀能快速解决问题，但维护成本高。更好的方式是从身份源层面拆分权限：
AWS-No-EC2-Login。这样权限边界更清晰，也更容易审计和自动化管理。
\n如果需要临时限制部分 SAML 用户通过控制台登录 EC2，可以用 aws:userid + 显式 Deny 精准拦截 ssm:StartSession 和 ec2-instance-connect:SendSSHPublicKey。
长期来看，建议把用户分组和 Role 映射放到身份源侧管理，而不是在一个高权限 Role 里维护越来越复杂的条件策略。
\n", "date_published": "2026-04-06T00:00:00.000Z", "date_modified": "2026-06-04T13:54:51.000Z", "authors": [], "tags": [ "AWS", "安全" ] }, { "title": "Amazon Linux 2 扩容 EBS 后 growpart 失败", "url": "https://blog.checo.cc/posts/AWS/6.html", "id": "https://blog.checo.cc/posts/AWS/6.html", "summary": "EBS 卷在控制台扩容后，还需要在操作系统内扩展分区和文件系统。如果根分区已经 100% 满了，growpart 可能会因为无法写临时文件而失败，错误看起来像是 sfdisk 问题。", "content_html": "\nEBS 卷在控制台扩容后，还需要在操作系统内扩展分区和文件系统。如果根分区已经 100% 满了，growpart 可能会因为无法写临时文件而失败，错误看起来像是 sfdisk 问题。
执行分区扩容：
\nsudo growpart /dev/nvme0n1 1返回类似错误：
\nfailed [sfd_list:1] sfdisk --list --unit=S /dev/nvme0n1\nFAILED: failed: sfdisk --list /dev/nvme0n1环境通常是：
\n/dev/nvme0n1，根分区是 /dev/nvme0n1p1。/ 已经接近或达到 100%。growpart 执行时需要在系统目录中创建临时文件并重写分区表。如果根文件系统已经满到只剩几十 KB，底层 sfdisk 调用可能无法正常完成，于是表现为分区扩容失败。
这时首要任务不是继续反复执行 growpart，而是先释放一点根分区空间。
Amazon Linux 2 上可以先清理 yum 缓存：
\nsudo yum clean all确认根分区至少有几 MB 可用空间：
\ndf -h /sudo growpart /dev/nvme0n1 1XFS 需要用挂载点扩容：
\nsudo xfs_growfs -d /如果是 ext4，则应使用：
\nsudo resize2fs /dev/nvme0n1p1df -hT /\nlsblk确认根分区大小和可用空间已经更新。
\ngrowpart 报 sfdisk 失败不一定是分区表坏了，也可能只是根文件系统没有空间让工具运行。对 Amazon Linux 2 + XFS 的根卷扩容，可以按这个顺序处理：
growpart 扩分区。xfs_growfs 扩文件系统。df -hT 验证。EC2 Linux 实例无法启动或实例状态检查失败时，问题可能同时存在于 AWS 控制面和操作系统内部。这个案例里，一部分是 KMS 权限导致加密 EBS 无法解密，另一部分是 /etc/fstab 使用不稳定设备名导致系统进入维护模式。
故障分成两类：
\nCreateGrant 或 Decrypt 权限不足。Give root password for maintenance\n(or press Control-D to continue):第二种情况会导致 OS 无法完整启动，实例无法响应底层健康检查，最终表现为实例状态检查异常。
\n如果 EBS 卷使用 KMS CMK 加密，启动实例的 IAM 角色必须具备使用该 KMS key 的权限。至少需要：
\n{\n \"Effect\": \"Allow\",\n \"Action\": [\n \"kms:Decrypt\",\n \"kms:GenerateDataKey\",\n \"kms:CreateGrant\"\n ],\n \"Resource\": \"arn:aws-cn:kms:<region>:<account-id>:key/<key-id>\"\n}如果角色没有权限，EC2 在启动阶段无法解密系统盘或数据盘，实例就会启动失败。
\nLinux 上 NVMe 设备名可能随重启或底层变化改变。如果 /etc/fstab 中写死了类似：
/dev/nvme2n1p1 /data ext4 defaults 1 2当设备名变化或卷不存在时，系统会在启动阶段等待挂载，最终进入 emergency / maintenance 模式。
\n更稳的写法是用 UUID 并加 nofail：
UUID=<volume-uuid> /data ext4 defaults,nofail 1 2网络文件系统还应加 _netdev：
server:/share /mnt/share nfs defaults,_netdev,nofail 0 0在同可用区启动一台 Linux 救援实例。停止原实例后，分离原根卷并挂载到救援实例。
\n如果原系统使用 LVM，先安装工具并激活卷组：
\nsudo dnf install lvm2 -y\nsudo vgscan\nsudo vgchange -ay\nsudo lvs挂载原根分区：
\nsudo mkdir -p /mnt/rescue\nsudo mount -o nouuid /dev/<vg-name>/<root-lv> /mnt/rescuesudo vi /mnt/rescue/etc/fstab先把有风险的数据盘挂载项注释掉，让系统能启动。启动后再用 lsblk -f 获取 UUID，改成稳定配置。
sudo umount /mnt/rescue\nsudo vgchange -an然后在控制台把根卷挂回原实例，启动并验证。
\n实例启动后执行：
\nlsblk -f\nsudo systemctl daemon-reload\nsudo mount -a\ndf -hmount -a 无报错，说明 fstab 配置基本正常。
EC2 Linux 启动失败要区分两层：
\n加密卷启动失败优先查 CloudTrail 和 KMS 权限；系统卡维护模式优先查控制台系统日志和 /etc/fstab。数据盘挂载建议统一使用 UUID + nofail，避免设备名变化把系统启动卡死。
手动安装 Windows Server 2019 累积更新时，如果提示 “The update is not applicable to your computer”，不一定代表缺少前置 SSU。很多时候是系统已经安装了更高版本累积更新，但还没重启完成版本号更新。
\n\n手动安装某个 Windows Server 2019 累积更新时，安装器返回：
\nThe update is not applicable to your computerCBS 日志中可能出现：
\nHigher version found for package ..., superseded.WindowsUpdate.log 中可能看到：
\nThe volatile RebootRequired key exists先看当前系统版本：
\nwinver或者读取注册表：
\nGet-ItemProperty \"HKLM:\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\" |\n Select-Object CurrentBuildNumber, UBR如果当前 Build 已高于目标 KB 对应版本，说明该 KB 内容已经被更高版本累积更新覆盖，安装“不适用”是正常结果。
\nCBS.log 里的 Higher version found 很关键。Windows 累积更新之间存在取代关系，较新的 LCU 已包含旧 LCU 的内容。
如果 WindowsUpdate.log 出现 RebootRequired，说明系统可能已经完成阶段性安装，但注册表中的 Build/UBR 还没在重启过程中更新。
这会导致 winver 看起来仍是旧版本，而 CBS 已经显示更高版本包存在。
如果 CBS 已显示系统存在更高版本包，应停止继续安装旧 KB，避免浪费维护窗口。
\n生产环境建议先创建 AMI 备份，再重启实例：
\nRestart-Computer重启后再次检查：
\nwinver\nGet-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10如果没有必须安装某个旧 KB 的合规要求，建议直接安装最新 LCU。Windows 累积更新通常包含此前更新内容。
\n“此更新不适用于您的计算机”不一定是失败。排查时不要只看 winver，还要结合：
RebootRequired。如果系统已经安装更高版本更新但尚未重启，正确动作通常是安排维护窗口重启，而不是反复手动安装旧补丁。
\n", "date_published": "2026-04-25T00:00:00.000Z", "date_modified": "2026-06-04T13:54:51.000Z", "authors": [], "tags": [ "AWS", "Windows" ] }, { "title": "Windows Server 2019 .NET 累积更新安装失败：绕过 WUA 使用 DISM", "url": "https://blog.checo.cc/posts/AWS/9.html", "id": "https://blog.checo.cc/posts/AWS/9.html", "summary": "在 Windows Server 2019 上安装 .NET Framework 累积更新时，如果双击 .msu 或 wusa.exe 路径一直失败，并且 WindowsUpdate.log 出现 0xC8000402 PopulateDataStore failed，问题可能不是 CBS 安装失败，而是 WUA 扫描层已经坏了。", "content_html": "\n在 Windows Server 2019 上安装 .NET Framework 累积更新时，如果双击 .msu 或 wusa.exe 路径一直失败，并且 WindowsUpdate.log 出现 0xC8000402 PopulateDataStore failed，问题可能不是 CBS 安装失败，而是 WUA 扫描层已经坏了。
某些 .NET 累积更新是容器包，里面包含多个真正适用的 .msu。例如一个总 KB 可能内嵌：
如果系统已经是 .NET 4.8，只需要安装对应 4.8 的那份。
\nWindowsUpdate.log 反复出现：
\nProtocolTalker *FAILED* [C8000402] PopulateDataStore failed\nProtocolTalker *FAILED* [C8000402] Sync of Updates\nAgent * END * Finding updates ... Exit code = 0xC8000402CBS.log 中却搜不到目标 KB 的痕迹。
\n这说明补丁还没有进入 CBS 安装引擎，失败发生在更早的 WUA 扫描阶段。
\nwusa.exe 安装 .msu 的流程大致是：
双击 .msu -> wusa.exe -> WUA 适用性扫描 -> CBS 安装如果 WUA 的 DataStore 损坏，或者离线扫描源反复注册导致元数据污染，WUA 可能在 PopulateDataStore 阶段失败，最终返回 “0 updates found” 或安装失败。
此时继续双击 .msu 没意义，因为永远到不了 CBS。
核心思路是绕过 WUA，直接让 CBS 处理 CAB 包。
\n$msu = \"C:\\Patches\\windows10.0-kbxxxxx-x64-ndp48.msu\"\n$dst = \"C:\\Patches\\Extract\"\nNew-Item -ItemType Directory -Force -Path $dst | Out-Null\nexpand.exe -F:* $msu $dst$cab = Get-ChildItem $dst -Filter \"Windows10.0-KB*.cab\" | Select-Object -First 1\nDISM.exe /Online /Add-Package /PackagePath:\"$($cab.FullName)\" /NoRestart /LogPath:C:\\Patches\\dism.logshutdown /r /t 30Get-HotFix -Id KBxxxxx\nDISM.exe /Online /Get-Packages | findstr /I \"DotNetRollup\"如果是 .NET 更新，还可以检查关键 .NET 文件版本是否更新。
\n如果后续还需要 Windows Update 正常扫描，可以重置 WUA 数据库：
\nStop-Service -Name wuauserv, BITS, cryptSvc -Force\nRename-Item C:\\Windows\\SoftwareDistribution C:\\Windows\\SoftwareDistribution.old\nRename-Item C:\\Windows\\System32\\catroot2 C:\\Windows\\System32\\catroot2.old\n\n$svc = New-Object -ComObject Microsoft.Update.ServiceManager\n$svc.Services | Where-Object { $_.IsScanPackageService } |\n ForEach-Object { $svc.RemoveService($_.ServiceID) }\n\nStart-Service -Name wuauserv, BITS, cryptSvc这不是安装补丁的必要步骤，只是恢复 WUA 扫描能力。
\n如果目标 KB 在 CBS.log 中完全没有痕迹，而 WindowsUpdate.log 指向 0xC8000402 PopulateDataStore failed，就要把问题定位在 WUA 扫描层。
处理方式是：
\nDISM /Add-Package 直接注入。这个方法适合 WUA 损坏但 CBS 仍正常的场景。
\n", "date_published": "2026-06-03T00:00:00.000Z", "date_modified": "2026-06-04T13:54:51.000Z", "authors": [], "tags": [ "AWS", "Windows" ] }, { "title": "Mac mini M4 硬件深度检测指南", "url": "https://blog.checo.cc/posts/Mac/1.html", "id": "https://blog.checo.cc/posts/Mac/1.html", "summary": "Mac mini M4 透明俯视内部构造图Mac mini M4 透明俯视内部构造图 新 Mac 到手后，我习惯先做一次系统化检测：硬件信息、SSD 健康、接口状态、安全配置、系统稳定性都过一遍。这样后面如果遇到异常，可以知道是机器本身的问题，还是后续使用环境造成的。", "content_html": "\n新 Mac 到手后，我习惯先做一次系统化检测：硬件信息、SSD 健康、接口状态、安全配置、系统稳定性都过一遍。这样后面如果遇到异常，可以知道是机器本身的问题，还是后续使用环境造成的。
\n\n本文基于 Mac mini M4 的实际检测流程整理，命令主要适用于 Apple Silicon Mac。
\n查看硬件概况：
\nsystem_profiler SPHardwareDataType重点看这些字段：
\n查看 macOS 版本：
\nsw_vers查看系统运行时间：
\nuptime查看首次设置日期：
\nls -la /var/db/.AppleSetupDone.AppleSetupDone 的修改时间通常可以作为首次开机设置时间的参考。
system_profiler SPNVMeDataType也可以看 diskutil 输出：
diskutil info disk0重点关注：
\n需要先安装 smartmontools：
\nbrew install smartmontools查看内置 SSD 的完整 SMART 数据：
\nsudo smartctl -a /dev/disk0常用指标可以这样理解：
\n| 指标 | 含义 | 正常参考 |
\n|
一次很离谱的经历：Dock 里的 VS Code 图标突然变成通用应用图标，Finder 里原本的 Visual Studio Code.app 也不见了。最后排查下来，问题出在 VS Code 自动更新、ShipIt 后台进程和跨 APFS 卷移动之间。
凌晨打开 Mac mini 准备工作，习惯性点击 Dock 上的 VS Code 图标，结果图标变成了空白的 macOS 通用应用图标。
\n![\"Dock](\"/assets/images/vscode/vscode-generic-icon.png\"){kind=icon}
打开 Finder 到应用所在目录，也能看到 VS Code 状态异常：
\n![\"Finder](\"/assets/images/vscode/vscode-missing-finder.png\")
我的 VS Code 没装在系统默认的 /Applications/，而是在外置 APFS 卷的应用目录里。
先检查应用目录：
\nls -la \"/Volumes/<external-volume>/applications/\" | grep -i \"code\\|visual\"没有任何输出。也就是说，Visual Studio Code.app 目录已经不存在。
但 Dock 里还保留着旧路径：
\ndefaults read com.apple.dock persistent-apps | grep -A2 \"Visual Studio Code\"输出里还能看到类似路径：
\nfile:///Volumes/<external-volume>/applications/Visual%20Studio%20Code.app/Dock 记住了一个已经不存在的 app，所以 macOS 只能显示通用图标。
\n继续查系统临时目录，发现了 VS Code 的更新器痕迹：
\nfind /private/var/folders -name \"*.ShipIt*\" -maxdepth 4能看到多个类似目录：
\n/private/var/folders/.../T/com.microsoft.VSCode.ShipIt.xxxxxxxx进入其中一个目录，可以看到完整的 Visual Studio Code.app 包。也就是说，旧版本已经从目标目录删除，新版本却停在了临时目录里，没有成功回到安装位置。
查看临时目录里 app 的版本：
\ndefaults read \"/private/var/folders/.../ShipIt.xxxxxxxx/Visual Studio Code.app/Contents/Info.plist\" CFBundleShortVersionString确认它就是更新后的新版本。
\n结论很明确：VS Code 自动更新器删除了旧版本，但新版本移动回原位置时失败了。
\nVS Code 使用 Electron 的 Squirrel.Mac 做自动更新，核心辅助进程叫 ShipIt。大致流程是：
\n1. 检查更新并下载新版本\n2. 解压到 /private/var/folders/.../T/\n3. 启动 ShipIt 辅助进程\n4. ShipIt 等待 VS Code 退出\n5. 删除旧的 Visual Studio Code.app\n6. 把新 app 移动到原安装位置问题出在临时目录和安装目录不在同一个卷。
\nmacOS 的临时目录通常在启动卷：
\n/private/var/folders/<hash>/T/而我的 VS Code 在外置 APFS 卷：
\n/Volumes/<external-volume>/applications/Visual Studio Code.app同卷移动通常只是改目录项，速度很快；跨卷移动则会变成复制再删除。这个过程不是原子的，只要复制中断、目标卷权限异常、磁盘空间不足、卷短暂不可用，就可能出现“旧的删了，新的没到”的状态。
\n这不是 VS Code 独有的问题。只要更新器把新版本放在启动卷临时目录，再把 app 移到另一个卷，就有类似风险。
\n第一次我从临时目录把 app 移回去：
\nmv \"/private/var/folders/.../T/com.microsoft.VSCode.ShipIt.xxxxxxxx/Visual Studio Code.app\" \\\n \"/Volumes/<external-volume>/applications/\"然后在 VS Code 设置里禁用自动更新：
\n{\n \"update.mode\": \"none\"\n}本以为问题结束了，结果用 DMG 重装后，VS Code 又被删了一次。
\n原因是 ShipIt 是独立后台进程。旧版 VS Code 之前已经触发过更新，ShipIt 可能还在后台排队等待执行。update.mode: "none" 只在 VS Code 主进程读取配置时生效，挡不住已经启动的 ShipIt。
pkill -f \"ShipIt\"mv \"/private/var/folders/.../T/com.microsoft.VSCode.ShipIt.xxxxxxxx/Visual Studio Code.app\" \\\n \"/Volumes/<external-volume>/applications/\"关键是让 ShipIt 二进制无法继续运行：
\nchmod -x \"/Volumes/<external-volume>/applications/Visual Studio Code.app/Contents/Frameworks/Squirrel.framework/Versions/A/Resources/ShipIt\"确认执行权限已经去掉：
\nls -la \"/Volumes/<external-volume>/applications/Visual Studio Code.app/Contents/Frameworks/Squirrel.framework/Versions/A/Resources/ShipIt\"如果权限里没有 x，说明它已经不能直接执行。
rm -rf /private/var/folders/.../T/com.microsoft.VSCode.ShipIt.*这一步要小心路径，确认只删除 VS Code 的 ShipIt 临时目录。
\nupdate.mode: "none" 不够它只能阻止 VS Code 主进程后续触发更新。对已经运行的 ShipIt 后台进程无效。
\n如果必须把 app 放在外置卷，建议禁用自动更新，改成手动更新。否则每次自动更新都可能触发跨卷复制。
\n更新失败时，新版本 app 往往还完整地躺在：
\n/private/var/folders/.../T/com.microsoft.VSCode.ShipIt.xxxxxxxx/不要急着重新下载，先找临时目录。
\n关掉 VS Code 不代表更新器已经停止。排查这类问题时，要单独检查和清理 ShipIt。
\n| 项目 | 内容 |
\n|
众所周知，Kali有很多自带的渗透测试工具。今天心血来潮想要在WSL中安装一个并且迁移到E盘，避免占用所剩无几的C盘空间
\nWindows系统需要开启WSL
\n如果之前有装过WSL，默认是Ubuntu，可以使用以下命令进行卸载
\nwsl --unregister kali-linuxwsl --install -d kali-linux![](\"https://picgo.checo.cc/20251211022031.png\")
wsl --export kali-linux D:\\kali-backup.tar![](\"https://picgo.checo.cc/20251211022321.png\")
wsl --unregister kali-linux![](\"https://picgo.checo.cc/20251211022909.png\")
wsl --import kali-linux E:\\WSL\\Kali D:\\kali-backup.tar![](\"https://picgo.checo.cc/20251211022548.png\")
wsl -d kali-linux会默认以root身份登录
\n![](\"https://picgo.checo.cc/20251215005129.png\")
echo -e \"[user]\\ndefault=checo\" > /etc/wsl.conf![](\"https://picgo.checo.cc/20251215005258.png\")
wsl --terminate kali-linuxwsl -d kali-linux![](\"https://picgo.checo.cc/20251215005514.png\")
\n进来后的提示符变成了 $，且用户名是 checo
之后可以出一期教程，研究如何使用Kali
\n", "image": "https://picgo.checo.cc/20251211022031.png", "date_published": "2025-12-11T00:00:00.000Z", "date_modified": "2026-06-06T15:23:57.000Z", "authors": [], "tags": [ "Windows", "Linux" ] }, { "title": "AWS 启动Windows11 EC2", "url": "https://blog.checo.cc/posts/AWS/2.html", "id": "https://blog.checo.cc/posts/AWS/2.html", "summary": "AWS 启动Windows11 EC2 众所周知，AWS中国区并没有提供Windows11的AMI，VMimport也比较麻烦 可以直接使用一个开源的reinstall脚本从Linux安装Windows 项目地址：https://github.com/bin456789/reinstall 参考文档：https://lpwmm.blog.csdn.ne...", "content_html": "\n众所周知，AWS中国区并没有提供Windows11的AMI，VMimport也比较麻烦
\n可以直接使用一个开源的reinstall脚本从Linux安装Windows
\n项目地址：https://github.com/bin456789/reinstall
\n参考文档：https://lpwmm.blog.csdn.net/article/details/155258680?spm=1001.2014.3001.5502
![\"CloudWatch](\"/assets/images/posts/aws-cloudwatch-cert-architecture.svg\")
在一台 Windows Server 2008 EC2 实例上，CloudWatch Agent 服务状态正常，但监控指标一直无法上报到 CloudWatch。日志里反复出现 x509: certificate signed by unknown authority，最后定位到旧系统根证书和 TLS 支持不足。
CloudWatch Agent 日志中持续出现类似错误：
\nWriteToCloudWatch failure, err: RequestError: send request failed\ncaused by: Post https://monitoring.<region>.amazonaws.com.cn/:\nx509: certificate signed by unknown authority同时需要注意两个容易误判的点：
\nping monitoring.<region>.amazonaws.com.cn 不通不一定代表服务不可达，Interface Endpoint 通常不响应 ICMP。404 Not Found 也是正常现象，它不是普通网页服务。Windows Server 2008 的根证书库太旧，可能缺少验证 AWS 服务端证书所需的根证书，例如 Amazon Root CA 1。纯内网实例如果无法访问公网，也不能自动拉取新的受信任根证书。
\n此外，旧版 Windows Server 2008 还可能缺少支持现代 TLS 链路的补丁。最终表现就是 CloudWatch Agent 建立 HTTPS 连接时无法完成证书链验证。
\n先安装 Windows Server 2008 所需的安全补丁，例如 KB4474419。补丁安装后必须重启系统。
\nwusa.exe C:\\Patches\\windows6.1-kb4474419-v3-x64.msu /quiet /norestart\nshutdown /r /t 0下载 Amazon Root CA 1 证书：
\nhttps://www.amazontrust.com/repository/AmazonRootCA1.cer在内网环境中，可以先从可访问公网的机器下载，再通过安全方式拷贝到实例。
\n导入到受信任根证书存储：
\ncertutil -addstore -f Root C:\\Patches\\AmazonRootCA1.cer也可以通过 certmgr.msc 图形界面导入到“受信任的根证书颁发机构”。
net stop \"Amazon CloudWatch Agent\"\nnet start \"Amazon CloudWatch Agent\"检查 Agent 日志，确认不再出现 x509: certificate signed by unknown authority。
也可以测试 TCP 443 连通性：
\n(New-Object System.Net.Sockets.TcpClient).Connect(\"monitoring.<region>.amazonaws.com.cn\", 443)如果命令无报错，说明 TCP 层连通。最终以 CloudWatch 控制台中指标正常上报为准。
\n旧版 Windows Server 2008 在纯内网环境里运行 CloudWatch Agent 时，常见问题不是 VPC Endpoint，而是系统根证书和 TLS 能力太旧。处理顺序建议是：
\n这类旧系统应尽量纳入迁移计划，长期运行会不断遇到证书、TLS、补丁和软件兼容问题。
\n", "image": "https://blog.checo.cc/assets/images/posts/aws-cloudwatch-cert-architecture.svg", "date_published": "2026-05-01T00:00:00.000Z", "date_modified": "2026-06-06T16:08:40.000Z", "authors": [], "tags": [ "AWS", "Windows" ] }, { "title": "足球", "url": "https://blog.checo.cc/photos/3.html", "id": "https://blog.checo.cc/photos/3.html", "summary": "2025.4.19 北京国安vs山东泰山", "content_html": "\n![](\"https://picgo.checo.cc/DSC_4615.JPG\")
![](\"https://picgo.checo.cc/DSC_4616.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4626.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4628.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4637.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4640.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4692.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4696.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4698.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4701.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4702.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4704.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4713.JPG\")
\n![](\"https://picgo.checo.cc/DSC_4747.JPG\")
![](\"https://picgo.checo.cc/DSC_6427-已增强-降噪.jpg\")
![](\"https://picgo.checo.cc/DSC_5916-已增强-降噪.jpg\")
\n![](\"https://picgo.checo.cc/DSC_6308.jpg\")
\n![](\"https://picgo.checo.cc/DSC_6359.jpg\")
\n![](\"https://picgo.checo.cc/DSC_6368-已增强-降噪.jpg\")
\n![](\"https://picgo.checo.cc/DSC_6364-已增强-降噪.jpg\")
\n![](\"https://picgo.checo.cc/DSC_6385-已增强-降噪.jpg\")
\n![](\"https://picgo.checo.cc/DSC_9305-2.jpg\")
\n![](\"https://picgo.checo.cc/DSC_9122.jpg\")
\n![](\"https://picgo.checo.cc/DSC_8961-已增强-降噪.jpg\")
\n![](\"https://picgo.checo.cc/DSC_8729.jpg\")
\n![](\"https://picgo.checo.cc/DSC_8666-已增强-降噪.jpg\")
\n![](\"https://picgo.checo.cc/DSC_8668-已增强-降噪.jpg\")
\n![](\"https://picgo.checo.cc/DSC_8727.jpg\")
\n![](\"https://picgo.checo.cc/DSC_4839-已增强-降噪.jpg\")
\n![](\"https://picgo.checo.cc/DSC_4880-已增强-降噪.jpg\")
![](\"https://picgo.checo.cc/DSC_0180.jpg\")
![](\"https://picgo.checo.cc/DSC_0307-已增强-降噪.jpg\")
\n![](\"https://picgo.checo.cc/DSC_0076.jpg\")
\n![](\"https://picgo.checo.cc/DSC_0059.jpg\")
\n![](\"https://picgo.checo.cc/DSC_0085.jpg\")
近日DeepSeek官网过于火爆，时常不回复
\n![](\"https://picgo.checo.cc/20250209145239.png\")
本地部署有更高的安全性
\n本地部署可以绕过一些官方的限制
\nOS: Windows 10 Pro 22H2
\nCPU: AMD Ryzen 5 5600H (6C12T, Base 3.3GHz / Boost 4.2GHz)
\nGPU: NVIDIA GeForce RTX 3050 Ti Laptop GPU (4GB GDDR6 VRAM)
\nRAM: SAMSUNG 16GB DDR4-3200
\nIDE: LM Studio v0.3.9
推荐使用国外网络环境并开启代理工具的TUN模式
\n下载安装LM Studio客户端
\n点击跳转
修改模型下载目录（推荐）
\n防止模型大量占用C盘空间
\n![](\"https://picgo.checo.cc/20250209115213.png\")
根据电脑配置下载对应模型
\n带Distill字样的是蒸馏模型
\n这里推荐DeepSeek-R1-Distill-Llama-8B-Abliterated-GGUF，4g显存能流畅运行，该模型还解除了DeepSeek自带的一些限制，让本地应用更加自由
\n![](\"https://picgo.checo.cc/20250209144621.png\")
加载模型
\n下载完成之后点击顶部加载刚刚下载好的模型
\n建议拉高GPU卸载，打开快速注意力以提高性能
\n![](\"https://picgo.checo.cc/20250209144950.png\")
进行使用即可
\n![](\"https://picgo.checo.cc/20250209145930.png\")
Checo
\n这个博客主要用来放两类内容：一类是技术折腾和排障记录，另一类是生活、摄影和一些个人兴趣。很多文章不是标准教程，而是我在真实环境里遇到问题后整理出来的复盘。
\n\n写博客对我来说不是为了把每件事包装得很完整，而是把“当时怎么判断、踩了什么坑、最后怎么解决”留下来。以后再次遇到类似问题，能少走一些弯路；别人搜到时，也能快速判断这条路是否适合自己。
\nAI 分类主要记录大模型和相关工具的使用体验。
\n目前会写这些方向：
\n这部分文章会偏实践，不会只堆概念。能本地跑起来、能接入客户端、能解决实际问题，才值得记录。
\nAWS 现在是博客里内容最多的一类。这里主要放云服务排障、EC2 运维、Windows/Linux 系统问题、S3、ALB、IAM、FSx、SSM、CloudWatch 等案例。
\n这类文章通常会按这个结构写：
\n很多 AWS 问题看起来是云平台故障，但最后根因可能在操作系统、证书链、KMS 权限、Windows Update、AD 端口、Kerberos 票据或第三方安全软件。写下来是为了提醒自己：排障要分层，不要一开始就把问题归因到某个组件。
\n运维分类放的是更通用的服务器、容器和服务迁移记录。
\n比如：
\n这类内容的重点是可复现和可回滚。生产环境里的操作不能只追求“能跑”，还要考虑备份、验证、切流量和失败回退。
\nVPS 分类会记录服务器、网络、域名和常用脚本。
\n后面计划补充：
\n这部分会比较杂，但都围绕个人服务器和网络资产管理。
\nmacOS 分类主要记录我自己的 Mac 使用、故障排查和硬件检测。
\n比如：
\n这类文章偏个人经验，但很多坑具有共性。尤其是 macOS 上跨卷、权限、临时目录、应用自动更新这些问题，平时不明显，一旦出事就很难第一时间定位。
\nWindows 分类目前主要放 WSL、Kali 和 Windows 环境相关内容。
\n以后会继续补：
\n这部分和 AWS 里的 Windows 排障不同：AWS 分类更关注云上案例，Windows 分类更偏本地环境和个人使用。
\n摄影是另一个长期保留的栏目。
\n这里不会写太多器材参数，更多是照片本身和拍摄场景，比如皖南川藏线、鸟、足球比赛。技术博客容易越写越硬，摄影能让这个站不只是一个问题清单，也保留一点生活感。
\n后续文章我会尽量遵循几个原则：
\n短期先把已有笔记整理干净，尤其是 AWS、运维和 VPS 相关内容。中期会把博客的视觉和导航再整理一下，让分类更清楚，文章列表更适合浏览。
\n这个博客现在还不算丰富，但已经开始有自己的方向：技术问题不只记录“怎么做”，更记录“为什么这么做”。能长期积累下去，就会越来越有价值。
\n", "image": "https://picgo.checo.cc/DSC_0180.jpg", "date_published": "2024-05-20T00:00:00.000Z", "date_modified": "2026-06-06T15:23:57.000Z", "authors": [], "tags": [ "博客" ] }, { "title": "通过硅基流动使用DeepSeek-R1", "url": "https://blog.checo.cc/posts/AI/2.html", "id": "https://blog.checo.cc/posts/AI/2.html", "summary": "通过硅基流动使用DeepSeek-R1 下载安装Cherry Studio 这里是内容。 注册硅基流动账号 点击注册 获取API key", "content_html": "\n这里是内容。
\n![\"从零训练](\"/assets/images/posts/llm-from-scratch-hero.png\")
这个项目是在 Apple M4 Mac mini 16GB 上，用 MLX 从随机初始化开始训练一个 TinyStories 风格的小型 GPT 模型。它不是调用 API，也不是微调现成模型，而是把数据准备、tokenizer、模型结构、训练循环、checkpoint 和推理生成完整走了一遍。
\n项目地址：sergioperezcheco/llm-from-scratch
\n\n最终训练的是一个 44M 参数量的 GPT 模型：
\n| 项目 | 结果 |
\n|
哪吒探针的三网延迟功能非常好用，我们可以通过FOFA这一网络空间测绘工具寻找我们需要的三网IP
\n\n", "date_published": "2022-01-06T00:00:00.000Z", "date_modified": "2026-04-02T16:35:01.000Z", "authors": [], "tags": [] } ] }