我正在尝试的步骤摘要:
- 从 Windows_Server_A 分离操作系统卷
- 将卷附加到 Windows_Server_B
- 修改无害文件
- 从 B 分离并重新连接到 Windows_Server_A 的 /dev/sda1
- 启动成功
这不起作用。连接/磁盘管理联机/脱机/分离过程导致卷在返回 Server_A 时无法启动
** 详细步骤**
- 从 EC2 Windows 2012 实例中分离操作系统卷。将其设为 Volume_X
- 将 Volume_X 附加到临时 EC2 Windows 实例
- 在临时 EC2 服务器的磁盘管理中,将新卷转为在线
- 请注意,有两个分区。一个小分区(350MB)没有驱动器号,一个大分区(100GB)。大分区分配有驱动器号:G
- 导航到 G 盘上的特定文件
- 修改文件
- 关闭所有窗口
- 在磁盘管理中将驱动器脱机
- 关闭临时 EC2 服务器
- 从临时服务器分离 Volume_X
- 将 Volume_X 重新附加到其原始服务器的挂载点 /dev/sda1
- 尝试启动原始服务器
该实例从未通过“初始化”并且转到实例设置 - 获取屏幕截图产生以下内容:
为了隔离问题,我尝试不修改文件:
- 使用 Volume_X 的全新工作副本。与原始服务器分离。连接到备用服务器。
- 我所做的只是将驱动器置于“在线”状态,然后 2 秒后将其置于“离线”状态,而没有修改驱动器上的任何数据。
- 重新连接到原始服务器会产生完全相同的问题
因此,看起来我只是简单地将 Volume_X 附加到单独的服务器上并将其置于“在线”状态(磁盘管理),从而损坏了它。
将 Windows 操作系统卷移动到另一台服务器进行文件修改,然后返回到其原始实例并成功启动的正确方法是什么?
所需步骤:
- 停止原有服务器
- 分离卷
- 将卷附加到备用服务器
- ?????然后修改一个文件然后?????
- 从备用服务器分离卷
- 将卷附加到原始服务器
- 原始服务器应该可以正常启动
谢谢你的时间
答案1
据我所知,Windows Server 2016 上的磁盘管理实用程序某物到引导分区(较小的~350MB)。通过 Server_B 的磁盘管理“联机”然后“脱机”后,它们根本无法运行。它们不再可在 Server_A 上引导。
我们的目标可以归结为:
- 停止服务器A
- 将操作系统卷作为数据卷移动到服务器 B
- 修改文件
- 将操作系统卷移回服务器 A 并成功启动
我们可以按如下方式实现它:
- 停止 Server_A。如果可能,请自然关闭。
- 从 Server_A 分离卷
- 将卷附加到 Linux Server_B。如有必要,您可以快速启动临时 Linux 实例。Ubuntu Server 对我来说效果很好。
sudo apt-get install ntfs-3g
- 确认已安装读写 NTFS 驱动程序。现在通常默认安装。- 运行
fdisk
以查找您感兴趣的分区的设备名称。我们正在寻找操作系统卷的非启动分区的标识符(100GB 分区,而不是 350MB 分区)。我的是 /dev/xvdf2。 sudo mkdir /mnt/ntfs_fix
建立挂载点sudo mount -t ntfs-3g /dev/xvdf2 /mnt/ntfs_fix
将分区挂载为读/写卷- 继续修改您的文件。Pico 非常适合编辑文本文件。
/mnt/ntfs_fix/windows/system32/config
我通过导航并运行chntpw -e SYSTEM
(修改 Windows 系统注册表值) 更改了注册表值chntpw reg 编辑文档- 完成更改后,请卸载。
sudo umount /dev/xvdf2
- 从 Server_B 分离卷
- 将卷附加到 Server_A
/dev/sda1
(对于 Windows EC2 OS 卷必须是 /dev/sda1) - 启动Server_A
笔记
- 如果一开始就需要强制停止 OS 卷,那么在尝试挂载到 Linux 服务器上时,您将收到错误。您可以使用
sudo ntfsfix /dev/xvdf2
将 NTFS 卷的状态从“未正确关闭”状态修复为“正确关闭”状态。然后它应该可以挂载。请记住,这有可能损坏您的卷,因此如果您可以通过从 Server_A 执行标准关机来避免这种情况,那么请执行此操作。否则,请确保您有当前备份。 - Linux 不会从启动卷 (350MB) 读取或写入数据,而 Windows Server 则会对其进行一些操作。这样,我们就可以只修改 OS 卷的 OS 分区,并在我们重新连接并从 Server_A 启动时维护一个可启动卷。