cloning a linux image using dd

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












0















If I wish to clone my linux image using the dd utility, I can do for example dd if=/dev/SDX of=/dev/SDY , where SDX is the internal memory device where the linux image is stored, and SDY is the external memory device I would like to copy it to.



However if I do this without cloning to a different memory device and use the same internal memory, example : dd if=/dev/SDX of=/home/my_dir/my_image.img , this is creating an image file in the same internal memory device that the actual image resides. This seems to work fine for me, but how does it? /home/my_dir/ is inside /dev/SDX which I am cloning?










share|improve this question
























  • why not just copy the relevant files instead of the entire image?

    – StrongBad
    Jan 25 at 20:39











  • @StrongBad I need a complete clone of my image to distribute to others

    – Engineer999
    Jan 25 at 20:45











  • <pre> this shouldnt work. you cannot put an 8G image inside the same filesystem with 6G of free space. possible explanation: if=/dev/SDX has read errors (bad sector, or alike) and output image is smaller than the disk. try again the dd with:

    – FabioM
    Jan 25 at 22:09











  • @KamilMaciorowski Someone suggested edits for my post and appended /my_image.img to /dev/SDX . I reverted now

    – Engineer999
    Jan 30 at 12:40












  • @KamilMaciorowski Sorry I edited my question now as it was completely messed up by the suggested edits

    – Engineer999
    Jan 30 at 12:53















0















If I wish to clone my linux image using the dd utility, I can do for example dd if=/dev/SDX of=/dev/SDY , where SDX is the internal memory device where the linux image is stored, and SDY is the external memory device I would like to copy it to.



However if I do this without cloning to a different memory device and use the same internal memory, example : dd if=/dev/SDX of=/home/my_dir/my_image.img , this is creating an image file in the same internal memory device that the actual image resides. This seems to work fine for me, but how does it? /home/my_dir/ is inside /dev/SDX which I am cloning?










share|improve this question
























  • why not just copy the relevant files instead of the entire image?

    – StrongBad
    Jan 25 at 20:39











  • @StrongBad I need a complete clone of my image to distribute to others

    – Engineer999
    Jan 25 at 20:45











  • <pre> this shouldnt work. you cannot put an 8G image inside the same filesystem with 6G of free space. possible explanation: if=/dev/SDX has read errors (bad sector, or alike) and output image is smaller than the disk. try again the dd with:

    – FabioM
    Jan 25 at 22:09











  • @KamilMaciorowski Someone suggested edits for my post and appended /my_image.img to /dev/SDX . I reverted now

    – Engineer999
    Jan 30 at 12:40












  • @KamilMaciorowski Sorry I edited my question now as it was completely messed up by the suggested edits

    – Engineer999
    Jan 30 at 12:53













0












0








0








If I wish to clone my linux image using the dd utility, I can do for example dd if=/dev/SDX of=/dev/SDY , where SDX is the internal memory device where the linux image is stored, and SDY is the external memory device I would like to copy it to.



However if I do this without cloning to a different memory device and use the same internal memory, example : dd if=/dev/SDX of=/home/my_dir/my_image.img , this is creating an image file in the same internal memory device that the actual image resides. This seems to work fine for me, but how does it? /home/my_dir/ is inside /dev/SDX which I am cloning?










share|improve this question
















If I wish to clone my linux image using the dd utility, I can do for example dd if=/dev/SDX of=/dev/SDY , where SDX is the internal memory device where the linux image is stored, and SDY is the external memory device I would like to copy it to.



However if I do this without cloning to a different memory device and use the same internal memory, example : dd if=/dev/SDX of=/home/my_dir/my_image.img , this is creating an image file in the same internal memory device that the actual image resides. This seems to work fine for me, but how does it? /home/my_dir/ is inside /dev/SDX which I am cloning?







linux devices dd images cloning






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 30 at 12:52







Engineer999

















asked Jan 25 at 20:18









Engineer999Engineer999

1526




1526












  • why not just copy the relevant files instead of the entire image?

    – StrongBad
    Jan 25 at 20:39











  • @StrongBad I need a complete clone of my image to distribute to others

    – Engineer999
    Jan 25 at 20:45











  • <pre> this shouldnt work. you cannot put an 8G image inside the same filesystem with 6G of free space. possible explanation: if=/dev/SDX has read errors (bad sector, or alike) and output image is smaller than the disk. try again the dd with:

    – FabioM
    Jan 25 at 22:09











  • @KamilMaciorowski Someone suggested edits for my post and appended /my_image.img to /dev/SDX . I reverted now

    – Engineer999
    Jan 30 at 12:40












  • @KamilMaciorowski Sorry I edited my question now as it was completely messed up by the suggested edits

    – Engineer999
    Jan 30 at 12:53

















  • why not just copy the relevant files instead of the entire image?

    – StrongBad
    Jan 25 at 20:39











  • @StrongBad I need a complete clone of my image to distribute to others

    – Engineer999
    Jan 25 at 20:45











  • <pre> this shouldnt work. you cannot put an 8G image inside the same filesystem with 6G of free space. possible explanation: if=/dev/SDX has read errors (bad sector, or alike) and output image is smaller than the disk. try again the dd with:

    – FabioM
    Jan 25 at 22:09











  • @KamilMaciorowski Someone suggested edits for my post and appended /my_image.img to /dev/SDX . I reverted now

    – Engineer999
    Jan 30 at 12:40












  • @KamilMaciorowski Sorry I edited my question now as it was completely messed up by the suggested edits

    – Engineer999
    Jan 30 at 12:53
















why not just copy the relevant files instead of the entire image?

– StrongBad
Jan 25 at 20:39





why not just copy the relevant files instead of the entire image?

– StrongBad
Jan 25 at 20:39













@StrongBad I need a complete clone of my image to distribute to others

– Engineer999
Jan 25 at 20:45





@StrongBad I need a complete clone of my image to distribute to others

– Engineer999
Jan 25 at 20:45













<pre> this shouldnt work. you cannot put an 8G image inside the same filesystem with 6G of free space. possible explanation: if=/dev/SDX has read errors (bad sector, or alike) and output image is smaller than the disk. try again the dd with:

– FabioM
Jan 25 at 22:09





<pre> this shouldnt work. you cannot put an 8G image inside the same filesystem with 6G of free space. possible explanation: if=/dev/SDX has read errors (bad sector, or alike) and output image is smaller than the disk. try again the dd with:

– FabioM
Jan 25 at 22:09













@KamilMaciorowski Someone suggested edits for my post and appended /my_image.img to /dev/SDX . I reverted now

– Engineer999
Jan 30 at 12:40






@KamilMaciorowski Someone suggested edits for my post and appended /my_image.img to /dev/SDX . I reverted now

– Engineer999
Jan 30 at 12:40














@KamilMaciorowski Sorry I edited my question now as it was completely messed up by the suggested edits

– Engineer999
Jan 30 at 12:53





@KamilMaciorowski Sorry I edited my question now as it was completely messed up by the suggested edits

– Engineer999
Jan 30 at 12:53










2 Answers
2






active

oldest

votes


















2














Indeed, this seems to work fine – with the emphasis on "seems".



To simplify the explanation, I assume a legacy filesystem without journaling (like ext2).

As soon as dd starts, the file my_image.img is created. The information that this file exists and where it physically resides on the disk, is stored in the filesystem's index (think of it like a "table of contents"). The file's final size is not yet known, so it takes up a minimal default size (this is usually not shown to the user application).

As data is written to the file, it grows and the index is updated on regular intervals. However, the index resides on the disk, too. Once dd copied the index, the index in the copy is no longer updated. If you actually tried using the copy, you would notice that it is incomplete.



All this is academical of course, as dd cannot fit the full image file inside itself (unless you employ some kind of compression).



With commands like these, you can try it for yourself:



dd if=/dev/zero of=demo.raw bs=1M count=256 # create a dummy "partition" for demonstration
mkfs.ext4 demo.raw # create ext4 filesystem
target=$(mktemp -d) # create a temporary mountpoint
sudo mount demo.raw $target # mount the filesystem
sudo chown $USER $target # make filesystem root writable for current user
dd if=demo.raw of=$target/inner.raw bs=1M # copy fileystem into itself – error as expected (no space left on device)
rm $target/inner.raw
dd if=demo.raw bs=1M | gzip -c > $target/inner.raw.gz # copy fileystem into itself, using compression
gzip -c $target/inner.raw.gz > inner.raw # decompress image
sudo mount inner.raw /mnt # mount inner copy – error as expected (copy is an incomplete file)
sudo umount $target
rm demo.raw inner.raw





share|improve this answer

























  • Even by piping and compressing it using gzip as I done before also, how does this even work , because we are copying the 8GB image, compressing it and storing it in the same file system which we are cloning. I understand how it works when copying to a different medium, but not inside its own medium, if you understand what I mean

    – Engineer999
    Jan 25 at 23:06











  • You ponder how this could work. But your feeling is correct – it does not actually work. I updated my answer.

    – Hermann
    Jan 27 at 0:20











  • I have tried it this way dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz and it works (appears to work fine), so i'm confused even more

    – Engineer999
    Jan 27 at 1:30


















0














this shouldnt work.
you cannot put an 8G RAW image inside the same filesystem with 6G of free space.
possible explanation: /dev/SDX has read errors (bad sector, or alike), and dd stopped before reaching the end of the disk, resulting in the output image smaller than the disk (so it fits). try again the dd with:



# dd if=/dev/SDX oflag=direct conv=noerror,notrunc of=/path/image.img


and also check the size of disk:



# df -h


and the size of the generated image:



# ls -lh /path/image.img





share|improve this answer

























  • Even if I copy and compress it like this : dd if=/dev/sdX | gzip -c > path/my_image.img.gz , how does it still work because my confusion is not about the file size but the fact that we are copying a linux image into the same file system which we are cloning?

    – Engineer999
    Jan 26 at 2:24











  • Let's say for example this : dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz . Isn't /home/my_dir inside the file system in /dev/sdX ?? I'm confused with this

    – Engineer999
    Jan 26 at 9:59












  • Yes, the image file is inside the filesystem you created an image of. And the copy won't be usable (for the reasons I mentioned in my answer).

    – Hermann
    Jan 27 at 0:22










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%2f496744%2fcloning-a-linux-image-using-dd%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









2














Indeed, this seems to work fine – with the emphasis on "seems".



To simplify the explanation, I assume a legacy filesystem without journaling (like ext2).

As soon as dd starts, the file my_image.img is created. The information that this file exists and where it physically resides on the disk, is stored in the filesystem's index (think of it like a "table of contents"). The file's final size is not yet known, so it takes up a minimal default size (this is usually not shown to the user application).

As data is written to the file, it grows and the index is updated on regular intervals. However, the index resides on the disk, too. Once dd copied the index, the index in the copy is no longer updated. If you actually tried using the copy, you would notice that it is incomplete.



All this is academical of course, as dd cannot fit the full image file inside itself (unless you employ some kind of compression).



With commands like these, you can try it for yourself:



dd if=/dev/zero of=demo.raw bs=1M count=256 # create a dummy "partition" for demonstration
mkfs.ext4 demo.raw # create ext4 filesystem
target=$(mktemp -d) # create a temporary mountpoint
sudo mount demo.raw $target # mount the filesystem
sudo chown $USER $target # make filesystem root writable for current user
dd if=demo.raw of=$target/inner.raw bs=1M # copy fileystem into itself – error as expected (no space left on device)
rm $target/inner.raw
dd if=demo.raw bs=1M | gzip -c > $target/inner.raw.gz # copy fileystem into itself, using compression
gzip -c $target/inner.raw.gz > inner.raw # decompress image
sudo mount inner.raw /mnt # mount inner copy – error as expected (copy is an incomplete file)
sudo umount $target
rm demo.raw inner.raw





share|improve this answer

























  • Even by piping and compressing it using gzip as I done before also, how does this even work , because we are copying the 8GB image, compressing it and storing it in the same file system which we are cloning. I understand how it works when copying to a different medium, but not inside its own medium, if you understand what I mean

    – Engineer999
    Jan 25 at 23:06











  • You ponder how this could work. But your feeling is correct – it does not actually work. I updated my answer.

    – Hermann
    Jan 27 at 0:20











  • I have tried it this way dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz and it works (appears to work fine), so i'm confused even more

    – Engineer999
    Jan 27 at 1:30















2














Indeed, this seems to work fine – with the emphasis on "seems".



To simplify the explanation, I assume a legacy filesystem without journaling (like ext2).

As soon as dd starts, the file my_image.img is created. The information that this file exists and where it physically resides on the disk, is stored in the filesystem's index (think of it like a "table of contents"). The file's final size is not yet known, so it takes up a minimal default size (this is usually not shown to the user application).

As data is written to the file, it grows and the index is updated on regular intervals. However, the index resides on the disk, too. Once dd copied the index, the index in the copy is no longer updated. If you actually tried using the copy, you would notice that it is incomplete.



All this is academical of course, as dd cannot fit the full image file inside itself (unless you employ some kind of compression).



With commands like these, you can try it for yourself:



dd if=/dev/zero of=demo.raw bs=1M count=256 # create a dummy "partition" for demonstration
mkfs.ext4 demo.raw # create ext4 filesystem
target=$(mktemp -d) # create a temporary mountpoint
sudo mount demo.raw $target # mount the filesystem
sudo chown $USER $target # make filesystem root writable for current user
dd if=demo.raw of=$target/inner.raw bs=1M # copy fileystem into itself – error as expected (no space left on device)
rm $target/inner.raw
dd if=demo.raw bs=1M | gzip -c > $target/inner.raw.gz # copy fileystem into itself, using compression
gzip -c $target/inner.raw.gz > inner.raw # decompress image
sudo mount inner.raw /mnt # mount inner copy – error as expected (copy is an incomplete file)
sudo umount $target
rm demo.raw inner.raw





share|improve this answer

























  • Even by piping and compressing it using gzip as I done before also, how does this even work , because we are copying the 8GB image, compressing it and storing it in the same file system which we are cloning. I understand how it works when copying to a different medium, but not inside its own medium, if you understand what I mean

    – Engineer999
    Jan 25 at 23:06











  • You ponder how this could work. But your feeling is correct – it does not actually work. I updated my answer.

    – Hermann
    Jan 27 at 0:20











  • I have tried it this way dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz and it works (appears to work fine), so i'm confused even more

    – Engineer999
    Jan 27 at 1:30













2












2








2







Indeed, this seems to work fine – with the emphasis on "seems".



To simplify the explanation, I assume a legacy filesystem without journaling (like ext2).

As soon as dd starts, the file my_image.img is created. The information that this file exists and where it physically resides on the disk, is stored in the filesystem's index (think of it like a "table of contents"). The file's final size is not yet known, so it takes up a minimal default size (this is usually not shown to the user application).

As data is written to the file, it grows and the index is updated on regular intervals. However, the index resides on the disk, too. Once dd copied the index, the index in the copy is no longer updated. If you actually tried using the copy, you would notice that it is incomplete.



All this is academical of course, as dd cannot fit the full image file inside itself (unless you employ some kind of compression).



With commands like these, you can try it for yourself:



dd if=/dev/zero of=demo.raw bs=1M count=256 # create a dummy "partition" for demonstration
mkfs.ext4 demo.raw # create ext4 filesystem
target=$(mktemp -d) # create a temporary mountpoint
sudo mount demo.raw $target # mount the filesystem
sudo chown $USER $target # make filesystem root writable for current user
dd if=demo.raw of=$target/inner.raw bs=1M # copy fileystem into itself – error as expected (no space left on device)
rm $target/inner.raw
dd if=demo.raw bs=1M | gzip -c > $target/inner.raw.gz # copy fileystem into itself, using compression
gzip -c $target/inner.raw.gz > inner.raw # decompress image
sudo mount inner.raw /mnt # mount inner copy – error as expected (copy is an incomplete file)
sudo umount $target
rm demo.raw inner.raw





share|improve this answer















Indeed, this seems to work fine – with the emphasis on "seems".



To simplify the explanation, I assume a legacy filesystem without journaling (like ext2).

As soon as dd starts, the file my_image.img is created. The information that this file exists and where it physically resides on the disk, is stored in the filesystem's index (think of it like a "table of contents"). The file's final size is not yet known, so it takes up a minimal default size (this is usually not shown to the user application).

As data is written to the file, it grows and the index is updated on regular intervals. However, the index resides on the disk, too. Once dd copied the index, the index in the copy is no longer updated. If you actually tried using the copy, you would notice that it is incomplete.



All this is academical of course, as dd cannot fit the full image file inside itself (unless you employ some kind of compression).



With commands like these, you can try it for yourself:



dd if=/dev/zero of=demo.raw bs=1M count=256 # create a dummy "partition" for demonstration
mkfs.ext4 demo.raw # create ext4 filesystem
target=$(mktemp -d) # create a temporary mountpoint
sudo mount demo.raw $target # mount the filesystem
sudo chown $USER $target # make filesystem root writable for current user
dd if=demo.raw of=$target/inner.raw bs=1M # copy fileystem into itself – error as expected (no space left on device)
rm $target/inner.raw
dd if=demo.raw bs=1M | gzip -c > $target/inner.raw.gz # copy fileystem into itself, using compression
gzip -c $target/inner.raw.gz > inner.raw # decompress image
sudo mount inner.raw /mnt # mount inner copy – error as expected (copy is an incomplete file)
sudo umount $target
rm demo.raw inner.raw






share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 27 at 0:21

























answered Jan 25 at 21:14









HermannHermann

817513




817513












  • Even by piping and compressing it using gzip as I done before also, how does this even work , because we are copying the 8GB image, compressing it and storing it in the same file system which we are cloning. I understand how it works when copying to a different medium, but not inside its own medium, if you understand what I mean

    – Engineer999
    Jan 25 at 23:06











  • You ponder how this could work. But your feeling is correct – it does not actually work. I updated my answer.

    – Hermann
    Jan 27 at 0:20











  • I have tried it this way dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz and it works (appears to work fine), so i'm confused even more

    – Engineer999
    Jan 27 at 1:30

















  • Even by piping and compressing it using gzip as I done before also, how does this even work , because we are copying the 8GB image, compressing it and storing it in the same file system which we are cloning. I understand how it works when copying to a different medium, but not inside its own medium, if you understand what I mean

    – Engineer999
    Jan 25 at 23:06











  • You ponder how this could work. But your feeling is correct – it does not actually work. I updated my answer.

    – Hermann
    Jan 27 at 0:20











  • I have tried it this way dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz and it works (appears to work fine), so i'm confused even more

    – Engineer999
    Jan 27 at 1:30
















Even by piping and compressing it using gzip as I done before also, how does this even work , because we are copying the 8GB image, compressing it and storing it in the same file system which we are cloning. I understand how it works when copying to a different medium, but not inside its own medium, if you understand what I mean

– Engineer999
Jan 25 at 23:06





Even by piping and compressing it using gzip as I done before also, how does this even work , because we are copying the 8GB image, compressing it and storing it in the same file system which we are cloning. I understand how it works when copying to a different medium, but not inside its own medium, if you understand what I mean

– Engineer999
Jan 25 at 23:06













You ponder how this could work. But your feeling is correct – it does not actually work. I updated my answer.

– Hermann
Jan 27 at 0:20





You ponder how this could work. But your feeling is correct – it does not actually work. I updated my answer.

– Hermann
Jan 27 at 0:20













I have tried it this way dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz and it works (appears to work fine), so i'm confused even more

– Engineer999
Jan 27 at 1:30





I have tried it this way dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz and it works (appears to work fine), so i'm confused even more

– Engineer999
Jan 27 at 1:30













0














this shouldnt work.
you cannot put an 8G RAW image inside the same filesystem with 6G of free space.
possible explanation: /dev/SDX has read errors (bad sector, or alike), and dd stopped before reaching the end of the disk, resulting in the output image smaller than the disk (so it fits). try again the dd with:



# dd if=/dev/SDX oflag=direct conv=noerror,notrunc of=/path/image.img


and also check the size of disk:



# df -h


and the size of the generated image:



# ls -lh /path/image.img





share|improve this answer

























  • Even if I copy and compress it like this : dd if=/dev/sdX | gzip -c > path/my_image.img.gz , how does it still work because my confusion is not about the file size but the fact that we are copying a linux image into the same file system which we are cloning?

    – Engineer999
    Jan 26 at 2:24











  • Let's say for example this : dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz . Isn't /home/my_dir inside the file system in /dev/sdX ?? I'm confused with this

    – Engineer999
    Jan 26 at 9:59












  • Yes, the image file is inside the filesystem you created an image of. And the copy won't be usable (for the reasons I mentioned in my answer).

    – Hermann
    Jan 27 at 0:22















0














this shouldnt work.
you cannot put an 8G RAW image inside the same filesystem with 6G of free space.
possible explanation: /dev/SDX has read errors (bad sector, or alike), and dd stopped before reaching the end of the disk, resulting in the output image smaller than the disk (so it fits). try again the dd with:



# dd if=/dev/SDX oflag=direct conv=noerror,notrunc of=/path/image.img


and also check the size of disk:



# df -h


and the size of the generated image:



# ls -lh /path/image.img





share|improve this answer

























  • Even if I copy and compress it like this : dd if=/dev/sdX | gzip -c > path/my_image.img.gz , how does it still work because my confusion is not about the file size but the fact that we are copying a linux image into the same file system which we are cloning?

    – Engineer999
    Jan 26 at 2:24











  • Let's say for example this : dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz . Isn't /home/my_dir inside the file system in /dev/sdX ?? I'm confused with this

    – Engineer999
    Jan 26 at 9:59












  • Yes, the image file is inside the filesystem you created an image of. And the copy won't be usable (for the reasons I mentioned in my answer).

    – Hermann
    Jan 27 at 0:22













0












0








0







this shouldnt work.
you cannot put an 8G RAW image inside the same filesystem with 6G of free space.
possible explanation: /dev/SDX has read errors (bad sector, or alike), and dd stopped before reaching the end of the disk, resulting in the output image smaller than the disk (so it fits). try again the dd with:



# dd if=/dev/SDX oflag=direct conv=noerror,notrunc of=/path/image.img


and also check the size of disk:



# df -h


and the size of the generated image:



# ls -lh /path/image.img





share|improve this answer















this shouldnt work.
you cannot put an 8G RAW image inside the same filesystem with 6G of free space.
possible explanation: /dev/SDX has read errors (bad sector, or alike), and dd stopped before reaching the end of the disk, resulting in the output image smaller than the disk (so it fits). try again the dd with:



# dd if=/dev/SDX oflag=direct conv=noerror,notrunc of=/path/image.img


and also check the size of disk:



# df -h


and the size of the generated image:



# ls -lh /path/image.img






share|improve this answer














share|improve this answer



share|improve this answer








edited Jan 30 at 12:50









Vlastimil

8,0721464138




8,0721464138










answered Jan 25 at 22:15









FabioMFabioM

513




513












  • Even if I copy and compress it like this : dd if=/dev/sdX | gzip -c > path/my_image.img.gz , how does it still work because my confusion is not about the file size but the fact that we are copying a linux image into the same file system which we are cloning?

    – Engineer999
    Jan 26 at 2:24











  • Let's say for example this : dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz . Isn't /home/my_dir inside the file system in /dev/sdX ?? I'm confused with this

    – Engineer999
    Jan 26 at 9:59












  • Yes, the image file is inside the filesystem you created an image of. And the copy won't be usable (for the reasons I mentioned in my answer).

    – Hermann
    Jan 27 at 0:22

















  • Even if I copy and compress it like this : dd if=/dev/sdX | gzip -c > path/my_image.img.gz , how does it still work because my confusion is not about the file size but the fact that we are copying a linux image into the same file system which we are cloning?

    – Engineer999
    Jan 26 at 2:24











  • Let's say for example this : dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz . Isn't /home/my_dir inside the file system in /dev/sdX ?? I'm confused with this

    – Engineer999
    Jan 26 at 9:59












  • Yes, the image file is inside the filesystem you created an image of. And the copy won't be usable (for the reasons I mentioned in my answer).

    – Hermann
    Jan 27 at 0:22
















Even if I copy and compress it like this : dd if=/dev/sdX | gzip -c > path/my_image.img.gz , how does it still work because my confusion is not about the file size but the fact that we are copying a linux image into the same file system which we are cloning?

– Engineer999
Jan 26 at 2:24





Even if I copy and compress it like this : dd if=/dev/sdX | gzip -c > path/my_image.img.gz , how does it still work because my confusion is not about the file size but the fact that we are copying a linux image into the same file system which we are cloning?

– Engineer999
Jan 26 at 2:24













Let's say for example this : dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz . Isn't /home/my_dir inside the file system in /dev/sdX ?? I'm confused with this

– Engineer999
Jan 26 at 9:59






Let's say for example this : dd if=/dev/sdX | gzip -c > /home/my_dir/my_image.img.gz . Isn't /home/my_dir inside the file system in /dev/sdX ?? I'm confused with this

– Engineer999
Jan 26 at 9:59














Yes, the image file is inside the filesystem you created an image of. And the copy won't be usable (for the reasons I mentioned in my answer).

– Hermann
Jan 27 at 0:22





Yes, the image file is inside the filesystem you created an image of. And the copy won't be usable (for the reasons I mentioned in my answer).

– Hermann
Jan 27 at 0:22

















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%2f496744%2fcloning-a-linux-image-using-dd%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?

Bahrain

Postfix configuration issue with fips on centos 7; mailgun relay