0

Summary of steps that I am attempting:

  • Detach OS volume from Windows_Server_A
  • Attach volume to Windows_Server_B
  • Modify a harmless file
  • Detach from B and reattach at /dev/sda1 for Windows_Server_A
  • Boot Successfully

This is not working. The attach / disk management online/offline / detach process is causing the volume to NOT boot when it returns to Server_A


** Detailed Steps**

  • Detach OS volume from EC2 windows 2012 instance. Let this be Volume_X
  • Attach Volume_X to a temporary EC2 windows instance
  • In Disk Management of temporary EC2 server, turn new volume online
  • Note that there are two partitions. One small one (350MB) without a drive letter and one large one (100GB). The large one gets a drive letter assigned: G
  • Navigate to a particular file on G drive
  • Modify the file
  • Close all windows
  • Turn drive offline in Disk Management
  • Shut down temporary EC2 server
  • Detach Volume_X from temporary server
  • Re-Attach Volume_X to its original server at mount point /dev/sda1
  • Attempt to boot original server
  • The instance never gets past "initialized" and going to Instance Settings - Get Screenshot yields the following:

    enter image description here


To isolate the problem, I tried without modifying a file:

  • With a fresh, working copy of Volume_X. Detach from Original server. Attach to alternate server.
  • All I did was turn the drive "online" and then 2 seconds later turned it "offline" without modifying any data on the drive.
  • Reattaching to the original server yields the same exact problem

Thus, it appears that I am corrupting Volume_X by simply attaching it and turning it "online" (disk management) on a separate server.


What is the proper way to move a windows OS volume to another server, for file modification, to then be returned to its original instance and successfully booted from?

Desired steps:

  • Stop original server
  • Detach volume
  • Attach volume to alternate server
  • ????? then modify a file then ?????
  • Detach volume from alternate server
  • Attach volume to original server
  • original server should boot fine

Thanks for your time

  • 1
    Rampant guesswork: If the volume has a common ancestry (AMIs/Snapshots) with a volume already on instance B, they might have a common identifier in the partition table or on a filesystem that blows the mind of Windows on system B causing it to mark the volume in some way that results in this behavior. Is this a possibility in your environment? – Michael - sqlbot Nov 6 '17 at 22:33
0

As best I can tell, the disk management utility on windows server 2016 does something to the boot partitions (the small ~350MB ones). They simply do not function after going "online" via Server_B's disk management and then "offline". They are no longer bootable on Server_A.

Since our goal boils down to:

  • Stop Server A
  • Move OS volume to Server B as a data volume
  • Modify files
  • Move OS volume back to Server A and successfully boot

We can accomplish it as follows:

  • Stop Server_A. Shutdown naturally if possible.
  • Detach volume from Server_A
  • Attach volume to Linux Server_B. You can spin up a temporary linux instance very quickly if necessary. Ubuntu Server worked well for me.
  • sudo apt-get install ntfs-3g - confirm that the read/write NTFS driver is installed. It is often installed by default now.
  • Run fdisk to find the device name for the partition that you are interested in. We are looking for the identifier for the non-boot partition of the operating system volume (the 100GB partition, not the 350MB partition). Mine was /dev/xvdf2.
  • sudo mkdir /mnt/ntfs_fix establish a mount point
  • sudo mount -t ntfs-3g /dev/xvdf2 /mnt/ntfs_fix mount the partition as a read/write volume
  • Proceed to modify your files. Pico is good for editing text files.
  • I changed a registry value by navigating to /mnt/ntfs_fix/windows/system32/config and running chntpw -e SYSTEM (to modify a windows system registry value) chntpw reg edit docs
  • When you are done making changes, unmount. sudo umount /dev/xvdf2
  • Detach volume from Server_B
  • Attach volume to Server_A as /dev/sda1 (must be /dev/sda1 for windows ec2 OS volume)
  • Start Server_A

Notes

  • If a forced stop of the OS volume was necessary at the beginning, Then you will receive an error when trying to mount on the linux server. You can use sudo ntfsfix /dev/xvdf2 to fix the status of the NTFS volume from a "shutdown improperly" state to a "shutdown properly" state. It should then be mountable. Keep in mind that this has the potential to damage your volume, so if you can avoid it by doing a standard shutdown from Server_A, then do it. Otherwise, make sure you have current backups.
  • Linux does not read or write from the boot volume (350MB) whereas windows server does something to it. In this way, we are able to modify only the OS-partition of the OS-volume and maintain a bootable volume for when we reattach and boot from Server_A.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.