I downloaded the ISO from https://www.ubuntu.com/download, selecting the default "Ubuntu Desktop" option.

The website links the page https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu which gives instructions how to verify ubuntu.

This seems pretty tedious, and I am wondering how realistic it is that there is a problem with ISO downloaded from the official website. I note that the process of verification itself requires me to download software that is new to me, thus introducing another attack vector on me even as I am closing another one.

For what it's worth, I am planning to use Live USB only and not to fully install Ubuntu. Does that make a difference?

  • 9
    My political answer is "YES DO IT". I've never done it except maybe once on the first download many moons ago. I'm always downloading and evaluating software or patches/bug fixes and just can't be bothered with the extra steps. Plus my systems are all non-production and if they go "poof" tomorrow I would just shrug and move on. Jan 8, 2018 at 5:07
  • 14
    Torrent is an alternative, if you don't want to check the md5sum. When you get a file via torrent, it will be checked automatically :-) It is often faster to use the torrent method (compared to ordinary downloads), but some internet service providers block it because they think that it is only used for illegal purposes.
    – sudodus
    Jan 8, 2018 at 6:09
  • 2
    The primary use of MD5 checksums over large files is to ensure the integrity of the downloaded file (e.g. to detect if transfer cancelled prematurely), not to mitigate the chance of MITM attacks. Jan 8, 2018 at 12:31
  • 1
    @rackandboneman No, that's not the underlying question at all. Jan 8, 2018 at 12:31
  • 16
    Fun fact: you'll probably spend more time asking this question than computing checksums in your whole life. Jan 8, 2018 at 12:58

8 Answers 8


Yes it's worthwhile.

It takes only seconds to sha256sum/etc a downloaded ISO, and it provides reassurance you weren't attacked by MITM etc. Beyond that, those seconds are insurance for the [hours of] time wasted if you had a few bit errors and debugging necessary chasing errors no-one else gets because of your download (eg. you have network issues & so try to debug; but networking is stuffed because that's what the few bits wrong were...) Think of checksum-checks as very cheap insurance.

The software needed to sha256sum something will be from another source usually (an older version, even different os/distro on occasion), is very small and is already present for many/most of us.

Further it allows me to download from a local mirror, but because I grab the sha256sum from the Canonical source; I've insurance that the mirror didn't play with it. Again very cheap insurance that costs me ~3secs of time.

  • 12
    However, if the download used the HTTPS transfer method, then all the integrity checks have took place already.
    – Nayuki
    Jan 8, 2018 at 5:07
  • 17
    @Nayuki these integrity checks would be worthless if the file is somehow damaged on the server (disk/FS-driver failure, bad mirroring etc.).
    – Ruslan
    Jan 8, 2018 at 9:14
  • 7
    @Nayuki Just because you are accessing a web site over HTTPS doesn't mean the entire link from your PC to the storage holding the file you're downloading is end to end encrypted. See the Google data center interlinks debacle some years ago.
    – user
    Jan 8, 2018 at 14:07
  • 33
    If someone has MITM'd the ISO, whose to say they didn't MITM the checksum when you viewed it on the website? (If you're using a mirror, it's useful.) It's not too rare to see the checksum and download served from the same entity.
    – Lan
    Jan 8, 2018 at 15:18
  • 16
    NEVER make the assumption that a checksum will detect MitM. The given checksums could be fake too. The proper way is to verify the signature, but that requires GPG (I've only done this once and it's a pain to do). Jan 9, 2018 at 14:27

Yes, it is VERY RECOMMENDED that you verify the image you downloaded, here are some reasons:

  • Just takes a few seconds and can tell you if the integrity of the file is correct, I mean, the file is not corrupted. (A common cause of corruption is a transfer error because of technical reasons such as a flaky internet connection from @sudodus comment.)
  • If the file is corrupted and you burn this ISO image into a CD/USB drive, and it won't work, or during an installation could fail, this results in a waste of time and CDs.
  • You are sure that you're using the official CLEAN version of any kind of ISO image or software and not a modified version (maybe by attackers), see this report: Watch Dogs pirates hit by scurvy Bitcoin-mining malware

If you already have a GNU Linux distro, you can use md5sum, if you're in Windows you can use: WinMD5Free.

Hope it helps.

  • 3
    For windows you can use the built-in certutil: superuser.com/a/898377/521689
    – Kanchu
    Jan 8, 2018 at 8:56
  • 1
    I also answered, but I'm upvoting your answer because I feel it answers the question well too and it is useful to more readers since it does not go into too technical details like the other answers.
    – bitoolean
    Jan 8, 2018 at 15:49
  • @sudodus Networks have their own integrity checks. While it's not impossible for errors to get past them (TCP just uses a simple checksum, which won't detect word swaps, but most links use CRC), it's not something one generally worries about.
    – Barmar
    Jan 8, 2018 at 18:40
  • If an attacker is able to corrupt a file, changing the value in an MD5 box should be within reach too, though. Jan 8, 2018 at 23:28

Yes it is, but Ubuntu seems to make it harder than it should be.

In the best case you would just download foo.iso and foo.iso.sig and click the .sig file (or use gpg on the shell on the .sig file) after you imported the key one time. This costs a few seconds.

Ubuntu seems to make it more complicated by forcing you to check the sha256 sums from a file while only the file itself is signed. That's convenient for them, but more work for their users.

On the other hand, when the file was generated just by sha256sum * >SHA256SUMS, you can check it using sha256 -c and get OK/Bad/Not-Found as output.


Check your /proc/net/dev and see how many bad TCP frames you have received so far. If you see a single-digit value (hopefully a zero), read on. If you have lots or network errors, then by all means use MD5 to verify your downloads (though I would rather investigate the root cause, since unreliable network means you can't trust anything you receive via HTTP).

When you're downloading over TCP which checksums all transmitted data, there's very little chance of having a corrupt download with exactly the same size. If you're confident you're downloading from the official site (you normally are if you're using HTTPS and the certificate check passes), verifying that your download is complete is normally enough. Decent web browsers usually do the check for you anyway, saying something along the lines of "download failed" if they don't get the amount of data they expect, though I have seen browsers which just decide to keep the incomplete file without saying anything to the user, in which case you could check the file size manually.

Of course, verifying a checksum still has its value, covering you in cases where the file you're downloading is corrupt on the server, but that doesn't happen too often. Still, if you're going to use your download for something important, that's a step worth taking.

As @sudodus said in the comments, using Bittorrent instead of HTTPS is another option, since torrent clients do a much better job when dealing with incomplete/corrupt data as web browsers do.

Note that checksums don't really prevent you from being attacked, that's what HTTPS is for.

  • 5
    The TCP checksum isn't big enough for something as large as an ISO file. It's only 16 bits; on a noisy link, there's a good chance that some corruption got through.
    – Mark
    Jan 8, 2018 at 23:46
  • 1
    @Mark for a large ISO, there will be many TCP checksums: one for each individual TCP segment required to transmit the data. Jan 9, 2018 at 22:39
  • 3
    @AnthonyGeoghegan, exactly. Each segment has an independent chance to be corrupted, and given how many segments are involved in an ISO file, there's a pretty good chance that one of them will be corrupted in a way that still matches that segment's checksum.
    – Mark
    Jan 9, 2018 at 22:43
  • 1
    @Mark can you check your /proc/net/dev and tell how many bad TCP frames you have received? My computer got 0, with an uptime of 140 days. If I'm not mistaken, certified Gigabit Ethernet equipment provides bit error rate of 10^-10 or better. Of course, it all depends on what you call a "good chance"... Jan 10, 2018 at 9:59
  • 2
    @Voo Ethernet CRC is useless because it's recalculated even when it shouldn't change: evanjones.ca/tcp-and-ethernet-checksums-fail.html
    – Navin
    Jan 10, 2018 at 15:51

I found out the hard way about not check summing. I would burn a CD with an ISO that got corrupted during a download, and could not get it to boot or it had errors when running.

Like the others said, it takes little time.

  • The worst thing about that experience is if you burn the ISO again, you get the same error on the CD Jan 8, 2018 at 3:47
  • 1
    That why I use RW CDs and DVDs. :-)
    – fixit7
    Jan 8, 2018 at 5:01
  • 7
    I've never written any CD/DVD for more than a decade. Not worth the time to write and cost to buy when there are tons of cheap pendrives
    – phuclv
    Jan 8, 2018 at 5:43

You are seeing it with only one use case, in a set up with mass automation it helps to have it verified; scripts that run the check , before proceeding with what ever we need to do with the image


The others have given answers with technical details that I forgot although I'm a programmer (my work doesn't involve communication over networks), so I'm just going to let you know a personal experience.

A long time ago, when I used to burn CDs frequently, it once happened to me to have downloaded this linux distribution ISO which appeared to have downloaded correctly. The CD failed me, so I checked the downloaded file and it did not match. So, I downloaded again and it worked. So, this only happened once in 15 years since I've been an advanced computer user and programming (have been using computers since the age of 11, 19 years ago, and I've burnt more than a thousand discs). But it is proof that it can happen.

It also happened to me through BitTorrent once or twice, so that is not fail-safe either. When forcing recheck of the downloaded file, it identified the corrupt piece.

My conclusion is HTTP (relying on TCP) may be as safe as it gets, but the Internet means there are intermediary nodes between your device and the server, and there is no telling what can happen on the way (packets are even lost all the time), and sometimes computers can't tell that the data is wrong I guess.

No one can answer whether it would be worth the trouble for you - it depends on context and I'm sure you can judge that for yourself. For me, it's not worth it most of the time. If I was going to install an OS though, I would check the downloaded image before.

Note: the fact that I only once or twice noticed a corrupt download doesn't mean that it only happened then. Maybe other times it doesn't get in the way so you don't notice.

EDIT: I even had other more experienced programmers at work argue (with quite some indignation even) that these data integrity verification hashes make it possible to know whether a file is bit-identical to the original, but I know (I have read) that the fact that two files result in the same hash does not mean that they are identical - it just means it is extremely unlikely they are different. The way they are useful is that when files are not identical, and especially when they are very different, their resulting hash codes will practically never be the same (it is even less likely this test would fail). In less words - if hash codes are different, you know the files are different.


Media Checks

Modern releases (20.04 and later) automatically scan. I for sure let that scan occur (on the first boot of the day; I tend to skip it if rebooted in the same box on the same day).

If you don't want to check beforehand, you can switch to a terminal (post-install) and always do a

dmesg |grep squashfs

and look for errors. A standard install should find only the copyright messages when dmesg is scanned; if any other lines appear with squashfs I'd read them as the install is likely not trustworthy.

If using an older release (pre-20.04), I'll always also do a manual CD integrity check, primarily as the write to USB-media I've found the most troublesome (I have 10+ failures per year, even if that's a smallish percentage of writes; it's still significant).

Ubuntu 23.04 Desktop

The way you verify actually varies on release, with a Ubuntu 23.04 Desktop system I'll use the following

sudo journalctl |grep casper-md5check

And what I look for is

May 11 08:37:42 ubuntu casper-md5check[3924]: Checking ./casper/install-sources.yaml..../casper/install-sources.yaml: OK
May 11 08:37:42 ubuntu casper-md5check[3924]: Checking ./casper/vmlinuz..../casper/vmlinuz: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Checking ./casper/initrd......./casper/initrd: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Checking ./boot/memtest86+x64.bin..../boot/memtest86+x64.bin: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Checking ./boot/grub/grub.cfg..../boot/grub/grub.cfg: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Checking ./boot/grub/loopback.cfg...../boot/grub/loopback.cfg: OK
May 11 08:37:47 ubuntu casper-md5check[3924]: Check finished: no errors found.
May 11 08:37:47 ubuntu systemd[1]: Finished casper-md5check.service - casper-md5check Verify Live ISO checksums.

Where the key message I look (& wait for; ie. I may need to run this command a few times as the process will continue to run as a background task) is

Check finished: no errors found.

ISO image Validation

As for ISO image validation pre-write, or How to verify your Ubuntu download, I download using zsync and it checks the integrity of the ISO image at the conclusion of download; I tend to trust that, and just do the self-scan on boot.

If I download via a torrent, I tend to do a quick sha256sum check against the checksum file I downloaded using wget on a different device. I tend to perform this check on ISO image files downloaded previously anyway.

Why do it?

The checks take seconds to maybe a minute. If you have a single bit wrong, the debugging the installation or corrupted data could take hours if you're lucky, but more likely days-weeks-months.

There are generally at least one bug report filed per day (on launchpad; I monitor via #ubuntu-bugs-announce), reported by users who've been having problems with they consider a bug that would have been prevented by these checks. The bug reports are just marked INVALID and given a quick paste with a couple of lines from their dmesg output). So I see on a very regular basis users wasting hours trying to repeat processes that will never work (often over days), because they skipped these checks and thus are starting with corrupted media where problems should be expected.

I see it as a very cheap insurance.

  • This is somewhat duplicate; from another question that was marked duplicate of this, thus will get deleted. I felt it had extra detail that was worth keeping.. askubuntu.com/questions/1311183/… It's more up-to-date and provides example (#ubuntu-bugs-announce)
    – guiverc
    Jan 31, 2021 at 5:20
  • For a different explanation, you can also read bugs.launchpad.net/ubuntu/+bug/1874662 too, which the rare bug gets marked duplicate of (It's faster to just paste the invalid/squashfs issue so that's more common)
    – guiverc
    Jan 31, 2021 at 5:22

You must log in to answer this question.

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