0

I ran ubuntu off a usb stick to make images of partitions of a hard drive, I used GNU ddrescue, which is effectively like dd. The source drive (the drive I made images from), was 160GB.

how can I take images of NTFS partitions made with dd on one sized drive, and write them to another drive of a different size? The drive I want to write the images to is 1TB.

I'm wary of writing the partition to another drive's partition, then finding that sizes don't match and even resizing it might not work besides I don't really want to have to resize partitions anyway.

I thought perhaps there may be a way to convert a dd image to a macrium image, so I tried mounting the image with OSFmount, and right clicking the mounted partition and clicking to create an image in macrium reflect, but macrium didn't see it 'cos macrium seems to only work when there's an actual physical disk drive in there that it is creating an image from, not on just a virtual partition.

So how do you write a raw image, made from dd, to a partition of another drive?

  • Do you have a whole-disk image or just individual partition images? – grawity Aug 19 at 5:36
  • IIRC you only need to ensure that the partitions are the exact same size, i.e. number of sectors. If the destination partition is a bit larger, then the extra space is simply never used, unless you resize the partition. – sawdust Aug 19 at 5:37
  • @grawity individual partition images – barlop Aug 19 at 6:17
  • @sawdust I don't want the partitions to be the exact same size. I want the ones on the target drive to be bigger – barlop Aug 19 at 6:19
  • 1
    You can copy the partition first, and then resize the partition/filesystem. There is no way to do each partition in one step. – sawdust Aug 19 at 6:26
1

The last time I did something similar, I booted the PC with a Linux LiveCD that was customized to include a copy of GParted.
A new MBR and partition table was installed on the target drive (using GParted).
For each partition on the source drive:

  • Create a new partition on the target drive that is at least the same size as the original (using GParted or fdisk).
    The closer you get to the exact number of sectors as the original the better, i.e. less chance of any issues with the transplanted filesystem.

  • Copy the partition from (or the partition image of) the original drive to the target drive using dd.

  • Resize the target partition to your new requirement (using GParted).
    The filesystem within the partition will be adjusted commensurately.
    Increasing the size should be rather quick.

  • Repeat for the next partition.


ADDENDUM

But Gparted has no option to make a partition hidden.

Your assertion is incorrect.
First select a partition.
Then from the menu bar, select Partition, and choose Manage Flags from the dropdown menu.
From there you can enable/disable an assortment of partition flags, including "hidden".

It also has no option to convert primary to logical ...

That is a questionable conversion that is best performed by basic operations.
A logical partition requires that it exists within an extended partition.
Automatically creating an extended partition does have ramifications, including available size and impact on subsequent operations.

Note the ability to create more than one extended partition depends on the tool and need to be portable. For Windows compatibility there can only be one extended partition.

... so if one copies an image onto a partition then wants to change a partition from primary to logical, they have to delete the partition and recreate it as logical and copy on again

The steps that I described above clearly state that the destination partition should be created prior to writing/copying the image.
If the target partition needs to be a logical partition, then first make sure there is already an extended partition, and then create the logical partition.
If you create a primary partition when the original was a logical partition, then you are simply botching the copy procedure.

Converting a primary partition to a logical partition is a bogus operation.


ADDENDUM 2

Suppose I don't know if the original was a primary or a logical, because e.g. the original hard drive is messed up.
So would you still say that if you create a primary instead of a logical then it's a botched copy procedure and therefore understandable that one has to copy again?

At what point and how did you determine that the destination partition should be a logical partition?

Given those answers, what is the reason why that determination could not have been available prior to creating the destination partition as a primary partition?


really the copy procedure is separate from creating partitions, and ...

Not in my procedure.
Each destination partition is created to its original size.
After the filesystem (i.e. the partition image) is written to the new partition, then it (the partition and filesystem) is resized.
This procedure relies on GParted knowing how to resize the filesystem contained within the partition.
I do not have to look-up/learn any filesystem commands on how to fit a filesystem to its partition. That task is assigned to GParted.


if there was an option to convert then one would not have to copy again –

The conversion from primary to logical partition is not as simple (or convenient) as you presume.

This web page describes a utility capable of "primary partition to logical partition" with just a mouse click or two.
The gotcha is revealed in this salient comment at the end of the article:

The location and the size of the primary partition will be slightly different after 
converting due to the fact that the logical partition is 63 sectors bigger 
than primary partition.

(That is poorly worded because it's hard to tell if the "63 sectors bigger" refers to the location or to the size of the logical partition (or both?). The change in "location" certainly makes sense. So I'm quite sure that if the writer was referring to the size, then he got the size difference backwards, otherwise that means that the conversion consumes more disk space than the original. There is simply no reason to increase the size of the resulting partition.)

Aside from the change(?) in partition size, the ramifications of this statement confirm that a time-consuming copy of the partition will occur.
The time to perform this copy will require about twice the time you could simply recreate the logical partition and write the image.

Why's that, you ask?

You start with a primary partition.
A logical partition has to be enveloped within an extended partition.
So the start of the original (primary) partition has to be pushed back to create space for the (start of the) new extended partition.
In theory just one sector could suffice, but the convention is one track, or the fake HDD geometry of 63 sectors.

In order to create this free space, the original (primary) partition (and its filesystem) first has to be reduced in size by 63 sectors at the end of the partition (assuming that this conversion consumes zero new disk space).
Then the original (primary) partition (and its filesystem) has to be moved back 63 sectors.
This move entails a time-consuming read and write of every sector of the partition.
Once the move is complete, the extended partition can be created in the newly freed area, and the original partition can be redefined as a logical partition.

This partition conversion procedure is not going to save you any time when you already have an image to write.

The only way to avoid the time-consuming copy during conversion would be to use a program that "cheats" and requires an unallocated track preceding the existing primary partition, such as this utility:

Note: ... there should be at least 63 free sectors in front of the primary partition 
when changing it to logical.

also, you write "The closer you get to the exact number of sectors as the original the better, i.e. less chance of any issues with the transplanted filesystem." <-- can you elaborate on this?

That is simply my attempt to replicate the original partition.
There could be allocation round-off, and you cannot create the partition with the exact same number of sectors as the original partition (or size of the image).
So round up the number of sectors to the next allocation step.

As in if I don't get it close and then I resize it, what would that mean and what would happen?
would it mean that the resized partition will still remain a different size to the file system?

GParted has not complained when there is a small discrepancy between partition size and its filesystem.
After resizing by GParted, the filesystem seems to fully occupy the partition.
I have not experimented with the scenario you describe, so I don't have an answer.

  • gparted looks pretty limited.. e.g. one partition on my friend's acer laptop is a 10GB partition with the label PQSERVICE which is a recovery partition on acer laptops. And it's hidden. But Gparted has no option to make a partition hidden. It also has no option to convert primary to logical so if one copies an image onto a partition then wants to change a partition from primary to logical, they have to delete the partition and recreate it as logical and copy on again – barlop Aug 21 at 10:40
  • @barlop -- Your complaints are addressed as an addendum above. – sawdust Aug 21 at 23:02
  • Suppose I don't know if the original was a primary or a logical, because e.g. the original hard drive is messed up. So would you still say that if you create a primary instead of a logical then it's a botched copy procedure and therefore understandable that one has to copy again? really the copy procedure is separate from creating partitions, and if there was an option to convert then one would not have to copy again – barlop Aug 22 at 3:50
  • also, you write "The closer you get to the exact number of sectors as the original the better, i.e. less chance of any issues with the transplanted filesystem." <-- can you elaborate on this? As in if I don't get it close and then I resize it, what would that mean and what would happen? would it mean that the resized partition will still remain a different size to the file system? – barlop Aug 22 at 4:48
  • @barlop -- See new addendum for response – sawdust Aug 22 at 9:56
1

When it comes to Windows, dd and other 3rd party tools are not an efficient way to image a partition.

  • Windows has always natively supported imaging of partitions or individual directories..
    • The system partition can only be imaged from WinPE/WinRE, while all other partitions are able to be imaged while booted to Windows.
    • WIMs (Windows IMage) can be captured of an entire partition or individual folders/files.
      Create a WimScript.ini config file to specify exclusions or exceptions.

  • All WinPE/WinRE WIMs have either ImageX or DISM included within them.

    • WinPE: Windows Preinstallation Environment

      • Such as a Windows Setup boot media (SHIFT + F10 to access terminal)
    • WinRE: Windows Recovery Environment


Commands

WinPE only has 32MB of scratch [temp] space by default, so /ScratchDir is required

  • Windows >=8: DISM is utilized to capture an image:

    DISM /Capture-Image /ImageFile:"Z:\Base.wim" /CaptureDir:"C:" /Name:"Windows Backup" /Description:"Base Image 2019.08.24 @ 08:30" /Compress:Max /CheckIntegrity /Verify /NoRpFix /ScratchDir:"Z:\"
    
  • Windows <=7: ImageX is utilized in lieu of DISM:

    ImageX /Capture "C:" "Z:\Base.esd" "Windows Backup" "Base Image 2019.08.24 @ 08:30" /Compress:Recovery /Check /Verify /NoRpFix /ScratchDir:"Z:\"
    



NOTE:

  • It's impossible for an ESD/WIM image to become corrupted
    • Provided imaging commands are always issued with:
      • DISM: /CheckIntegrity & /Verify
      • ImageX: /Check & /Verify

  • ESDs can only be taken of a system partition
    • /Compress:Recovery is the only compression algorithm available.
      • ESD compression ratio is ~33% more efficient than the WIM compression ratio.
      • In Windows 10, Microsoft only allows ESDs for Push-Button Reset exported images

  • ESDs/WIMs are smart compression image formats
    • Only changed files are added to an image when a new image is appended to it
      • Newly appended images utilize the same copy of unchanged files already contained within the image from the previous image(s).
        • This allows for an image to remain small in relation to the data contained within.



DISM & ImageX Prerequisites


Example: /Get-WIMinfo || /Info

PS $  ls -file

  Directory: Z:\WIM

    Mode                LastWriteTime            Length  Name
    ----                -------------            ------  ----
    -a----        2018.12.24 03:34:13   95,019,530,773B  Base.wim
    -a----        2016.06.14 22:32:36              568B  DISM.cmd
    -a----        2016.05.17 05:36:10               97B  wimscript.ini

PS $  dism /get-wiminfo /wimfile:Base.wim

  Deployment Image Servicing and Management tool
  Version: 10.0.18362.1

    Details for image : Base.wim

    Index : 1
      Name : Alienware 18: Windows 10
      Description : v1803: Base (Drivers Only)
      Size : 22,710,283,446 bytes

    Index : 2
      Name : Alienware 18: Windows 10
      Description : v1803: Software Installed (No Customizations)
      Size : 45,591,850,754 bytes

    Index : 3
      Name : Alienware 18: Windows 10
      Description : v1803: Software Installed (Customized)
      Size : 94,958,267,312 bytes

    Index : 4
      Name : Alienware 18: Windows 10
      Description : v1803: Software Group 1 Installed (Customized)
      Size : 101,588,267,910 bytes

    Index : 5
      Name : Alienware 18: Windows 10
      Description : v1803: Software Group 2 Installed (Customized)
      Size : 101,905,314,237 bytes

    Index : 6
      Name : Alienware 18: Windows 10
      Description : v1809: Updated Applications
      Size : 114,959,954,040 bytes

  The operation completed successfully.
PS $  dism /get-wiminfo /wimfile:Base.wim /index:1

  Deployment Image Servicing and Management tool
  Version: 10.0.18362.1

    Details for image : Base.wim

      Index : 1
      Name : Alienware 18: Windows 10
      Description : v1803: Base (Drivers Only)
      Size : 22,710,283,446 bytes
      WIM Bootable : No
      Architecture : x64
      Hal : acpiapic
      Version : 10.0.17134
      ServicePack Build : 1
      ServicePack Level : 1
      Edition : Professional
      Installation : Client
      ProductType : WinNT
      ProductSuite : Terminal Server
      System Root : WINDOWS
      Directories : 24288
      Files : 112665
      Created : 2018.05.05 - 13:56:47
      Modified : 2018.05.05 - 13:56:47
      Languages :
              en-US (Default)

  The operation completed successfully.


PS $  dism /get-wiminfo /wimfile:Base.wim /index:2

  Deployment Image Servicing and Management tool
  Version: 10.0.18362.1

    Details for image : Base.wim

      Index : 2
      Name : Alienware 18: Windows 10
      Description : v1803: Software Installed (No Customizations)
      Size : 45,591,850,754 bytes
      WIM Bootable : No
      Architecture : x64
      Hal : acpiapic
      Version : 10.0.17134
      ServicePack Build : 1
      ServicePack Level : 1
      Edition : Professional
      Installation : Client
      ProductType : WinNT
      ProductSuite : Terminal Server
      System Root : WINDOWS
      Directories : 45803
      Files : 203058
      Created : 2018.05.06 - 01:55:47
      Modified : 2018.05.06 - 01:55:48
      Languages :
              en-US (Default)

  The operation completed successfully.


PS $  dism /get-wiminfo /wimfile:Base.wim /index:3

  Deployment Image Servicing and Management tool
  Version: 10.0.18362.1

    Details for image : Base.wim

      Index : 3
      Name : Alienware 18: Windows 10
      Description : v1803: Software Installed (Customized)
      Size : 94,958,267,312 bytes
      WIM Bootable : No
      Architecture : x64
      Hal : acpiapic
      Version : 10.0.17134
      ServicePack Build : 1
      ServicePack Level : 81
      Edition : Professional
      Installation : Client
      ProductType : WinNT
      ProductSuite : Terminal Server
      System Root : WINDOWS
      Directories : 62409
      Files : 350446
      Created : 2018.06.01 - 19:09:51
      Modified : 2018.06.19 - 21:26:18
      Languages :
              en-US (Default)

  The operation completed successfully.


PS $  dism /get-wiminfo /wimfile:Base.wim /index:4

  Deployment Image Servicing and Management tool
  Version: 10.0.18362.1

    Details for image : Base.wim

      Index : 4
      Name : Alienware 18: Windows 10
      Description : v1803: Software Group 1 Installed (Customized)
      Size : 101,588,267,910 bytes
      WIM Bootable : No
      Architecture : x64
      Hal : acpiapic
      Version : 10.0.17134
      ServicePack Build : 1
      ServicePack Level : 81
      Edition : Professional
      Installation : Client
      ProductType : WinNT
      ProductSuite : Terminal Server
      System Root : WINDOWS
      Directories : 61908
      Files : 346074
      Created : 2018.06.08 - 21:54:02
      Modified : 2018.06.19 - 21:26:18
      Languages :
              en-US (Default)

  The operation completed successfully.


PS $  dism /get-wiminfo /wimfile:Base.wim /index:5

  Deployment Image Servicing and Management tool
  Version: 10.0.18362.1

    Details for image : Base.wim

      Index : 5
      Name : Alienware 18: Windows 10
      Description : v1803: Software Group 2 Installed (Customized)
      Size : 101,905,314,237 bytes
      WIM Bootable : No
      Architecture : x64
      Hal : acpiapic
      Version : 10.0.17134
      ServicePack Build : 1
      ServicePack Level : 81
      Edition : Professional
      Installation : Client
      ProductType : WinNT
      ProductSuite : Terminal Server
      System Root : WINDOWS
      Directories : 76113
      Files : 423408
      Created : 2018.06.09 - 20:38:36
      Modified : 2018.06.19 - 21:26:18
      Languages :
              en-US (Default)

  The operation completed successfully.


PS $  dism /get-wiminfo /wimfile:Base.wim /index:6

  Deployment Image Servicing and Management tool
  Version: 10.0.18362.1

    Details for image : Base.wim

      Index : 6
      Name : Alienware 18: Windows 10
      Description : v1809: Updated Applications
      Size : 114,959,954,040 bytes
      WIM Bootable : No
      Architecture : x64
      Hal : acpiapic
      Version : 10.0.17763
      ServicePack Build : 195
      ServicePack Level : 0
      Edition : Professional
      Installation : Client
      ProductType : WinNT
      ProductSuite : Terminal Server
      System Root : WINDOWS
      Directories : 87659
      Files : 452028
      Created : 2018.12.24 - 04:27:13
      Modified : 2018.12.24 - 04:27:15
      Languages :
              en-US (Default)

  The operation completed successfully.
  • You write "Windows > 8" and "Windows < 7" What about Windows 7? If sometimes where you've written > you mean >= or if where you've written < you mean <= then could you please correct that – barlop Aug 24 at 23:34
  • You write "Windows has always natively supported imaging of partitions or individual directories.." <-- I just tested on a Windows 7 does it natively have imagex, and it doesn't. So i'm sure that certainly XP or 9X wouldn't have had it. Also, docs.microsoft.com/en-us/previous-versions/windows/it-pro/… was written in 2008 and says "ImageX is a command-line tool in Windows Vista" B4 Vista there was XP(which many people used for some years even after Vista), many use a good version of windows for nearly a decade, and versions of win were around long b4 XP – barlop Aug 24 at 23:41
  • Perhaps you mean that imagex is native to WinPE?(rather than native to windows?). I see WinPE began with XP en.wikipedia.org/wiki/Windows_Preinstallation_Environment many used BartPE in those days.. and WinPE became free in the Windows 7 days hardforum.com/threads/new-alternatives-to-bartpe.1803055 – barlop Aug 24 at 23:50
  • I see that DISM is native to windows 10 though.. but imagex is not native to windows 7 though imagex would apparently be in win7 PE. – barlop Aug 25 at 3:18
  • 1
    @barlop Great points =] I've addressed the following: > to >= and < to <= ; Windows 7 requires installation of Windows 7 AIK forimagex, which has been annotated (natively means it's not a 3rd party tool, whereas default would be including it by default - Microsoft placed the tools within the Windows AIK/ADK, which I've never understood since they're a valuable tool for more than just Win deployment) ; All Win ver. <7 are obsolete & no longer supported (and should no longer be being utilized), which is why I didn't address Vista or XP, but ImageX did exist for Vista and XP. – JW0914 Aug 25 at 11:26
0

Gparted uses a command ntfsresize and.. I see two ways of doing it in Gparted..

Method 1

An option in gparted, gparted calls the option 'check'!

One way, is that Gparted actually identifies when the file system is smaller than the partition, and it puts an exclamation mark there

enter image description here

you can right click that partition(i.e. the row gparted shows for that partition) and go to information and it says there is that mismatch and where the option is to fix it..

enter image description here

And the option to fix it is if you right click the partition and click 'check'

And based on the information given by gparted for the commands it gives, the commands it runs are some fairly straight forward ntfsresize commands, straightforward in that they don't even involve having to specify to ntfssize how many MB or MiB.

enter image description here

Method 2

This method is similar to what sawdust said.

Any time you resize a partition in Gparted, it resizes the file system to fill the whole thing.

If in gparted you increase the size of the partition by even a very small amount e.g. 1MB, then gparted will expand the file system.


Note- Regardless of those two methods, the gparted 'check' or the gparted resize, there are things to consider if the partition has Windows.. because there's a system reserved partition that needs to be on the hard drive and if that's not there, then no windows 7/10 can load at all. And it'd be the active partition.

Note2- Another method is to use fdisk rather than resizing a partition. That involves deleting a partition and recreating it with the same starting point but a different size. And using ntfsresize for the file system resizing. And taking into account whether dealing with MB or MiB.

Gparted has options for 'boot'(a crucial option, making a partition active), and 'hidden' under what it calls 'flags'.

Related link- How to resize an NTFS volume to fill the partition? Lots of good info on related methods here.

  • i'm also considering creating partitions for windows, from the windows installation media, incase it also adds anything to the system reserved partition..i'll look into this. – barlop Aug 23 at 12:16

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.