I have an ISO file, which I burned to a CD. Now how can I check if the CD is correctly created? I would like a command that calculate the hash sum that I can use to check with the hash sum I calculate on the ISO file. Ideally the command should:

  • Work regardless of the ISO file: that is, I don't want to keep a list of hash sum for each file in the disc, or remember the number of blocks whatever
  • Be relatively short: a one-line command is great, a chain of commands which is two line long is OK, a script that span one page is not
  • Be fairly efficient: for example, dd the disc back to a file then run md5sum on the file is unacceptable

If there is no answer that cannot satisfy all I will appreciate the nearest match too. Even better if you can tell me why it is not so straight-forward.

3 Answers 3


The basic problem is that we want to take the md5sum of the exact same information that was on the ISO originally. When you write the ISO to a CD, there is likely blank space on the end of the disk, which inevitably changes the md5sum. Thus, the the very shortest way:

md5sum /dev/cdrom

doesn't work. What does work (and is common in online documentation) is only reading the exact number of bytes from the device and then doing the md5sum. If you know the number of bytes you can do something like:

dd if=/dev/cdrom bs=1 count=xxxxxxxx | md5sum

where 'xxxxx' is the size of the iso in bytes.

If you don't know the number of bytes off hand, but have the iso on your disk still, you can get them using ls by doing the something like the following (taken from here):

dd if=/dev/cdrom | head -c `stat --format=%s file.iso` | md5sum

There are many other one-line constructions that should work. Notice that in each case we are using dd to read the bytes from the disk, but we aren't piping these to a file, rather, we are handing them to md5sum straight away.

Possible speed improvements can be made by doing some calculations to use a bigger block size (the bs= in the dd command).

  • You can simplify dd if=/dev/cdrom | to </dev/cdrom. There's nothing magical about dd and block devices, it's just a stream manipulation command with a funny syntax. Commented Nov 5, 2010 at 18:26
  • By the way, you (phunehehe) should have the iso size together with the MD5 checksum. This is particularly important for MD5 which is partially broken, but it's a good idea for both security and usability no matter what checksum you use. Commented Nov 5, 2010 at 18:34
  • @Gilles: actually, using dd with bs of the device cache size can speedup data transfer as opposed to plain input redirection.
    – alex
    Commented Nov 6, 2010 at 4:51
  • @Gilles: what do you mean by "MD5 which is partially broken"? And why should I keep the file size, when if something is wrong the checksum should tell me right away?
    – phunehehe
    Commented Nov 6, 2010 at 10:15
  • @phunehehe: There are known cryptographic weaknesses with MD5 (it is not (publicly) known how to generate a collision for a given file, but it could come). Knowing the file size gives you a little more confidence (though not much more). It also gives you immediate feedback for common accidental errors such as truncated downloads. Commented Nov 6, 2010 at 11:56

There is program for this task. It's called - checkisomd5. In Ubuntu it can be installed by command:

sudo apt-get install isomd5sum
  • How do you use it? checkisomd5 /dev/sr0 gives me: The media check is complete, the result is: NA. No checksum information available, unable to verify media.
    – Torsten
    Commented Dec 7, 2019 at 14:25
  • Checksum should be embeds in iso image with tool "implantisomd5". It's have to done before iso will be write on disk. Utility included in "checkisomd5". Commented Dec 11, 2019 at 0:32

If the size of the image on the disc is divisible by 2048, whole number, which seems to be very common, then you can get an accurate MD5sum as follows where sr0 is the name of the optical -which can be found using, lshw -C disk- and where 'count' is the dividend of the image size divided by 2048.

dd if=/dev/sr0 bs=2048 count=356352 |md5sum
  • Many CDs likely use "Mode 1" tracks, which has 2,048 bytes of user data per sector. ("Mode 2" stores 2,336 bytes of user data per sector, but lacks the more advanced error detection and correction capabilities offered by Mode 1, causing Mode 2 to be less useful for data where errors cannot be tolerated.)
    – user
    Commented Oct 7, 2015 at 9:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .