You download the Proxmox VE ISO, burn it to a USB stick, boot the server, and the installer hangs at 40% or throws a cryptic squashfs error partway through. You retry twice, reformat the USB, try a different port — still nothing. Nine times out of ten, this traces back to one thing nobody checked: the ISO file itself got corrupted somewhere between Proxmox's server and your USB stick, and it never actually finished downloading in one piece.
A single flipped bit is enough to break a bootable image. Your browser will happily report "Download complete" on a file that's missing the last 4 KB, and the file size might even look about right. The only way to know for sure is to check the file's fingerprint against the one Proxmox publishes. That takes about five minutes, and it saves you from troubleshooting a "broken installer" that was never actually a Proxmox problem in the first place.
What You Will Learn
- What a SHA256 checksum actually is, and why it catches corruption that a file size check won't
- How to compute and compare the checksum on Linux, macOS, and Windows
- How to go a step further and verify the GPG signature, which confirms the file really came from Proxmox and wasn't swapped out somewhere along the way
- What to do when the hashes don't match
- The mistakes that make people think verification "doesn't work" when it's actually working correctly
What Is This Feature?
A SHA256 checksum is a 64-character string of letters and numbers generated by running a file through a hashing algorithm. Feed it the exact same file twice, and you get the exact same string every time. Change even one byte — a single pixel in a corrupted download, one dropped packet — and the entire string comes out different. It's not a partial match or a percentage; it's either identical or it isn't. That makes it a reliable way to confirm a file arrived on your machine exactly as it left Proxmox's server, byte for byte.
GPG signature verification is a related but different check. A checksum tells you the file wasn't corrupted in transit. It does not tell you the checksum itself is trustworthy — if someone tampered with both the ISO and the checksum file on a shady mirror, a checksum comparison alone wouldn't catch it. GPG (GNU Privacy Guard) solves that by using public-key cryptography. Proxmox signs their release files with a private key only they hold, and you can verify that signature using their public key. If the signature checks out, you know the file was published by Proxmox and hasn't been altered since, no matter where you actually downloaded it from.
Why Would You Use It?
Most people skip this step and never run into trouble. Direct downloads over a stable connection usually complete cleanly. But a few situations make verification genuinely worth the ten minutes:
- You're on Wi-Fi, a VPN, or a flaky connection where downloads occasionally stall or resume mid-file
- You grabbed the ISO from a mirror, a shared network drive, or a colleague instead of proxmox.com directly
- You're about to wipe a physical server's disks to install Proxmox and don't want to discover a bad ISO after the fact
- You've hit a strange, unexplained install failure and want to rule out "bad download" before digging into BIOS settings or USB tools
Here's the honest version: if you've never had a download get corrupted, it's tempting to assume it can't happen to you. It can, and when it does, it rarely fails loudly. You just get a weird half-working installer that eats twenty minutes of your evening before you think to check the file itself.
Prerequisites
- A downloaded Proxmox VE ISO (as of this writing, the current release is proxmox-ve_9.2-1.iso, about 1.71 GB, built on Debian 13 "Trixie")
- A terminal on Linux or macOS, or PowerShell on Windows
- Internet access, so you can pull the published checksum and, optionally, the GPG signing key
- GPG installed if you want to do the signature check (most Linux distros and macOS have it or a one-line install; Windows users can use Gpg4win)
You don't need any Proxmox-specific tools for this. Everything here is standard, widely available software you'll likely use again for other Linux ISOs.
Step-by-Step Tutorial
Step 1: Download the ISO and Note the Published Checksum
Go to the official Proxmox VE downloads page and grab the ISO installer. The download page lists the SHA256 checksum right next to the file — for the current 9.2-1 release, it's:
4e88fe416df9b527624a175f24c9aa07c714d3332afb1ee3dbf3879573ef2c6cCopy that value somewhere you can paste it later, or just keep the browser tab open. The mirror at enterprise.proxmox.com/iso/ also hosts a matching .sha256 file and a detached .asc signature file alongside each ISO, which you'll want if you're doing the GPG check in Step 4.
Step 2: Compute the Hash on Your Own Machine
Open a terminal in the folder where the ISO landed and run the command for your operating system.
Linux
sha256sum proxmox-ve_9.2-1.isoThis prints the hash followed by the filename. It usually takes 20–40 seconds on a modern SSD for a file this size.
macOS
shasum -a 256 proxmox-ve_9.2-1.isomacOS doesn't ship sha256sum by default, but shasum is built in and does the same job with the -a 256 flag telling it which algorithm to use.
Windows
In PowerShell:
Get-FileHash .\proxmox-ve_9.2-1.iso -Algorithm SHA256Or, in an old-fashioned Command Prompt window:
certutil -hashfile proxmox-ve_9.2-1.iso SHA256Both work fine. certutil has been part of Windows since XP, so it's a handy fallback if PowerShell is locked down on a work machine.
Step 3: Compare the Hashes
Line up the string your machine just generated against the one from the downloads page. They need to match exactly — every character, case doesn't matter, but nothing can differ. Most people just eyeball the first six and last six characters, which catches the overwhelming majority of real mismatches without you having to squint at 64 characters for a minute straight.
If they match, your ISO is byte-for-byte identical to what Proxmox published. You're safe to burn it to USB and install.
Step 4 (Optional but Recommended): Verify the GPG Signature
This step confirms the file came from Proxmox in the first place, not just that it's internally consistent. Download the Proxmox release key and import it:
wget https://enterprise.proxmox.com/debian/proxmox-release-trixie.gpg
gpg --import proxmox-release-trixie.gpgThe current Proxmox VE 9.x release key has the fingerprint 24B3 0F06 ECC1 836A 4E5E FECB A7BC D142 0BFE 778E. It's worth double-checking that against the fingerprint listed on Proxmox's own site rather than trusting it blindly from any single source, this article included.
Next, download the matching .asc signature file from enterprise.proxmox.com/iso/ and run:
gpg --verify proxmox-ve_9.2-1.iso.asc proxmox-ve_9.2-1.isoA successful check prints Good signature from "Proxmox Release Key ...". You may also see a warning like This key is not certified with a trusted signature — that's normal for a key you just imported yourself and haven't manually marked as trusted. It doesn't mean the check failed.
Commands Explained
| Command | What It Does |
|---|---|
sha256sum <file> | Computes the SHA256 hash of a file on Linux and prints it to the terminal |
shasum -a 256 <file> | Same job as sha256sum, built into macOS |
Get-FileHash | PowerShell's built-in file hashing cmdlet; -Algorithm SHA256 selects the hash type |
certutil -hashfile <file> SHA256 | Windows' older command-line certificate utility, repurposed here to hash a file |
gpg --import <keyfile> | Adds a public key to your local GPG keyring so you can use it to verify signatures |
gpg --verify <sig> <file> | Checks that a detached signature was produced by the private key matching an imported public key, and that the signed file hasn't changed since |
Common Errors
The hash you compute doesn't match at all. This almost always means an incomplete or corrupted download, not a security problem. Delete the file and download it again, ideally with a download manager or wget -c that can resume properly instead of a browser tab you might have accidentally interrupted.
gpg: Can't check signature: No public key — you tried to run gpg --verify before importing the Proxmox release key. Go back and run the gpg --import command first.
BAD signature from GPG is a different animal from a hash mismatch and worth taking seriously. It means the file you have does not match what was actually signed by that key. Don't install it. Re-download from proxmox.com directly rather than a mirror, and check again.
On Windows, people sometimes get a "mismatch" that isn't real — they've copied a hash with a trailing space or a line break from a PDF or chat message. Paste into a plain text editor first if you're comparing by eye and something looks almost right but not quite.
Troubleshooting
If your hash keeps failing on every retry, even from a fresh download, the problem is sometimes upstream of your browser. Corporate proxies and some antivirus tools intercept and rewrite downloads in ways that break large binary files. Try downloading from a different network, or use curl -O / wget from a terminal instead of a browser, since command-line tools are less likely to have content-inspection software messing with the stream.
If you're stuck on a slow or unreliable connection, the official torrent link on the downloads page is often more resilient than a direct HTTPS download, since a torrent client verifies each piece as it arrives rather than trusting the whole file blindly at the end.
One more thing worth knowing: verifying the ISO file itself doesn't verify that your USB-writing tool copied it correctly afterward. Most tools (Rufus, balenaEtcher, dd) do this reliably, but if you're getting installer errors even after a clean checksum match, try re-writing the USB stick with a different tool before assuming the ISO is at fault again.
Best Practices
Always grab the checksum from the same page you download the ISO from, in the same browsing session, rather than an old bookmark or a checksum someone pasted into a forum post last year. Proxmox re-releases point versions fairly often, and an outdated checksum will never match a current ISO even if the file is perfectly fine.
If you manage more than a handful of Proxmox installs, it's worth keeping a small script around that automates the hash comparison instead of eyeballing 64 characters each time. Something as simple as piping the output of sha256sum through a comparison against a saved value removes the human-error factor entirely.
Treat a GPG signature failure very differently from a plain checksum mismatch. A checksum mismatch is usually just a bad download. A signature failure means the file doesn't trace back to Proxmox's actual signing key, and that's worth stopping and investigating rather than shrugging off.
Frequently Asked Questions
Do I really need to do this every single time I download Proxmox?
No. For a one-off homelab install on a stable home connection, most people skip it and never hit a problem. It's most worth doing before a production install, after a flaky download, or when you're troubleshooting an installer that's misbehaving for no obvious reason.
Is checking the SHA256 hash enough, or do I need to do the GPG step too?
The hash alone confirms the file isn't corrupted. It doesn't prove the file actually came from Proxmox rather than a tampered mirror that also published a matching fake checksum. GPG closes that gap. For a home lab, the hash check alone is usually sufficient; for anything you're deploying at work, do both.
My antivirus software flagged the ISO. Should I be worried?
Usually not. Large bootable Linux ISOs sometimes trigger heuristic false positives simply because antivirus engines aren't built to inspect disk images the way they inspect executables. A clean SHA256 match against the official published value is a far more reliable signal than an antivirus heuristic warning.
What if the hash doesn't match even after I re-download the file twice?
Try a different network or a wired connection instead of Wi-Fi, and download with wget or curl from a terminal instead of a browser. If it still fails, double-check you copied the correct checksum for the exact version and file you downloaded — mixing up the 9.2-1 checksum with an older 8.4-1 file is a surprisingly common mistake.
Can I verify the ISO after I've already burned it to USB?
Not directly with these commands, since writing to USB adds padding and partition structures that change the byte layout. Verify the ISO file itself before writing it. If you want extra assurance after writing, Rufus and balenaEtcher both have a built-in "verify after write" option that re-reads the USB stick and confirms it matches the source image.
Conclusion
This isn't a step most beginner guides mention, mostly because it works quietly in the background and you never notice it when nothing goes wrong. But the first time a "random" installer failure turns out to be a corrupted download, you'll understand why it's worth the five minutes. Run the hash check every time you're about to wipe a real server's disks, add the GPG step when you want certainty about the source, and you'll rule out an entire category of installer headaches before they start.