cloning a linux image using dd
Clash Royale CLAN TAG#URR8PPP
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
add a comment |
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
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
add a comment |
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
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
linux devices dd images cloning
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
add a comment |
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
add a comment |
2 Answers
2
active
oldest
votes
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
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
add a comment |
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
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
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
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
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
add a comment |
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
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
add a comment |
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
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
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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