New answers tagged

6

Bear in mind that dd is a raw interface to the read(), write() and lseek() system call. You can only use it reliably to extract chunks of data off regular files, block devices and some character devices (like /dev/urandom), that is files for which read(buf, size) is guaranteed to return size as long as the end of the file is not reached. For pipes, sockets ...


2

With a bashism, and a functionally "useless use of cat", but closest to the syntax the OP uses: cat <(dd if=file1 bs=1M count=99 skip=1) \ <(dd if=file2 bs=1M count=10) \ > final_output (That being said, Stephen Kitt's answer seems to be the most efficient possible method.)


12

dd can write to stdout too. ( dd if=file1 bs=1M count=99 skip=1 dd if=file2 bs=1M count=10 ) > final_output


8

I don't think you can easily read multiple files in a single dd invocation, but you can append to build the output file in several steps: dd if=file1 bs=1M count=99 skip=1 of=final_output dd if=file2 bs=1M count=10 of=final_output oflag=append conv=notrunc You need to specify both conv=notrunc and oflag=append. The first avoids truncating the output, the ...


2

Unfortunately, to manipulate the content of a binary file, dd is pretty much the only tool in POSIX. Although most modern implementations of text processing tools (cat, sed, awk, …) can manipulate binary files, this is not required by POSIX: some older implementations do choke on null bytes, input not terminated by a newline, or invalid byte sequences in the ...


0

Part of the point of using dd at all is that the user gets to pick the block size it uses. If dd fails for too large block sizes, IMO it's the user's responsibility to try smaller block sizes. I could ask for a TB from dd in one block, but that doesn't mean I'll get it. If you want an exact number of bytes, this will be horrendously slow, but should work: ...


1

If it is a archlinux bootable iso, you don't have to do anything special. Just dd if=somefile.iso of=/dev/sdx where sdx is the block device like /dev/sda and not a partition like /dev/sda1. This is possible as the iso already contains all that is needed. If you set some partition table, it will simply has no effect, as it will be overriden by dd, as ...


2

Using gparted remove the existing partitions from your usb , and fix the msdos partition table ( by going to the device menu then select create partition Table) . Then create a new partition fat32 by right click on the unallocated space and select new, make it as a primary FAT32 partition . Next step create your bootable usb: dd ...


0

I could update Dell Latitude BIOS with dd command by following these two links: https://wiki.ubuntu.com/DellBIOS Under section: Upgrading with a FreeDOS USB drive http://www.chtaube.eu/computers/freedos/bootable-usb/ Steps I did are straight forward. First download and unzip: bunzip2 FreeDOS-1.1-memstick-3-30M.img.bz2 Then run dd: sudo dd ...


1

Two problems: 1) dd if="$file" of="$out" seems to overwrite $out at some point. 2) Even allowing for that, the count=, skip=, & seek= logic loses a byte somewhere in there. Instead try something like this: file=/etc/passwd out=passwd.mod offset=0x5 dd if="$file" of="$out" conv=notrunc bs=1 count=$offset printf '\x41' >> $out dd if="$file" ...


1

If I understood you correctly, I believe that this will work for you: #!/bin/bash file=passwd.orig out=passwd.mod offset=0x5 dd if="$file" of="$out" conv=notrunc bs=1 count=$(($offset)) printf '\x41' | dd of="$out" conv=notrunc bs=1 seek=$(($offset)) dd if="$file" of="$out" conv=notrunc bs=1 seek=$((offset+1)) skip=$(($offset + 1)) You do need both seek ...


1

You missed the seek in the last command: dd if="$file" of="$out" \ conv=notrunc \ bs=1 \ skip="$((offset + 1))" \ seek="$((offset + 1))" skip=n skips n input block from input file before copying, seek=n skips n input block of output file before copying. You need both of them to correctly the writing offset.


2

You can use the split command to run a "filter" upon successive chunks of a file, and write a filter using cmp, echo, and true to gain a newline for every successful match, then use wc for counting these. For example, if $F is the file, $TB the template block file, and $SZ the size of the template block, then it could look like the following command line: $ ...


2

In a shell script, it might be better to use cmp from GNU diffutils. It compares data for you and can even skip offsets --ignore-initial=SKIP1:SKIP2 so you can run cmp for each sector offset, and it will exit on the first difference it finds... which is semi-efficient but still, that's a LOT of cmp calls if you want to run it for each sector... You could ...


1

Others have explained what they do, so I'll skip that. The point in dd having seperate bs and count argument is that bs controls how much is written at a time. Specifying really large values for bs will require a really large buffer in the program, and specifying values less than the block size of the device will be slow because the kernel has to build an ...


19

dd if=/dev/zero of=/dev/sda bs=4096 count=4096 Q: why 4096 is particularly used for counter? This will zero out the first 16 MiB of the drive. 16 MiB is probably more than enough to nuke any "start of disk" structures while being small enough that it won't take very long. dd if=/dev/zero of=/dev/sda bs=512 count=4096 seek=$(expr blockdev --getsz ...


4

Those commands will overwrite your sda device with zeroes -- the first one will do the first 16MB (block size of 4096 and count of 4096 blocks) and the 2nd one will overwrite the last 2MB (512 block size with 4096 blocks) with zeroes. (it's not technically erasing, and that relates to my first point below.) (that was the part already mentioned in other ...


12

This will erase the first 4096*4096=16MB and last 512*4096=2MB of your hard drive, which contain important structures useful for recovery. I assume this code was posted maliciously. I've never encounter a situation where explicitly specifying a count other than 1 was useful. I have erased the first block if I wanted to ensure I wasn't leaving any traces of ...


3

It looks like you know what you're doing! If sdb worked before (on Linux), then it should definitely work again after a restore like you describe. If it happened to me I would be suspecting some kind of user error. But either way, I just can't see what could have gone wrong. E.g. if gunzip was fed the files in the wrong order, it would generate scary ...



Top 50 recent answers are included