Mac 有 IPv6 地址却 ping 不通任何公网 IPv6。之前一直正常,某天突然全断,重启路由器也没用。最终定位是 iStoreOS 的 NDP Relay 模式不稳定,改一行配置从 relay 切到 server 就修好了。这篇记录了逐层排查到根因的完整过程。
AWS 不提供 Graviton 架构的 Windows AMI,但这不代表 Graviton 跑不了 Windows。本文记录如何用开源项目 bin456789/reinstall 的一键 DD 脚本,把一台运行 Amazon Linux 2023 的 t4g 实例原地重装成 Windows 11 Pro ARM64。


新 Mac 到手后,我习惯先做一次系统化检测:硬件信息、SSD 健康、接口状态、安全配置、系统稳定性都过一遍。这样后面如果遇到异常,可以知道是机器本身的问题,还是后续使用环境造成的。
在 EC2 Graviton 实例上跑 Windows 11 ARM 后,最实际的问题就是:x86/x64 的运维工具还能不能用?本文在 t4g.large(Graviton2)上对 Sysinternals Suite 全套工具做了兼容性测试,对比了 ARM64 原生与 x64 模拟的性能差异。
Graviton 实例跑 Windows 11 ARM 用的是 AWS ENA ARM64 驱动,而这个驱动目前只有一个版本(2.2.1)。它能跑满 t4g.large 的网络突发上限吗?本文用 iperf3 做了完整吞吐测试。
Graviton 上 DD 安装的 Windows 11 ARM 用的是微软 inbox StorNVMe.sys,而不是 AWS 官方 AWSNVMe.sys。这个 inbox 驱动会不会成为 IO 瓶颈?本文用 diskspd 做了完整的 IOPS 和吞吐测试,把瓶颈锁定在实例侧。
Graviton 上跑的是非官方方式安装的 Windows 11 ARM,Windows Update 还能正常工作吗?更新会不会把 inbox StorNVMe 驱动替换掉导致系统异常?本文做了完整的补丁扫描、下载、安装验证。
私有子网的 EC2 没有公网 IP,又不想用 AWS 托管 NAT Gateway(贵)。可以用一台 Windows Server 2022 实例配置 RRAS NAT 来做出网,本文记录完整的配置过程和踩坑。
Windows 实例执行 Sysprep 制作 AMI 时失败,报错 0x80073cf2。原因是 Notepad++ 8.9+ 注册的 AppX 包残留,即使卸载桌面版也无法清除。
EC2 Windows 实例启动后,系统时间比实际时间慢 8 小时。W32Time 同步时发生一次性 8 小时跳变,导致日志时间戳混乱、Kerberos 认证失败。根因是 RTC 本地时间与 UTC 混淆。
