Tag Info

New answers tagged

2

Just do: cp /dev/block_device imgfile If imgfile will be located on a file-system which understands such things, a GNU cp should default to writing the image sparsely. You can specify your preference, though, like... cp --sparse=always /dev/sda imgfile dd's primary usefulness is in its ability to reliably take only a specified portion of a stream, or ...


0

dd doesn't care what the data it copies means. Partition tables, partition contents, file fragments, empty filesystem space, it's all bytes. dd if=/dev/sda of=/dev/sdb makes /dev/sdb an exact copy of /dev/sda, provided that sdb is at least as large as sda (plus some trailing junk that won't be directly accessible if sdb is larger). All the magic is in the ...


6

Yes it does, even the blocks that would not (officially) contain data and also all information regarding partitions, UUIDs, etc.. E.g. recovery of data (i.e. after deleting files) from the dd-copied drive would be possible. You may want to read this regarding the noerror and sync options. Block size (bs=) doesn't affect the result unless there are read ...


0

For future reference: To suppress dd output completely redirect stderr to /dev/null like so: dd if=/dev/urandom of=sample.txt bs=5MB count=1 2> /dev/null This works nicely if you want to, for example, time the process using the time command in bash and assign the result to a variable, without getting any of the output that dd produces. reference: ...


1

Normally, Linux mdadm RAID devices are always a little smaller than the size of the component devices (or their sum in the case of RAID 0), because MD devices store metadata. In this case you have used --build, which invokes a manual assembly mode that does not use metadata. Nevertheless, a linear array might be smaller than the sum of the sizes of the ...


0

Consider running fsck on the backup. You may need to play some tricks with losetup to get loopback devices set on partitions embedded in the backup, but if the file check says the file structure is consistent the data itself is likely good. If you want a full checksum, you can use loopback devices with offsets to look at the internal 'partitions' of the ...


0

Post output of sw_vers + the exact commands you use for your dd. Also the output of - file aramok - which will fail if aramok is a file or directory (see below). Posting an image is difficult to read. Actual commands are better. It appears you're attempting to somehow write (dd) to a floppy with no formatting. Meaning your trying to dd either a file or a ...


0

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 ...


0

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 a delete command to a second fdisk which has opened your img file for every partition ...


0

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 ...


1

What we did was to md5um the actual partition. It doesn't exactly allow you to checksum the image with the disk, but if you have a few disks (like we do), you are able to establish the 'proper' checksum. For instance, in our case the partitions look like this: $ sudo fdisk -l /dev/sdc Disk /dev/sdc: 7948 MB, 7948206080 bytes 245 heads, 62 sectors/track, ...


6

It depends on what you mean by "patch the binary". I change binaries using dd sometimes. Of course there is no such feature in dd, but it can open files, and read and write things at specific offsets, so if you know what to write where, voila there is your patch. For example I had this binary that contained some PNG data. Use binwalk to find the offset, dd ...


58

Let's try it. Here's a trivial C program: #include <stdio.h> int main(int argc, char **argv) { puts("/usr/tmp"); } We'll build that into test: $ cc -o test test.c If we run it, it prints "/usr/tmp". Let's find out where "/usr/tmp" is in the binary: $ strings -t d test | grep /usr/tmp 1460 /usr/tmp -t d prints the offset in decimal into ...


2

Determine the size of the image, for example with \ls -l my.img (not ls -lh, that would give you an approximate size; \ls protects against an alias like ls='ls -h') or with stat -c %s my.img. If you want to check the copy against the original just this once, then just compare the files. Using hashes is useless for a one-time comparison, it would only make ...


0

sudo sh -c ' dd bs=64k if="$1" of="$2" ! cmp -- "$1" "$2" 2>&1 | grep -qvF "EOF on $1" ' -- my.img /dev/sdc cmp will compare two files byte for byte and return based on whether or not they are identical. If one is shorter than the other, but both files were identical for the entire length of the shorter file, then cmp will return 1 ...


0

Are you writing it to a filesystem on the SD card ? Or directly ? You need count if you want to limit the run length of the compared data ? dd should tell you how many bytes were copied. This needs to be captured and used with appropriate bs=x and count=y. This is to avoid hashing garbage in a cluster tip. EDIT capture the output, this is the line you ...


0

md5sum would be a good solution here, to compare the value of the image file with that of the SD card.


0

This is a very fast and efficient way of writing 64 kB strings of 0xFF over and over, using awk, consuming < 8% of CPU and limited only by the speed of the drive you are writing to. I have tried using tr as was suggested here and found it was painfully slow and consumed a lot of CPU translating each and every Byte. My method works in 64 kB blocks and is ...



Top 50 recent answers are included