In LINUX: Using dd to transfer shrunk partitions on a 2TB HDD to a 500GB SSD

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












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










share|improve this question
























  • 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















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










share|improve this question
























  • 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












0








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










share|improve this question
















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







hard-disk dd ssd partclone






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 22 at 2:51







AllanGH

















asked Mar 3 at 0:37









AllanGHAllanGH

43




43












  • 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

















  • 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
















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





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





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





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





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




1





While using Unix tools, the core/goal of this question is windows specific

– Rui F Ribeiro
Mar 3 at 5:10





While using Unix tools, the core/goal of this question is windows specific

– Rui F Ribeiro
Mar 3 at 5:10










1 Answer
1






active

oldest

votes


















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.






share|improve this answer























    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504032%2fin-linux-using-dd-to-transfer-shrunk-partitions-on-a-2tb-hdd-to-a-500gb-ssd%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    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.






    share|improve this answer



























      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.






      share|improve this answer

























        0












        0








        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 19 at 7:47









        AllanGHAllanGH

        43




        43



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f504032%2fin-linux-using-dd-to-transfer-shrunk-partitions-on-a-2tb-hdd-to-a-500gb-ssd%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?