跳至主要內容

在 EC2 T4g (Graviton) ARM 实例上 DD 安装 Windows 11 ARM

Checo2026/6/8大约 6 分钟AWSWindowsAWSEC2GravitonWindows 11ARM64DD

在 EC2 T4g (Graviton) ARM 实例上 DD 安装 Windows 11 ARM

AWS 不提供 Graviton 架构的 Windows AMI，但这不代表 Graviton 跑不了 Windows。本文记录如何用开源项目 bin456789/reinstall 的一键 DD 脚本，把一台运行 Amazon Linux 2023 的 t4g 实例原地重装成 Windows 11 Pro ARM64。

Windows 11 任务管理器显示 AWS Graviton2 处理器
Windows 11 任务管理器显示 AWS Graviton2 处理器

为什么 Graviton 跑不了 Windows

AWS 官方只提供 x86 架构的 Windows AMI。Graviton 是 ARM64 架构，微软虽然有 Windows on ARM，但 AWS 没有在 Graviton 平台上做官方驱动适配和 AMI 发布。所以正常流程是：选 t3/t3a 这类 x86 实例跑 Windows，Graviton 只能跑 Linux。

但「不官方支持」不等于「不能跑」。reinstall.sh 脚本能在已有的 Linux 实例上直接 DD 安装 Windows，包括 ARM64 版本。测试环境：

  • 实例类型：t4g.large（2 vCPU / 8 GB）
  • 原系统：Amazon Linux 2023 aarch64，50 GB EBS（gp3），UEFI 引导
  • 目标系统：Windows 11 Pro 25H2 ARM64（Build 26200.6584），中文版

核心发现：NVMe 驱动的反直觉坑

整个过程最反直觉的一点：注入 AWS 官方 NVMe 驱动反而导致启动失败，靠微软 inbox StorNVMe 才能正常运行。

StorNVMe.sys 是微软从 Windows 8.1 起就内置在系统镜像里的标准 NVMe 驱动，安装时自动加载，无需任何外部注入或手动操作。reinstall.sh 日志中的 Has StorNVMe: true 就是脚本检测到 ISO 自带该 inbox 驱动。

实测对比：

方案NVMe 驱动ENA 驱动结果
A（成功）不注入，用 inbox StorNVMe注入 AWS 官方 ARM64 ENA正常启动，RDP 可登录
B（失败）注入 AWS 官方 AWSNVMe100.sys注入 AWS 官方 ARM64 ENA实例状态检查持续失败，端口能握手但无响应

方案 B 的脚本日志显示一切正常（驱动文件正确拷入 boot.wim，***** DONE ***** 并重启），但 Windows 就是起不来。推测是 boot-start 驱动加载顺序或 ARM64 兼容性问题。

踩坑过程

脚本直接运行会 404

直接跑 reinstall.sh 安装 Windows 时，脚本在注入 AWS 驱动阶段中止：

***** ADD DRIVERS: AWS *****
https://s3.cn-north-1.amazonaws.com.cn/ec2-windows-drivers-downloads-cn/NVMe/ARM64/Latest/AWSNVMe.zip
[ERROR] CUID#7 - Download aborted. URI=.../NVMe/ARM64/Latest/AWSNVMe.zip
  -> [HttpSkipResponseCommand.cc:218] errorCode=3 Resource not found
***** ERROR *****
Failed to download .../NVMe/ARM64/Latest/AWSNVMe.zip

原因是脚本对 arm64 架构强行拼接 /ARM64 子目录去下载 NVMe 驱动，但 AWS 的 NVMe 驱动桶里根本没有 NVMe/ARM64/ 目录（只有 ENA 才有 ARM64 子目录），导致 404。

实际上 NVMe/Latest/AWSNVMe.zip 是一个 amd64 + ARM64 双架构通用包，AWSNVMe.inf 的 [Manufacturer] 段同时声明了两种架构：

[Manufacturer]
%Amazon% = AWSNVME, NTamd64.10.0, NTARM64.10.0
[AWSNVME.NTamd64.10.0]
[AWSNVME.NTARM64.10.0]

脚本拼 /ARM64 子目录是个 bug，正确路径应该是不带子目录的 NVMe/Latest/AWSNVMe.zip。不过知道了上面的结论，正确的做法是干脆不注入 NVMe 驱动。

ISO 来源

reinstall 脚本默认从网盘查找 ISO，但那是需要浏览器交互的非直链，自动下载会失败。需要手动指定微软官方 ARM64 Consumer 直链（可在 massgrave.dev/windows_arm_links 找到对应语言的 static 链接）。

微软 CDN 对中国出口限速明显，速度在 400 KiB/s ~ 20 MiB/s 之间波动，7 GB ISO 下载耗时较长。

完整操作步骤

1. 启动 t4g 实例

实例类型选 t4g.medium 或以上，磁盘 ≥ 30 GB。安全组放行入站 TCP 3389（RDP）和 SSH 22。

2. 下载脚本并准备安装

curl -O https://raw.githubusercontent.com/bin456789/reinstall/main/reinstall.sh

sudo bash reinstall.sh windows \
  --image-name="Windows 11 Pro" \
  --lang=zh-cn \
  --username=administrator \
  --password='YourPassword123' \
  --iso="https://software-static.download.prss.microsoft.com/dbazure/<id>/<build>_CLIENT_CONSUMER_A64FRE_zh-cn.iso"

注意事项：

  • --image-name 必须用消费者版包含的版本（Home / Home Single Language / Pro），不要用 IoT Enterprise LTSC，该版本没有 ARM64 ISO。
  • --iso 用微软官方 ARM64 Consumer 直链。不指定时脚本会找到需浏览器交互的网盘链接而卡住。

3. 重启进入 Alpine 安装环境

sudo reboot

重启后 GRUB 引导进 Alpine Live 环境，trans.sh 自动开始运行：识别 NVMe 磁盘和 ENA 网卡、分区、下载 Windows ISO。

Alpine 环境的 SSH 登录用户名是上一步 --username 设置的 administrator，密码是对应密码，不是 root。

4. 修补 trans.sh 跳过 NVMe 注入

这是核心步骤。trans.sh 跑到 AWS 驱动注入时会 404 中止，停在 Alpine 命令行并提示 Run 'sudo /trans.sh' to retry。

此时登录 Alpine，修改 /trans.sh 删除 NVMe 驱动注入：

sudo cp /trans.sh /trans.sh.bak
sudo sed -i '/AWSNVMe\.zip/d' /trans.sh

# 语法检查
sh -n /trans.sh && echo OK

修改后 add_driver_aws() 中应只剩 ENA 的下载与解压：

download "$(get_aws_repo)/ENA$arch_dir/$ena_ver/AwsEnaNetworkDriver.zip" $drv/AwsEnaNetworkDriver.zip
unzip -o -d $drv/aws/ $drv/AwsEnaNetworkDriver.zip
cp_drivers $drv/aws

5. 用 setsid 脱离 SSH 重新运行

直接前台 sudo /trans.sh 会在 SSH 断连时被 SIGHUP 杀掉。用 setsid 脱离 SSH 独立运行：

doas sh -c 'setsid sh -c "/trans.sh >/reinstall.log 2>&1" </dev/null >/dev/null 2>&1 &'

之后流程全自动，无需人工干预。可随时查看进度：

tail -c 200 /reinstall.log | tr '\r' '\n' | tail -5

备选：重启前修补 initrd

如果想避免「先失败再重跑」导致的 ISO 重复下载，可在第 2 步准备完成、第 3 步 reboot 之前，直接修补 initramfs 里嵌入的 trans.sh：

TRANS=/reinstall-tmp/initrd/trans.sh
sudo cp "$TRANS" "$TRANS.bak"
sudo sed -i '/AWSNVMe\.zip/d' "$TRANS"
sh -n "$TRANS" && echo OK

cd /reinstall-tmp/initrd
find . | sudo cpio --quiet -o -H newc -R 0:0 | gzip -1 | sudo tee /reinstall-initrd >/dev/null

然后再 sudo reboot，重启后 Alpine 跑的就是改好的脚本，一次成功。

整个过程从重启到 RDP 可用约 30 ~ 60 分钟（主要取决于 ISO 下载速度）。

6. 验证与登录

  • RDP 登录：用户名 administrator，密码是你设置的密码。
  • Windows 默认防火墙挡 ICMP，ping 不通正常。判断是否真正启动应以实例状态检查通过 + RDP 能登录为准。
  • 网卡驱动使用 AWS 官方 ENA ARM64 驱动，RDP 能连上即证明 ENA 工作正常。
Windows 11 桌面运行在 EC2 Graviton2 实例上
Windows 11 桌面运行在 EC2 Graviton2 实例上

避坑要点

  • 不要选 LTSC / IoT Enterprise 版本，没有 ARM64 ISO。
  • 不要让 SSH 前台直接跑 trans.sh，用 setsid 脱离 SSH，避免断连导致 SIGHUP 杀进程。
  • Alpine 安装环境的 SSH 用户名是脚本里设置的 --username（如 administrator）+ 对应密码，不是 root。
  • 不要注入 AWS 官方 NVMe 驱动。即使脚本日志显示驱动注入成功并 DONE 重启，也不代表 Windows 能起来。务必以实例状态检查和 RDP 实测为准。
  • 镜像与 Graviton 代际强绑定，不能跨代迁移。实测在 t4g（Graviton2）上 DD 成功的实例，打成 AMI 后启动 m8g（Graviton4）无法启动（UEFI 找不到可引导系统，陷入引导重试循环）。不同 Graviton 代际的 UEFI 固件、ACPI 表、CPU 特性不同。如需在 m8g 上运行，应直接在 m8g 实例上从头重做。

总结

这套方案本质是非官方玩法，AWS 不支持 Graviton 跑 Windows，仅适合做兼容性测试或临时验证，不能用于生产。最反直觉的一点：注入 AWS 官方 ARM64 NVMe 驱动反而起不来，靠微软 inbox StorNVMe 才能起来。建议复现时直接照本文跳过 NVMe 驱动注入。

参考

© 2026 Checo's Blog. All rights reserved.
Copyright © 2026 Checo