By jgrump2012


2018-08-12 17:40:58 8 Comments

I've seen numerous questions, answers, and guides relating to use of dd, cat, and clonezilla to facilitate partition and device cloning. Rather than continue those discussions I'm hoping to give very targeted questions to dd behavior within this post.

I'm using Ubuntu 18.04 LTS live, booted from USB. I have a 500gb HDD with Windows7 (/dev/sda). I've resized the partitions such that slightly more than 420gb is unallocated. I aim to backup the boot table and partitions to a 120gb SSD (/dev/sdb). The SSD has no partitions and shows 110gb unallocated.

sudo dd if=/dev/sda of=/dev/sdb hits failure and conveys 'No space left on device'. Spot checking partitions using gparted, I see /dev/sdb contains the same partitions, labels, size, and unused. The only noticeable difference is unallocated space.

I am able to boot Windows from the SSD but am left with a few questions related to dd behavior.

  • did dd attempt to copy device content which was not allocated?
  • does dd have an order of operations? (something like partition 1->99, then misc drive blocks)
  • by chance have I just been lucky so far in my immediate use of this Windows drive? am I being overly paranoid in thinking the drive is missing content?

For what it's worth, I do plan to retain the HDD for the foreseeable future.

2 comments

@Thomas 2018-08-13 05:17:46

Johan Myréen eloquently explained why your approach resulted in an error. There are a couple of workarounds to copy a drive to a smaller one with dd:

  • As suggested by mikeserv, instead of copying the entire device (/dev/sda), you could just copy the specific partition that contains your data of interest, e.g. /dev/sda1. This has a couple of disadvantages: You have to know which partition contains your data, and if you wipe the original drive and want to restore it, you will need to first recreate the original partition structure (ideally you have notes of what it looked like) and then restore the specific partition. (Any of this is potentially error-prone.) If you plan to run your Windows from the SSD, this is probably your best option (although Windows sometimes objects to hardware changes and wants to be reinstalled, but that is apparently not a problem in this case).
  • If you don't mind storing the content of your drive in compressed form, you can try something like sudo dd if=/dev/sda bs=1M | gzip > /path/to/mounted/backup-drive/sda_backup.gz (if the backup file is not user-writeable, either use sudo -i for a root shell or wrap the entire command with sudo sh -c 'command'; I am setting bs because the default of 512 bytes is inefficient for large amounts of data; instead of gzip you can also use other compression programs). This can be restored with zcat sda_backup.gz | dd of=/dev/sdx bs=1M, but you cannot boot from the partition and even mounting it is tricky (see this question for an interesting discussion of this aspect; the answer by doug65536 also discusses "zero-washing" to improve the compression ratio).

The problem with your current state of affairs is that you have copied the partition table from the large drive to the smaller one, which means it effectively contains wrong information about anything beyond 120 GB, and although that does not prevent you from from booting and using the partition, it is not ideal. You could try to just fix the partition table with something like gparted (much quicker than recopying) and hope that nothing else got borked, or start from scratch.

@Johan Myréen 2018-08-12 19:05:29

dd does not know anything about partitions or any other structure on the disk. It doesn't recognize "allocated" or "unallocated" parts of the disk. From dd's point of view, a device given as parameter consists of a series of blocks. Thus, if you run dd if=/dev/sda of=/dev/sdb, dd will copy blocks starting from the beginning of /dev/sda to the correspondingly numbered blocks on /dev/sdb, until it has read all blocks from /dev/sda or until it hits an error. In your example, because /dev/sdb was smaller in size than /dev/sda, dd was terminated with the error message "No space left on device" (on /dev/sdb).

@mikeserv 2018-08-12 19:09:26

maybe recommend ..sda1 and etc?

@Carcer 2018-08-12 22:52:43

@mikeserv in the specific use case of the querent, I would actually recommend just sticking with the raw block devices and letting dd run till it hits the error; you want the copied disk to be bootable, and creating the partitions manually is much more faff.

@jgrump2012 2018-08-13 02:31:52

Thanks @johan-myréen, this is helpful to understand. Hopefully it's ok to give a followup here. Prior to execution I had used gparted to resize the large drive. Given this, can we establish confidence that the blocks on /dev/sda were reordered such that they were first to be copied during dd execution?

Related Questions

Sponsored Content

1 Answered Questions

No space left on device (Ubuntu 16.04.5)

1 Answered Questions

Ubuntu won't login after disk migration

10 Answered Questions

[SOLVED] Can I label a disk device rather than a partition?

1 Answered Questions

[SOLVED] Parted: how to solve Location outside of device error?

1 Answered Questions

[SOLVED] sda and sdb keep on swapping

  • 2017-04-30 08:55:22
  • Chris Becke
  • 709 View
  • 3 Score
  • 1 Answer
  • Tags:   ubuntu fstab uuid

0 Answered Questions

How do I unmount a disk device and remove its device association

1 Answered Questions

Win10/Ubuntu16.04 dual boot errors

1 Answered Questions

[SOLVED] Can't format HDDs and install linux to Dell hybrid ultrabook

1 Answered Questions

[SOLVED] Prevent USB storage from using different device on reset

2 Answered Questions

Sponsored Content