Resize a partition image with GParted?

Question

I've resized partitions in GParted before. Now I'd like to move a large but mostly empty partition to a smaller drive. Instead of resizing it in place, I'd prefer to make a copy on a 3rd drive (drive image using dd), resize the copy, and then dd the copy to the new drive. But I don't think Gparted operates on drive images? How would I do this? Can I use the tools GParted uses directly?

Ooh! Or can I use a loopback thing to make the image file look like a physical drive that gparted can operate on?

Answer 1

You can't do this with GParted, but you can use the ntfsresize command directly on a disk image.

First, clone the disk image. You can find the disk device name using blkid or gParted, and then run:

sudo dd if=<disk device> of=<image file>

For example:

$ sudo dd if=/dev/sda2 of=disk.img
1000000+0 records in
1000000+0 records out
512000000 bytes (512 MB) copied, 9.33361 s, 54.9 MB/s

Then, verify if you can resize it to the size you need by running:

ntfsresize -i <image file>

For instance:

$ ntfsresize -i disk.img
ntfsresize v2011.4.12 (libntfs-3g)
Device name        : disk.img
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 511996416 bytes (512 MB)
Current device size: 512000000 bytes (512 MB)
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use       : 4 MB (0.6%)
Collecting resizing constraints ...
You might resize at 3035136 bytes or 4 MB (freeing 508 MB).
Please make a test run using both the -n and -s options before real resizing!

In this example, I can resize all the way down to 4MB because I just made a blank disk image for illustration purposes!

Now you can do the test run if you'd like, although it's not strictly necessary since you're operating on an image. You can specify the size in kilobytes, megabytes, or gigabytes by appending a k, M, or G, respectively:

ntfsresize -cnvs <size> <image file>

For instance:

$ ntfsresize -cnvs 256M disk.img 
ntfsresize v2011.4.12 (libntfs-3g)

No output is good output! Now do it for real:

ntfsresize -vs <size> <image file>

Last example:

$ ntfsresize -vs 256M disk.img 
ntfsresize v2011.4.12 (libntfs-3g)
Device name        : disk.img
NTFS volume version: 3.1
Cluster size       : 4096 bytes
Current volume size: 511996416 bytes (512 MB)
Current device size: 512000000 bytes (512 MB)
New volume size    : 255996416 bytes (256 MB)
Checking for bad sectors ...
Checking filesystem consistency ...
100.00 percent completed
Accounting clusters ...
Space in use       : 4 MB (0.6%)
Collecting resizing constraints ...
Needed relocations : 625 (3 MB)
WARNING: Every sanity check passed and only the dangerous operations left.
Make sure that important data has been backed up! Power outage or computer
crash may result major data loss!
Are you sure you want to proceed (y/[n])? y
Schedule chkdsk for NTFS consistency check at Windows boot time ...
Resetting $LogFile ... (this might take a while)
Relocating needed data ...
Relocate record       1:0x80:00000001:0x00000000:0x0000f423 --> 0x00007a11
Relocate record       2:0x80:00000624:0x00000000:0x0000f424 --> 0x00007a12
100.00 percent completed
Updating $BadClust file ...
Updating $Bitmap file ...
Updating Boot record ...
Syncing device ...
Successfully resized NTFS on device 'disk.img'.
You can go on to shrink the device for example with Linux fdisk.
IMPORTANT: When recreating the partition, make sure that you
  1)  create it at the same disk sector (use sector as the unit!)
  2)  create it with the same partition type (usually 7, HPFS/NTFS)
  3)  do not make it smaller than the new NTFS filesystem size
  4)  set the bootable flag for the partition if it existed before
Otherwise you won't be able to access NTFS or can't boot from the disk!
If you make a mistake and don't have a partition table backup then you
can recover the partition table by TestDisk or Parted's rescue mode.

That's it! Now you can copy that disk image to the new device.

Answer 2

I'm not sure what the situation was 5 years ago, but today it's cake.

$ sudo udisksctl loop-setup -f disk.img
Mapped file disk.img as /dev/loop0.
$ gparted /dev/loop0
$ sudo udisksctl loop-delete -d /dev/loop0

To grow or shrink the disk after you could use truncate -s. Keep in mind that this would wipe out any backup partition table at the end of the disk, or other data if not used properly.

The benefit this has over using losetup is that it shows which loop device is assigned. It also looks at the partition table and sets up a loop device for each partition. That is not particularly useful for using gparted on the disk, but makes it super easy to take an image of a drive and mount a specific partition within that image.

Answer 3

As a preparation, check the list of filesystem blocks on your system by running lsblk

Use losetup to create a loop block device from the disk image ( hereafter called disk.img )

sudo losetup --find --partscan disk.img

then run lsblk to see the list of blocks that are currently on your system. Compare the output with the previous output of lsblk and whatever is new is your loop block device. Use that to call gparted and proceed with the resizing operation.

sudo gparted /dev/loopXX

PS. using udisksctl loop-setup --file disk.img does create a loop device for you to work with but, you can't resize this loop device using gparted as it will be a mounted filesystem. You can try unmounting it but as soon as you do that the loop device disappears and you're left with no loop device to call gparted.

Answer 4

Could you resize it in place with GParted then use Clonezilla to move the partition to the new disk?

Answer 5

I have been using GParted for many, many years, and never lost a bit. I also like Easus free home edition for Windows.

How large/small is your partition? Can you copy the data to USB/DVD/a free online storage system, so as not to lose it - and then resize in place? The two aforementioned tools will not lose your data if you let them run to completion.

You say I've resized partitions in GParted before - so why the worry now? And DD will make a bit for bit copy... so you will have to resize anyway (defrag first).