How can I copy three partitions of my disk with a specific beginning and ending using dd?
Clash Royale CLAN TAG#URR8PPP
Using the fdisk -l
command I got the following answer:
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 28266495 14132224 27 Hidden NTFS WinRE
/dev/sda2 28268544 28473343 102400 7 HPFS/NTFS/exFAT
/dev/sda3 28473344 132552703 52039680 7 HPFS/NTFS/exFAT
/dev/sda4 * 132556798 625141759 246292481 5 Extended
/dev/sda5 193996800 198092799 2048000 82 Linux swap / Solaris
/dev/sda6 234960896 625141759 195090432 7 HPFS/NTFS/exFAT
/dev/sda7 198094848 234950316 18427734+ 83 Linux
/dev/sda8 132556800 183756018 25599609+ 83 Linux
I'd like to copy the three first partitions of my disk in an image using the dd
command. So I mounted an external hard drive, entered in its folder and typed:
# dd count=$((132552703-2048)) if=/dev/sda of=./newImage.image
But this command copied all the sda disk to my external hard drive instead of just copying until the end of the sda3 partition.
How can I use the dd
to create an image that starts at the beginning of sda1 and finishes at the end of sda3?
shell partition dd
add a comment |
Using the fdisk -l
command I got the following answer:
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 28266495 14132224 27 Hidden NTFS WinRE
/dev/sda2 28268544 28473343 102400 7 HPFS/NTFS/exFAT
/dev/sda3 28473344 132552703 52039680 7 HPFS/NTFS/exFAT
/dev/sda4 * 132556798 625141759 246292481 5 Extended
/dev/sda5 193996800 198092799 2048000 82 Linux swap / Solaris
/dev/sda6 234960896 625141759 195090432 7 HPFS/NTFS/exFAT
/dev/sda7 198094848 234950316 18427734+ 83 Linux
/dev/sda8 132556800 183756018 25599609+ 83 Linux
I'd like to copy the three first partitions of my disk in an image using the dd
command. So I mounted an external hard drive, entered in its folder and typed:
# dd count=$((132552703-2048)) if=/dev/sda of=./newImage.image
But this command copied all the sda disk to my external hard drive instead of just copying until the end of the sda3 partition.
How can I use the dd
to create an image that starts at the beginning of sda1 and finishes at the end of sda3?
shell partition dd
try with dd bs=2048 count=$(( (132552703-2048)/204)) your other arg
– Archemar
Jul 12 '15 at 5:31
add a comment |
Using the fdisk -l
command I got the following answer:
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 28266495 14132224 27 Hidden NTFS WinRE
/dev/sda2 28268544 28473343 102400 7 HPFS/NTFS/exFAT
/dev/sda3 28473344 132552703 52039680 7 HPFS/NTFS/exFAT
/dev/sda4 * 132556798 625141759 246292481 5 Extended
/dev/sda5 193996800 198092799 2048000 82 Linux swap / Solaris
/dev/sda6 234960896 625141759 195090432 7 HPFS/NTFS/exFAT
/dev/sda7 198094848 234950316 18427734+ 83 Linux
/dev/sda8 132556800 183756018 25599609+ 83 Linux
I'd like to copy the three first partitions of my disk in an image using the dd
command. So I mounted an external hard drive, entered in its folder and typed:
# dd count=$((132552703-2048)) if=/dev/sda of=./newImage.image
But this command copied all the sda disk to my external hard drive instead of just copying until the end of the sda3 partition.
How can I use the dd
to create an image that starts at the beginning of sda1 and finishes at the end of sda3?
shell partition dd
Using the fdisk -l
command I got the following answer:
Device Boot Start End Blocks Id System
/dev/sda1 * 2048 28266495 14132224 27 Hidden NTFS WinRE
/dev/sda2 28268544 28473343 102400 7 HPFS/NTFS/exFAT
/dev/sda3 28473344 132552703 52039680 7 HPFS/NTFS/exFAT
/dev/sda4 * 132556798 625141759 246292481 5 Extended
/dev/sda5 193996800 198092799 2048000 82 Linux swap / Solaris
/dev/sda6 234960896 625141759 195090432 7 HPFS/NTFS/exFAT
/dev/sda7 198094848 234950316 18427734+ 83 Linux
/dev/sda8 132556800 183756018 25599609+ 83 Linux
I'd like to copy the three first partitions of my disk in an image using the dd
command. So I mounted an external hard drive, entered in its folder and typed:
# dd count=$((132552703-2048)) if=/dev/sda of=./newImage.image
But this command copied all the sda disk to my external hard drive instead of just copying until the end of the sda3 partition.
How can I use the dd
to create an image that starts at the beginning of sda1 and finishes at the end of sda3?
shell partition dd
shell partition dd
edited Jan 27 at 19:08
Rafael Muynarsk
asked Jul 12 '15 at 3:21
Rafael MuynarskRafael Muynarsk
427616
427616
try with dd bs=2048 count=$(( (132552703-2048)/204)) your other arg
– Archemar
Jul 12 '15 at 5:31
add a comment |
try with dd bs=2048 count=$(( (132552703-2048)/204)) your other arg
– Archemar
Jul 12 '15 at 5:31
try with dd bs=2048 count=$(( (132552703-2048)/204)) your other arg
– Archemar
Jul 12 '15 at 5:31
try with dd bs=2048 count=$(( (132552703-2048)/204)) your other arg
– Archemar
Jul 12 '15 at 5:31
add a comment |
3 Answers
3
active
oldest
votes
first of all, here's how:
First do almost as you did before, but no subtraction - and add one to the count.
dd count=132552704 </dev/sda >img
Next print the partition table at a
sed
process which can screen out the ones which you're removing.sed
will write ad
elete command to a secondfdisk
which has opened yourimg
file for every partition from sda4 and on.fdisk -l img | sed -e'/sda4 /,$id' -e'g;$aw' | fdisk img
There is no 3. You're done.
secondly, here's why:
A Partial Success...
I'm pretty sure your command almost worked, but I'm willing to bet that it worked better than you think.
I expect that when you say it copied all of sda you believe that because an
fdisk -l
of that image indicated all of the partitions were included within. Based on thedd
command in your question, though, provided/dev/sda
's sector size is the fairly standard 512 bytes (and therefore identical todd
's default blocksize) then you should have copied everything from byte 0 of/dev/sda
only through to all but the last 2k sectors of/dev/sda3
.
About Sectors...
You can see below where the
fdisk
output reports on Units. That is the size of each sector thatfdisk
reports on. A disk sector might be 4096-bytes - if it is a very recently manufactured disk and handles the Advanced Format sector-size - otherwise it is very rare to find a disk not partitioned on a standard logical 512-byte sector-size.This is how
fdisk
'sman
page puts it:
-u
,--units[=unit]
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
-u
option by a space, the correct form is for example-u=cylinders
.
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
There's more on this here.
And something about
dd
, too...dd
cannot silently lose data. In fact, if a short read occurs,dd
is specified to be very vocal about it:
A partial input block is one for which
read()
returned less than the input block size. A partial output block is one that was written with fewer bytes than specified by the output block size...
...when there is at least one truncated block, the number of truncated blocks shall be written to standard error...
"%u truncated %sn"
,<number of truncated blocks>
,"record[s]"
Block i/o...
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
lseek()
for files existing on block-devices - it's a very basic principle of blocked i/o.
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
To sum up...
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
/dev/sda
will contain its entire partition table, and as such you would have copied said partition table to your image, and so anfdisk -l
of your image would report for all partitions of/dev/sda
, whether or not the data for those partitions actually resides within that image-file. You can, instead, of course, justcat
the separate data partitions separately into separate image files if you like - but in that case you lose the partition table entirely. All you really have to do is delete the partitions which you did not copy, and make sure you copy all of those you do.
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
third, here's how I know:
This will create an 4G
./img
file full of NULs.</dev/zero >./img
dd ibs=8k obs=8kx1b count=1kx1b524288+0 records in
1024+0 records out
4294967296 bytes (4.3 GB) copied, 3.53287 s, 1.2 GB/sThis will partition
./img
to match your disk up to the first three partitions but on a 1/16th scale:(set "$((p=0))" 28266495 27
28268544 28473343 2\n7
28473344 132552703 3\n7
while [ "$#" -ge "$((p+=1))" ]
do printf "nnpn$pn%.0dn%dntn%bn"
"$(($1/16))" "$(($2/16))" "$3"
shift 3
done; echo w
)| fdisk ./img >/dev/nullAnd so now we can look at it.
fdisk -l ./img
Disk ./img: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5659b81c
Device Boot Start End Sectors Size Id Type
./img1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFATI'll also put some actual filesystems and files on the three partitions.
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mkfs.vfat "$p"
mount "$p" mnt
echo "my part# is $p##*p"
>./mnt/"part$p##*p"
sync; umount mnt
done' "$PWD/img" 'losetup -D'Here are the byte offsets for where it all wound up...
grep -Ebao '(my[^0-9]*|PART)[123]' <./img
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2
917656608:PART3
917660672:my part# is 3
But did you notice that fdisk
was perfectly happy to report on the partitions' sizes before ever we formatted them with filesystems? This is because the partition table lies at the very head of the disk - it's only a layout and nothing more. None of the partitions need actually exist to be reported. They're only logically mapped out within the first 1M of ./img
. Watch:
Let's try getting only the first two partitions off of
./img
...<./img >./img2 dd count=1779583
1779583+0 records in
1779583+0 records out
911146496 bytes (911 MB) copied, 1.84985 s, 493 MB/sWe'll
grep
it again...grep -Ebao '(my[^0-9]*|PART)[123]' <./img2
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2And get an
fdisk
report...fdisk -l ./img2
Disk ./img2: 869 MiB, 911146496 bytes, 1779583 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcbcab4d8
Device Boot Start End Sectors Size Id Type
./img2p1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2p2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img2p3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFAT
Now that is curious. fdisk
still seems to believe there's a third partition extending as far out as 4G for a disk which it also seems to believe is only 869M in size!
Probably we should remove that third partition from the partition table.
printf %s\n d 3 w |
fdisk ./img2 >/dev/nullAnd now lets see if we can mount the partitions we copied and if our files remain in tact...
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mount "$p" mnt
grep . /dev/null ./mnt/*
umount mnt
done' "$PWD/img2" 'losetup -D'./mnt/part1:my part# is 1
./mnt/part2:my part# is 2
Apparently it's not impossible.
add a comment |
It isn't possible because dd is only direct 1 input to 1 output --the restoration would be damage because you merged 3 partitions in one and this isn't a backup and dd is only for identical copies.
Your answer would be possible:
dd if=/dev/sda1 of=~/hdadisk1.img;
dd if=/dev/sda2 of=~/hdadisk2.img
dd if=/dev/sda3 of=~/hdadisk3.img
(In a script if you want) and finally, you can to create an image with the hdadisk1,3,3.img although is a better practice you save these images in a partition for backups.
add a comment |
dd count=$((132552703-2048))
copies 132552703-2048 blocks of 512 bytes from the beginning of the input. The block size in fdisk
is 1 kB = 1024 bytes. So you have three problems:
- You specified a size that's half what you wanted.
- You didn't indicate that you wanted to start the copy at an offset.
- Your subtraction has a fencepost error: it misses the last block — the number of blocks is (end block offset) - (start block offset) + 1.
So you can do that copy with
dd bs=1k skip=2048 count=$((132552703-2048+1)) if=/dev/sda of=./newImage.image
I think this will work — dd
can silently lose data, but I think that 1kB blocks on a block device or regular file on Linux is fine. But it's slow.
The most straightforward way to copy a single partition would be to just copy it.
cat /dev/sda1 >sda1.image
cat /dev/sda2 >sda2.image
cat /dev/sda3 >sda3.image
It would be better to copy the partitions to separate files, because otherwise the partitions that aren't at the beginning of the file will be hard to use. If you really want the three partitions in the same file, you can concatenate them:
cat /dev/sda1 /dev/sda2 /dev/sda3 >newImage.image
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%2f215359%2fhow-can-i-copy-three-partitions-of-my-disk-with-a-specific-beginning-and-ending%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
first of all, here's how:
First do almost as you did before, but no subtraction - and add one to the count.
dd count=132552704 </dev/sda >img
Next print the partition table at a
sed
process which can screen out the ones which you're removing.sed
will write ad
elete command to a secondfdisk
which has opened yourimg
file for every partition from sda4 and on.fdisk -l img | sed -e'/sda4 /,$id' -e'g;$aw' | fdisk img
There is no 3. You're done.
secondly, here's why:
A Partial Success...
I'm pretty sure your command almost worked, but I'm willing to bet that it worked better than you think.
I expect that when you say it copied all of sda you believe that because an
fdisk -l
of that image indicated all of the partitions were included within. Based on thedd
command in your question, though, provided/dev/sda
's sector size is the fairly standard 512 bytes (and therefore identical todd
's default blocksize) then you should have copied everything from byte 0 of/dev/sda
only through to all but the last 2k sectors of/dev/sda3
.
About Sectors...
You can see below where the
fdisk
output reports on Units. That is the size of each sector thatfdisk
reports on. A disk sector might be 4096-bytes - if it is a very recently manufactured disk and handles the Advanced Format sector-size - otherwise it is very rare to find a disk not partitioned on a standard logical 512-byte sector-size.This is how
fdisk
'sman
page puts it:
-u
,--units[=unit]
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
-u
option by a space, the correct form is for example-u=cylinders
.
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
There's more on this here.
And something about
dd
, too...dd
cannot silently lose data. In fact, if a short read occurs,dd
is specified to be very vocal about it:
A partial input block is one for which
read()
returned less than the input block size. A partial output block is one that was written with fewer bytes than specified by the output block size...
...when there is at least one truncated block, the number of truncated blocks shall be written to standard error...
"%u truncated %sn"
,<number of truncated blocks>
,"record[s]"
Block i/o...
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
lseek()
for files existing on block-devices - it's a very basic principle of blocked i/o.
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
To sum up...
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
/dev/sda
will contain its entire partition table, and as such you would have copied said partition table to your image, and so anfdisk -l
of your image would report for all partitions of/dev/sda
, whether or not the data for those partitions actually resides within that image-file. You can, instead, of course, justcat
the separate data partitions separately into separate image files if you like - but in that case you lose the partition table entirely. All you really have to do is delete the partitions which you did not copy, and make sure you copy all of those you do.
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
third, here's how I know:
This will create an 4G
./img
file full of NULs.</dev/zero >./img
dd ibs=8k obs=8kx1b count=1kx1b524288+0 records in
1024+0 records out
4294967296 bytes (4.3 GB) copied, 3.53287 s, 1.2 GB/sThis will partition
./img
to match your disk up to the first three partitions but on a 1/16th scale:(set "$((p=0))" 28266495 27
28268544 28473343 2\n7
28473344 132552703 3\n7
while [ "$#" -ge "$((p+=1))" ]
do printf "nnpn$pn%.0dn%dntn%bn"
"$(($1/16))" "$(($2/16))" "$3"
shift 3
done; echo w
)| fdisk ./img >/dev/nullAnd so now we can look at it.
fdisk -l ./img
Disk ./img: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5659b81c
Device Boot Start End Sectors Size Id Type
./img1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFATI'll also put some actual filesystems and files on the three partitions.
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mkfs.vfat "$p"
mount "$p" mnt
echo "my part# is $p##*p"
>./mnt/"part$p##*p"
sync; umount mnt
done' "$PWD/img" 'losetup -D'Here are the byte offsets for where it all wound up...
grep -Ebao '(my[^0-9]*|PART)[123]' <./img
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2
917656608:PART3
917660672:my part# is 3
But did you notice that fdisk
was perfectly happy to report on the partitions' sizes before ever we formatted them with filesystems? This is because the partition table lies at the very head of the disk - it's only a layout and nothing more. None of the partitions need actually exist to be reported. They're only logically mapped out within the first 1M of ./img
. Watch:
Let's try getting only the first two partitions off of
./img
...<./img >./img2 dd count=1779583
1779583+0 records in
1779583+0 records out
911146496 bytes (911 MB) copied, 1.84985 s, 493 MB/sWe'll
grep
it again...grep -Ebao '(my[^0-9]*|PART)[123]' <./img2
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2And get an
fdisk
report...fdisk -l ./img2
Disk ./img2: 869 MiB, 911146496 bytes, 1779583 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcbcab4d8
Device Boot Start End Sectors Size Id Type
./img2p1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2p2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img2p3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFAT
Now that is curious. fdisk
still seems to believe there's a third partition extending as far out as 4G for a disk which it also seems to believe is only 869M in size!
Probably we should remove that third partition from the partition table.
printf %s\n d 3 w |
fdisk ./img2 >/dev/nullAnd now lets see if we can mount the partitions we copied and if our files remain in tact...
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mount "$p" mnt
grep . /dev/null ./mnt/*
umount mnt
done' "$PWD/img2" 'losetup -D'./mnt/part1:my part# is 1
./mnt/part2:my part# is 2
Apparently it's not impossible.
add a comment |
first of all, here's how:
First do almost as you did before, but no subtraction - and add one to the count.
dd count=132552704 </dev/sda >img
Next print the partition table at a
sed
process which can screen out the ones which you're removing.sed
will write ad
elete command to a secondfdisk
which has opened yourimg
file for every partition from sda4 and on.fdisk -l img | sed -e'/sda4 /,$id' -e'g;$aw' | fdisk img
There is no 3. You're done.
secondly, here's why:
A Partial Success...
I'm pretty sure your command almost worked, but I'm willing to bet that it worked better than you think.
I expect that when you say it copied all of sda you believe that because an
fdisk -l
of that image indicated all of the partitions were included within. Based on thedd
command in your question, though, provided/dev/sda
's sector size is the fairly standard 512 bytes (and therefore identical todd
's default blocksize) then you should have copied everything from byte 0 of/dev/sda
only through to all but the last 2k sectors of/dev/sda3
.
About Sectors...
You can see below where the
fdisk
output reports on Units. That is the size of each sector thatfdisk
reports on. A disk sector might be 4096-bytes - if it is a very recently manufactured disk and handles the Advanced Format sector-size - otherwise it is very rare to find a disk not partitioned on a standard logical 512-byte sector-size.This is how
fdisk
'sman
page puts it:
-u
,--units[=unit]
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
-u
option by a space, the correct form is for example-u=cylinders
.
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
There's more on this here.
And something about
dd
, too...dd
cannot silently lose data. In fact, if a short read occurs,dd
is specified to be very vocal about it:
A partial input block is one for which
read()
returned less than the input block size. A partial output block is one that was written with fewer bytes than specified by the output block size...
...when there is at least one truncated block, the number of truncated blocks shall be written to standard error...
"%u truncated %sn"
,<number of truncated blocks>
,"record[s]"
Block i/o...
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
lseek()
for files existing on block-devices - it's a very basic principle of blocked i/o.
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
To sum up...
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
/dev/sda
will contain its entire partition table, and as such you would have copied said partition table to your image, and so anfdisk -l
of your image would report for all partitions of/dev/sda
, whether or not the data for those partitions actually resides within that image-file. You can, instead, of course, justcat
the separate data partitions separately into separate image files if you like - but in that case you lose the partition table entirely. All you really have to do is delete the partitions which you did not copy, and make sure you copy all of those you do.
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
third, here's how I know:
This will create an 4G
./img
file full of NULs.</dev/zero >./img
dd ibs=8k obs=8kx1b count=1kx1b524288+0 records in
1024+0 records out
4294967296 bytes (4.3 GB) copied, 3.53287 s, 1.2 GB/sThis will partition
./img
to match your disk up to the first three partitions but on a 1/16th scale:(set "$((p=0))" 28266495 27
28268544 28473343 2\n7
28473344 132552703 3\n7
while [ "$#" -ge "$((p+=1))" ]
do printf "nnpn$pn%.0dn%dntn%bn"
"$(($1/16))" "$(($2/16))" "$3"
shift 3
done; echo w
)| fdisk ./img >/dev/nullAnd so now we can look at it.
fdisk -l ./img
Disk ./img: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5659b81c
Device Boot Start End Sectors Size Id Type
./img1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFATI'll also put some actual filesystems and files on the three partitions.
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mkfs.vfat "$p"
mount "$p" mnt
echo "my part# is $p##*p"
>./mnt/"part$p##*p"
sync; umount mnt
done' "$PWD/img" 'losetup -D'Here are the byte offsets for where it all wound up...
grep -Ebao '(my[^0-9]*|PART)[123]' <./img
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2
917656608:PART3
917660672:my part# is 3
But did you notice that fdisk
was perfectly happy to report on the partitions' sizes before ever we formatted them with filesystems? This is because the partition table lies at the very head of the disk - it's only a layout and nothing more. None of the partitions need actually exist to be reported. They're only logically mapped out within the first 1M of ./img
. Watch:
Let's try getting only the first two partitions off of
./img
...<./img >./img2 dd count=1779583
1779583+0 records in
1779583+0 records out
911146496 bytes (911 MB) copied, 1.84985 s, 493 MB/sWe'll
grep
it again...grep -Ebao '(my[^0-9]*|PART)[123]' <./img2
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2And get an
fdisk
report...fdisk -l ./img2
Disk ./img2: 869 MiB, 911146496 bytes, 1779583 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcbcab4d8
Device Boot Start End Sectors Size Id Type
./img2p1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2p2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img2p3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFAT
Now that is curious. fdisk
still seems to believe there's a third partition extending as far out as 4G for a disk which it also seems to believe is only 869M in size!
Probably we should remove that third partition from the partition table.
printf %s\n d 3 w |
fdisk ./img2 >/dev/nullAnd now lets see if we can mount the partitions we copied and if our files remain in tact...
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mount "$p" mnt
grep . /dev/null ./mnt/*
umount mnt
done' "$PWD/img2" 'losetup -D'./mnt/part1:my part# is 1
./mnt/part2:my part# is 2
Apparently it's not impossible.
add a comment |
first of all, here's how:
First do almost as you did before, but no subtraction - and add one to the count.
dd count=132552704 </dev/sda >img
Next print the partition table at a
sed
process which can screen out the ones which you're removing.sed
will write ad
elete command to a secondfdisk
which has opened yourimg
file for every partition from sda4 and on.fdisk -l img | sed -e'/sda4 /,$id' -e'g;$aw' | fdisk img
There is no 3. You're done.
secondly, here's why:
A Partial Success...
I'm pretty sure your command almost worked, but I'm willing to bet that it worked better than you think.
I expect that when you say it copied all of sda you believe that because an
fdisk -l
of that image indicated all of the partitions were included within. Based on thedd
command in your question, though, provided/dev/sda
's sector size is the fairly standard 512 bytes (and therefore identical todd
's default blocksize) then you should have copied everything from byte 0 of/dev/sda
only through to all but the last 2k sectors of/dev/sda3
.
About Sectors...
You can see below where the
fdisk
output reports on Units. That is the size of each sector thatfdisk
reports on. A disk sector might be 4096-bytes - if it is a very recently manufactured disk and handles the Advanced Format sector-size - otherwise it is very rare to find a disk not partitioned on a standard logical 512-byte sector-size.This is how
fdisk
'sman
page puts it:
-u
,--units[=unit]
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
-u
option by a space, the correct form is for example-u=cylinders
.
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
There's more on this here.
And something about
dd
, too...dd
cannot silently lose data. In fact, if a short read occurs,dd
is specified to be very vocal about it:
A partial input block is one for which
read()
returned less than the input block size. A partial output block is one that was written with fewer bytes than specified by the output block size...
...when there is at least one truncated block, the number of truncated blocks shall be written to standard error...
"%u truncated %sn"
,<number of truncated blocks>
,"record[s]"
Block i/o...
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
lseek()
for files existing on block-devices - it's a very basic principle of blocked i/o.
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
To sum up...
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
/dev/sda
will contain its entire partition table, and as such you would have copied said partition table to your image, and so anfdisk -l
of your image would report for all partitions of/dev/sda
, whether or not the data for those partitions actually resides within that image-file. You can, instead, of course, justcat
the separate data partitions separately into separate image files if you like - but in that case you lose the partition table entirely. All you really have to do is delete the partitions which you did not copy, and make sure you copy all of those you do.
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
third, here's how I know:
This will create an 4G
./img
file full of NULs.</dev/zero >./img
dd ibs=8k obs=8kx1b count=1kx1b524288+0 records in
1024+0 records out
4294967296 bytes (4.3 GB) copied, 3.53287 s, 1.2 GB/sThis will partition
./img
to match your disk up to the first three partitions but on a 1/16th scale:(set "$((p=0))" 28266495 27
28268544 28473343 2\n7
28473344 132552703 3\n7
while [ "$#" -ge "$((p+=1))" ]
do printf "nnpn$pn%.0dn%dntn%bn"
"$(($1/16))" "$(($2/16))" "$3"
shift 3
done; echo w
)| fdisk ./img >/dev/nullAnd so now we can look at it.
fdisk -l ./img
Disk ./img: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5659b81c
Device Boot Start End Sectors Size Id Type
./img1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFATI'll also put some actual filesystems and files on the three partitions.
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mkfs.vfat "$p"
mount "$p" mnt
echo "my part# is $p##*p"
>./mnt/"part$p##*p"
sync; umount mnt
done' "$PWD/img" 'losetup -D'Here are the byte offsets for where it all wound up...
grep -Ebao '(my[^0-9]*|PART)[123]' <./img
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2
917656608:PART3
917660672:my part# is 3
But did you notice that fdisk
was perfectly happy to report on the partitions' sizes before ever we formatted them with filesystems? This is because the partition table lies at the very head of the disk - it's only a layout and nothing more. None of the partitions need actually exist to be reported. They're only logically mapped out within the first 1M of ./img
. Watch:
Let's try getting only the first two partitions off of
./img
...<./img >./img2 dd count=1779583
1779583+0 records in
1779583+0 records out
911146496 bytes (911 MB) copied, 1.84985 s, 493 MB/sWe'll
grep
it again...grep -Ebao '(my[^0-9]*|PART)[123]' <./img2
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2And get an
fdisk
report...fdisk -l ./img2
Disk ./img2: 869 MiB, 911146496 bytes, 1779583 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcbcab4d8
Device Boot Start End Sectors Size Id Type
./img2p1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2p2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img2p3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFAT
Now that is curious. fdisk
still seems to believe there's a third partition extending as far out as 4G for a disk which it also seems to believe is only 869M in size!
Probably we should remove that third partition from the partition table.
printf %s\n d 3 w |
fdisk ./img2 >/dev/nullAnd now lets see if we can mount the partitions we copied and if our files remain in tact...
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mount "$p" mnt
grep . /dev/null ./mnt/*
umount mnt
done' "$PWD/img2" 'losetup -D'./mnt/part1:my part# is 1
./mnt/part2:my part# is 2
Apparently it's not impossible.
first of all, here's how:
First do almost as you did before, but no subtraction - and add one to the count.
dd count=132552704 </dev/sda >img
Next print the partition table at a
sed
process which can screen out the ones which you're removing.sed
will write ad
elete command to a secondfdisk
which has opened yourimg
file for every partition from sda4 and on.fdisk -l img | sed -e'/sda4 /,$id' -e'g;$aw' | fdisk img
There is no 3. You're done.
secondly, here's why:
A Partial Success...
I'm pretty sure your command almost worked, but I'm willing to bet that it worked better than you think.
I expect that when you say it copied all of sda you believe that because an
fdisk -l
of that image indicated all of the partitions were included within. Based on thedd
command in your question, though, provided/dev/sda
's sector size is the fairly standard 512 bytes (and therefore identical todd
's default blocksize) then you should have copied everything from byte 0 of/dev/sda
only through to all but the last 2k sectors of/dev/sda3
.
About Sectors...
You can see below where the
fdisk
output reports on Units. That is the size of each sector thatfdisk
reports on. A disk sector might be 4096-bytes - if it is a very recently manufactured disk and handles the Advanced Format sector-size - otherwise it is very rare to find a disk not partitioned on a standard logical 512-byte sector-size.This is how
fdisk
'sman
page puts it:
-u
,--units[=unit]
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
-u
option by a space, the correct form is for example-u=cylinders
.
- When listing partition tables, show sizes in sectors or in cylinders. The default is to show sizes in sectors. For backward compatibility, it is possible to use the option without the unit argument - then the default is used. Note that the optional unit argument cannot be separated from the
There's more on this here.
And something about
dd
, too...dd
cannot silently lose data. In fact, if a short read occurs,dd
is specified to be very vocal about it:
A partial input block is one for which
read()
returned less than the input block size. A partial output block is one that was written with fewer bytes than specified by the output block size...
...when there is at least one truncated block, the number of truncated blocks shall be written to standard error...
"%u truncated %sn"
,<number of truncated blocks>
,"record[s]"
Block i/o...
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
lseek()
for files existing on block-devices - it's a very basic principle of blocked i/o.
- But anyway, that actually can't happen with block-device i/o. It's what makes a block-device a block-device - there's an extra layer (sometimes several) of buffered protection for block-devices as opposed to character devices. It is this distinction which enables POSIX to guarantee
To sum up...
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
/dev/sda
will contain its entire partition table, and as such you would have copied said partition table to your image, and so anfdisk -l
of your image would report for all partitions of/dev/sda
, whether or not the data for those partitions actually resides within that image-file. You can, instead, of course, justcat
the separate data partitions separately into separate image files if you like - but in that case you lose the partition table entirely. All you really have to do is delete the partitions which you did not copy, and make sure you copy all of those you do.
- And so you have copied all of your device up to the point you specified, but the thing is, the first 2k sectors of
third, here's how I know:
This will create an 4G
./img
file full of NULs.</dev/zero >./img
dd ibs=8k obs=8kx1b count=1kx1b524288+0 records in
1024+0 records out
4294967296 bytes (4.3 GB) copied, 3.53287 s, 1.2 GB/sThis will partition
./img
to match your disk up to the first three partitions but on a 1/16th scale:(set "$((p=0))" 28266495 27
28268544 28473343 2\n7
28473344 132552703 3\n7
while [ "$#" -ge "$((p+=1))" ]
do printf "nnpn$pn%.0dn%dntn%bn"
"$(($1/16))" "$(($2/16))" "$3"
shift 3
done; echo w
)| fdisk ./img >/dev/nullAnd so now we can look at it.
fdisk -l ./img
Disk ./img: 4 GiB, 4294967296 bytes, 8388608 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5659b81c
Device Boot Start End Sectors Size Id Type
./img1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFATI'll also put some actual filesystems and files on the three partitions.
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mkfs.vfat "$p"
mount "$p" mnt
echo "my part# is $p##*p"
>./mnt/"part$p##*p"
sync; umount mnt
done' "$PWD/img" 'losetup -D'Here are the byte offsets for where it all wound up...
grep -Ebao '(my[^0-9]*|PART)[123]' <./img
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2
917656608:PART3
917660672:my part# is 3
But did you notice that fdisk
was perfectly happy to report on the partitions' sizes before ever we formatted them with filesystems? This is because the partition table lies at the very head of the disk - it's only a layout and nothing more. None of the partitions need actually exist to be reported. They're only logically mapped out within the first 1M of ./img
. Watch:
Let's try getting only the first two partitions off of
./img
...<./img >./img2 dd count=1779583
1779583+0 records in
1779583+0 records out
911146496 bytes (911 MB) copied, 1.84985 s, 493 MB/sWe'll
grep
it again...grep -Ebao '(my[^0-9]*|PART)[123]' <./img2
2826272:PART1
2830336:my part# is 1
904606240:PART2
904624640:my part# is 2And get an
fdisk
report...fdisk -l ./img2
Disk ./img2: 869 MiB, 911146496 bytes, 1779583 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xcbcab4d8
Device Boot Start End Sectors Size Id Type
./img2p1 2048 1766655 1764608 861.6M 27 Hidden NTFS WinRE
./img2p2 1766784 1779583 12800 6.3M 7 HPFS/NTFS/exFAT
./img2p3 1779584 8284543 6504960 3.1G 7 HPFS/NTFS/exFAT
Now that is curious. fdisk
still seems to believe there's a third partition extending as far out as 4G for a disk which it also seems to believe is only 869M in size!
Probably we should remove that third partition from the partition table.
printf %s\n d 3 w |
fdisk ./img2 >/dev/nullAnd now lets see if we can mount the partitions we copied and if our files remain in tact...
sudo sh -c ' trap "$1" 0
cd /tmp; mkdir -p mnt
for p in "$(losetup --show -Pf "$0")p"*
do mount "$p" mnt
grep . /dev/null ./mnt/*
umount mnt
done' "$PWD/img2" 'losetup -D'./mnt/part1:my part# is 1
./mnt/part2:my part# is 2
Apparently it's not impossible.
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Jul 12 '15 at 13:03
mikeservmikeserv
45.7k668159
45.7k668159
add a comment |
add a comment |
It isn't possible because dd is only direct 1 input to 1 output --the restoration would be damage because you merged 3 partitions in one and this isn't a backup and dd is only for identical copies.
Your answer would be possible:
dd if=/dev/sda1 of=~/hdadisk1.img;
dd if=/dev/sda2 of=~/hdadisk2.img
dd if=/dev/sda3 of=~/hdadisk3.img
(In a script if you want) and finally, you can to create an image with the hdadisk1,3,3.img although is a better practice you save these images in a partition for backups.
add a comment |
It isn't possible because dd is only direct 1 input to 1 output --the restoration would be damage because you merged 3 partitions in one and this isn't a backup and dd is only for identical copies.
Your answer would be possible:
dd if=/dev/sda1 of=~/hdadisk1.img;
dd if=/dev/sda2 of=~/hdadisk2.img
dd if=/dev/sda3 of=~/hdadisk3.img
(In a script if you want) and finally, you can to create an image with the hdadisk1,3,3.img although is a better practice you save these images in a partition for backups.
add a comment |
It isn't possible because dd is only direct 1 input to 1 output --the restoration would be damage because you merged 3 partitions in one and this isn't a backup and dd is only for identical copies.
Your answer would be possible:
dd if=/dev/sda1 of=~/hdadisk1.img;
dd if=/dev/sda2 of=~/hdadisk2.img
dd if=/dev/sda3 of=~/hdadisk3.img
(In a script if you want) and finally, you can to create an image with the hdadisk1,3,3.img although is a better practice you save these images in a partition for backups.
It isn't possible because dd is only direct 1 input to 1 output --the restoration would be damage because you merged 3 partitions in one and this isn't a backup and dd is only for identical copies.
Your answer would be possible:
dd if=/dev/sda1 of=~/hdadisk1.img;
dd if=/dev/sda2 of=~/hdadisk2.img
dd if=/dev/sda3 of=~/hdadisk3.img
(In a script if you want) and finally, you can to create an image with the hdadisk1,3,3.img although is a better practice you save these images in a partition for backups.
edited Jul 12 '15 at 5:20
Archemar
20.1k93772
20.1k93772
answered Jul 12 '15 at 4:01
Joe MantilJoe Mantil
786
786
add a comment |
add a comment |
dd count=$((132552703-2048))
copies 132552703-2048 blocks of 512 bytes from the beginning of the input. The block size in fdisk
is 1 kB = 1024 bytes. So you have three problems:
- You specified a size that's half what you wanted.
- You didn't indicate that you wanted to start the copy at an offset.
- Your subtraction has a fencepost error: it misses the last block — the number of blocks is (end block offset) - (start block offset) + 1.
So you can do that copy with
dd bs=1k skip=2048 count=$((132552703-2048+1)) if=/dev/sda of=./newImage.image
I think this will work — dd
can silently lose data, but I think that 1kB blocks on a block device or regular file on Linux is fine. But it's slow.
The most straightforward way to copy a single partition would be to just copy it.
cat /dev/sda1 >sda1.image
cat /dev/sda2 >sda2.image
cat /dev/sda3 >sda3.image
It would be better to copy the partitions to separate files, because otherwise the partitions that aren't at the beginning of the file will be hard to use. If you really want the three partitions in the same file, you can concatenate them:
cat /dev/sda1 /dev/sda2 /dev/sda3 >newImage.image
add a comment |
dd count=$((132552703-2048))
copies 132552703-2048 blocks of 512 bytes from the beginning of the input. The block size in fdisk
is 1 kB = 1024 bytes. So you have three problems:
- You specified a size that's half what you wanted.
- You didn't indicate that you wanted to start the copy at an offset.
- Your subtraction has a fencepost error: it misses the last block — the number of blocks is (end block offset) - (start block offset) + 1.
So you can do that copy with
dd bs=1k skip=2048 count=$((132552703-2048+1)) if=/dev/sda of=./newImage.image
I think this will work — dd
can silently lose data, but I think that 1kB blocks on a block device or regular file on Linux is fine. But it's slow.
The most straightforward way to copy a single partition would be to just copy it.
cat /dev/sda1 >sda1.image
cat /dev/sda2 >sda2.image
cat /dev/sda3 >sda3.image
It would be better to copy the partitions to separate files, because otherwise the partitions that aren't at the beginning of the file will be hard to use. If you really want the three partitions in the same file, you can concatenate them:
cat /dev/sda1 /dev/sda2 /dev/sda3 >newImage.image
add a comment |
dd count=$((132552703-2048))
copies 132552703-2048 blocks of 512 bytes from the beginning of the input. The block size in fdisk
is 1 kB = 1024 bytes. So you have three problems:
- You specified a size that's half what you wanted.
- You didn't indicate that you wanted to start the copy at an offset.
- Your subtraction has a fencepost error: it misses the last block — the number of blocks is (end block offset) - (start block offset) + 1.
So you can do that copy with
dd bs=1k skip=2048 count=$((132552703-2048+1)) if=/dev/sda of=./newImage.image
I think this will work — dd
can silently lose data, but I think that 1kB blocks on a block device or regular file on Linux is fine. But it's slow.
The most straightforward way to copy a single partition would be to just copy it.
cat /dev/sda1 >sda1.image
cat /dev/sda2 >sda2.image
cat /dev/sda3 >sda3.image
It would be better to copy the partitions to separate files, because otherwise the partitions that aren't at the beginning of the file will be hard to use. If you really want the three partitions in the same file, you can concatenate them:
cat /dev/sda1 /dev/sda2 /dev/sda3 >newImage.image
dd count=$((132552703-2048))
copies 132552703-2048 blocks of 512 bytes from the beginning of the input. The block size in fdisk
is 1 kB = 1024 bytes. So you have three problems:
- You specified a size that's half what you wanted.
- You didn't indicate that you wanted to start the copy at an offset.
- Your subtraction has a fencepost error: it misses the last block — the number of blocks is (end block offset) - (start block offset) + 1.
So you can do that copy with
dd bs=1k skip=2048 count=$((132552703-2048+1)) if=/dev/sda of=./newImage.image
I think this will work — dd
can silently lose data, but I think that 1kB blocks on a block device or regular file on Linux is fine. But it's slow.
The most straightforward way to copy a single partition would be to just copy it.
cat /dev/sda1 >sda1.image
cat /dev/sda2 >sda2.image
cat /dev/sda3 >sda3.image
It would be better to copy the partitions to separate files, because otherwise the partitions that aren't at the beginning of the file will be hard to use. If you really want the three partitions in the same file, you can concatenate them:
cat /dev/sda1 /dev/sda2 /dev/sda3 >newImage.image
edited Apr 13 '17 at 12:36
Community♦
1
1
answered Jul 12 '15 at 20:22
GillesGilles
537k12810871604
537k12810871604
add a comment |
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%2f215359%2fhow-can-i-copy-three-partitions-of-my-disk-with-a-specific-beginning-and-ending%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
try with dd bs=2048 count=$(( (132552703-2048)/204)) your other arg
– Archemar
Jul 12 '15 at 5:31