0

A source HDA (2TB mechanical HDD) has 5 partitions on it (GPT) that used to occupy the entire capacity of the 2TB HDA.

The Operating System resident on the source drive is Windows 10.

Since the majority of the 'data' partition was unused storage space, and occupied 1.5TB of the drive capacity, it was shrunk, using gparted, to about 350GB, and the 'Push Button Recovery' partition (above it on the source HDA) was moved downward to be contiguous with the data partition.

The resultant state of the source HDA is 5 partitions occupying less than 400GB on a 2TB HDA, with the excess storage space on the drive being unallocated space.

Proposed target device is a Samsung 500GB SDD, which is currently in an unallocated state (no partitions defined and no boot structures written to the drive).

Hypothesis:

I can use dd (bs=1M, no count parameter specified) to write directly from the source device to the target device, since the aggregate partition sizes on the source device amount to less than the capacity of the target device; and have only an anomalous condition in what will be the unallocated space that results on the target device, post transfer.

Addressing this anomalous unallocated region of the target device by relocating the 'Push Button Recovery' partition to the upper end of the drive space, and growing the data partition to fill the remainder of the unallocated space on the target device, using gparted should work and leave me with a bootable device.

Question:

I don't tinker with windows systems unless I get backed into a corner by somebody else (like a family member), so I do not have a great deal of intuition in dealing with such situations; so, can anybody see why this would produce a non-bootable target SSD before I waste the time doing this?

# # # # # UPDATE # # # # #

OK....I'm following-up on this--merely to let others know what ultimately worked in this particular situation:

Partition arrangement on the source HDD:
Partition   FS      Label                 Size    Flags
/dev/sdg1  ntfs     Recovery             600 MiB  hidden, diag
/dev/sdg2  fat32    ESP                  300 MiB  boot, esp
/dev/sdg3  unknown                       128 MiB  msftres
/dev/sdg4  NTFS     User Data Space      350 GiB  msftdata
/dev/sdg5  NTFS     Push Button Reset  16.61 GiB  hidden, diag
Unallocated --             --            1.5 TiB     --

Partition arrangement on the target SSD:
Partition   FS      Label                 Size    Flags
/dev/sdh1  ntfs     Recovery             600 MiB  hidden, diag
/dev/sdh2  fat32    ESP                  300 MiB  boot, esp
/dev/sdh3  unknown                       128 MiB  msftres
/dev/sdh4  NTFS     User Data Space   448.15 GiB  msftdata
/dev/sdh5  NTFS     Push Button Reset  16.61 GiB  hidden, diag

A lot of time was spent trying various approaches to addressing the issue at hand, with unsatisfactory results.

Because allocated time was expiring, the installed OS recovery facilities were used to create 'restore' media, and perform an OS recovery to the SSD installed in the host system.

With both drives attached to a Debian 8.5 based computer, partclone_0.2.73-2+b1 (partclone.ntfs) was used to write the user data partition from the source HDD to the the target SSD. (/dev/sdg4 to /dev/sdh4)

While a windows-agnostic solution is preferred, this method produces a bootable target SSD with all original user data intact, and mismatches between partition tables were avoided.

Info on partclone can be found at:

https://packages.debian.org/jessie/admin/partclone

https://packages.debian.org/stretch/admin/partclone

https://manpages.debian.org/testing/partclone/index.html

  • Do both drives have the same block size? You can check with fdisk If not then you may take a performance hit when using dd because the partitions (and filesystems) would be out of alignment with the block size of the SSD – Emmanuel Rosa Mar 3 at 1:44
  • On the 2TB HDA, Sector_logical / Sector_physical / IO_minimum / IO_optimal come back as: 512B / 4096B / 4096B / 4096B. On the 500GB SSD, Sector_logical / Sector_physical / IO_minimum / IO_optimal come back as: 512B / 512B / 512B / 512B. I would conclude that, given your inquiry, my best move would be to dd with a bs=512, rather than the 1M? – AllanGH Mar 3 at 1:58
  • what you suggest makes sense, but windows questions might be better asked on "superuser" – Jasen Mar 3 at 2:02
  • There are a plethora of SysAdmins, who manage Unix / Linux based environments with windoze clients, that may have run into this scenario when maintaining desktops in the cubicle pits. My question is directed to those individuals who have that level of administrative support--you know...the ones who can give an opinion based upon direct experience in that context--rather than begging for fanboyism. Re-titling the post for me, to give a false impression of the nature of my question, imposes a far from helpful filter on my inquiry, and is less than I expected from the userbase, here. – AllanGH Mar 3 at 4:31
  • 1
    While using Unix tools, the core/goal of this question is windows specific – Rui F Ribeiro Mar 3 at 5:10
0

OK....following Kusalananda's recommendation, I've shared what worked for me, in this situation, as an update to my original post, and will refrain from duplicating what I typed, up there, in this space.

Seemingly, the method, detailed above, will not be easily implemented if ready access to, or the means of creating, restore media is not available. So the utility of this method is self-evidently limited; but it did resolve the issue at hand.

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.