Results 1 to 5 of 5
Thread: [SOLVED] Need help with dd !!!
Enjoy an ad free experience by logging in. Not a member yet? Register.
[SOLVED] Need help with dd !!!
dd if=/dev/hda3 conv=sync,noerror bs=64K | gzip -c > nc6000_linux_system.img.gz
gunzip -c nc6000_linux_system.img.gz | dd of=/dev/hda3 conv=sync,noerror bs=64K
dd: writing '/dev/hda3': No space left on device 3673+348340 records in 352012+0 records out 23069491200 bytes (23 GB) copied, 713.275 s, 32.3 MB/s
What am I doing wrong?
Can someone help me please? I do not understand if my partition image is faulty, or I do not know how to restore it.Fedora22.GNOME@Dell_Latitude_E7440
- Join Date
- Nov 2009
- San Diego, CA
I'm not a dd expert but looks like someone here had a similar problem.
The mistake you made was giving gunzip the file name so it'll perform the unzip in situ. This means that you'll need enough space in your current directory for both the zipped and unzipped files! Try
gunzip <partition.image.gz | dd bs=1M of=/dev/hda6
I'll try it.Fedora22.GNOME@Dell_Latitude_E7440
Recently, I found out that -c option in gunzip sends the data to std.out. That means the image is being unziped on the fly, no additional drive space is consumed (on the drive that holds the image).
In spite of the "No space left on device" message, the restore operation was successful and my system boots normally.
Still if someone has an explanation, I am interested to hear it.Fedora22.GNOME@Dell_Latitude_E7440
On LinuxQuestions.org I got an explanation:
Originally Posted by AwesomeMachine
In the command line to restore, dd is dependent on gunzip feeding it image data. Because of the sync parameter, dd pads the last block with zeroes to make it a full block. So dd keeps going after the image.gz file is written. No space left on device is not an error. Many uses of dd require the device to run out of space. It's not a problem. But the sync conversion is helpful for the method of backup you are using (gzip).Fedora22.GNOME@Dell_Latitude_E7440