Fedora Live

These notes record details for putting a Fedora Live ISO image onto a USB flash drive or a DVD disc.

Get & Verify Live ISO Image

This section exhibits downloading and verifying a Fedora Live ISO image for the Xfce Desktop spin, in particular. But since downloading is trivial, this section largely details the steps in verifying the image once downloaded.

Get Fedora's public key

The Fedora project uses public-key encryption so that you can verify the authenticity and integrity of the ISO images you download. Each version (e.g., 24, 25) of Fedora has its own pair of private and public keys. So the first step is to import the public key for Fedora into your keyring. You can subsequently check that your keyring has the desired key. For example:

-> gpg2 --list-keys 'Fedora 25'
pub   rsa4096 2016-03-31 [SCE]
uid           [  full  ] Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>

This key applies to all editions of Fedora 25; use it even if you prefer a live image for a distribution other than the Xfce spin or the Workstation.

Download the ISO image

Download the ISO image for the Fedora distribution of your liking from the Get Fedora or Fedora Spins pages. Here the Fedora Xfce spin and the (GNOME) Workstation are retrieved for a 64-bit desktop. For whatever distribution you select, be sure to grab the 64-bit build or 32-bit build that matches your computer's architecture. For the Xfce spin:

-> wget --continue https://download.fedoraproject.org/pub/fedora/linux/releases/25/Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-25-1.3.iso

Or for the Workstation edition:

-> wget --continue https://download.fedoraproject.org/pub/fedora/linux/releases/25/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-25-1.3.iso

The handy option --continue tells wget to resume an interrupted download from where it left off, should it get disturbed.

Get checksums

Next, download the distribution's CHECKSUM file. A checksum file provides the expected digest (e.g., SHA-256) of an ISO image so that you can be confident you have the real deal. Which checksum file you download depends on the ISO image you wish to check. Several spins share a single checksum file:

-> wget https://spins.fedoraproject.org/static/checksums/Fedora-Spins-25-1.3-x86_64-CHECKSUM

-> grep iso Fedora-Spins-25-1.3-x86_64-CHECKSUM | cut -d' ' -f2

The grep command above concisely lists the ISO images that the file provides digests for. It omits the long digests themselves; these 64-character strings look like gibberish.

The workstation ISO has its own checksum file:

-> wget https://getfedora.org/en/static/checksums/Fedora-Workstation-25-1.3-x86_64-CHECKSUM

-> grep iso Fedora-Workstation-25-1.3-x86_64-CHECKSUM | cut -d' ' -f2

Verify checksums files themselves

Of course, you'll want to rest assured that the checksum files themselves are legit, and that's where the Fedora public key comes in. The Fedora project signs its checksum files with its private key. Use GnuPG to verify the signature:

-> gpg2 --verify-files Fedora-Spins-25-1.3-x86_64-CHECKSUM
gpg: Signature made Fri 18 Nov 2016 09:15:37 AM EST using RSA key ID 4089D8F2FDB19C98
gpg: Good signature from "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>" [full]

-> gpg2 --verify-files Fedora-Workstation-25-1.3-x86_64-CHECKSUM 
gpg: Signature made Fri 18 Nov 2016 09:15:52 AM EST using RSA key ID 4089D8F2FDB19C98
gpg: Good signature from "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>" [full]

Verify the ISO image

To verify an ISO image, you compute its digest locally and compare the result to the expected digest in the verified checksum file. Matching digests confirm the integrity of the ISO file. Delegate this job to sha256sum, which may need a few moments for due process:

-> grep Xfce Fedora-Spins-25-1.3-x86_64-CHECKSUM | sha256sum --check
Fedora-Xfce-Live-x86_64-25-1.3.iso: OK

Here, grep extracts the relevant content for input to sha256sum. This construct avoids irrelevant warnings when sha256sum examines the checksum file in whole:

-> sha256sum --check Fedora-Spins-25-1.3-x86_64-CHECKSUM
sha256sum: Fedora-LXDE-Live-x86_64-25-1.3.iso: No such file or directory
Fedora-LXDE-Live-x86_64-25-1.3.iso: FAILED open or read
Fedora-Xfce-Live-x86_64-25-1.3.iso: OK
sha256sum: Fedora-SoaS-Live-x86_64-25-1.3.iso: No such file or directory
Fedora-SoaS-Live-x86_64-25-1.3.iso: FAILED open or read
sha256sum: Fedora-KDE-Live-x86_64-25-1.3.iso: No such file or directory
Fedora-KDE-Live-x86_64-25-1.3.iso: FAILED open or read
sha256sum: Fedora-Cinnamon-Live-x86_64-25-1.3.iso: No such file or directory
Fedora-Cinnamon-Live-x86_64-25-1.3.iso: FAILED open or read
sha256sum: Fedora-MATE_Compiz-Live-x86_64-25-1.3.iso: No such file or directory
Fedora-MATE_Compiz-Live-x86_64-25-1.3.iso: FAILED open or read
sha256sum: WARNING: 19 lines are improperly formatted
sha256sum: WARNING: 5 listed files could not be read

The five files that sha256sum could not read were not downloaded; so no worries there. The improperly formatted lines comprise the checksum file's GnuPG signature plus commentary rather than digests and file names for examination; so no need to be alarmed.

Checking the workstation image is similar:

-> grep Live Fedora-Workstation-25-1.3-x86_64-CHECKSUM | sha256sum --check
Fedora-Workstation-Live-x86_64-25-1.3.iso: OK

Optionally browse the ISO image

You can use isoinfo (package genisoimage) to browse the file system on an ISO image:

-> isoinfo -fR -i Fedora-Xfce-Live-x86_64-25-1.3.iso

Here, option -i specifies the ISO image to examine, and combo -fR shapes the file listing; combo -lR would give more detail.

For more flexibility, you can mount an ISO image as a loop device and thereby browse its file system with the usual tool set. For example, as user root:

=> mount Fedora-Xfce-Live-x86_64-25-1.3.iso /mnt -o loop,ro 
-> ls -R /mnt
EFI/  Fedora-Legal-README.txt  isolinux/  LICENSE  LiveOS/

=> umount /mnt

Create a Live USB Drive: Direct Write

You can directly write your Fedora ISO image onto a USB flash drive with sufficient capacity. This approach is perhaps the simplest and quickest if you have a spare USB flash drive. It formats the drive and erases any existing data, however, so choose your target drive accordingly.

The venerable dd command does the main job. It will need the sector (or block) count and size, which isosize (package util-linux) can provide.

-> isosize -x Fedora-Xfce-Live-x86_64-25-1.3.iso
sector count: 548575, sector size: 2048

And you'll want to check that the image fits on your flash drive:

-> isosize Fedora-Xfce-Live-x86_64-25-1.3.iso
-> echo 'scale=2; 1123481600 / 1024^3' | bc

So, this image spans a little over 1 GiB.

The examples in these notes use /dev/sdd for the path to the USB flash drive. But your path may differ; use gnome-disks, blkid, lsblk, or findfs, say, to determine the proper path for your system. Now the main event:

=> dd if=Fedora-Xfce-Live-x86_64-25-1.3.iso count=548575 bs=2048 of=/dev/sdd
548575+0 records in
548575+0 records out
1123481600 bytes (1.1 GB) copied, 265.329 s, 4.2 MB/s

For a quick sanity check, verify that the number of bytes copied by dd matches the file size reported by isosize.

GNOME Disk Utility (executable gnome-disks, package gnome-disk-utility) offers an equivalent GUI tool called Restore Disk Image, which has the appealing and reassuring feature of displaying a progress bar. You select the Fedora ISO image to "restore" and the target drive to write it to. Access this somewhat-hidden option from a button in the program's top toolbar. Or, open it indirectly through file managers Nautilus and Thunar: right-click on the ISO image; choose Open With Other Application; then select Disk Image Writer.

The direct-write method works for bootable ISO images in general, not just Fedora's, and guides recommend it as the most reliable method. It does not support persistent overlays, however.

Create a Live USB Drive: Live CD Tools

You can also use livecd-iso-to-disk (package livecd-tools) to install a Fedora Live OS from its ISO image onto a USB flash drive. This tool offers two modes. The destructive mode formats and wipes the entire flash drive. The (mostly) non-destructive mode installs the live OS to an existing partition on the flash drive but does not format the drive or erase other data. Either way, the drive does not retain the ISO file system of its source image.

If you are content to overwrite the flash drive, use option --format and supply the drive's path without any partition number. For a UEFI host:

=> livecd-iso-to-disk --noverify --format --efi Fedora-Xfce-Live-x86_64-25-1.3.iso /dev/sdd
Press Enter to continue or ctrl-c to abort

Target device is now set up with a Live image!

For a BIOS host, replace option --efi with --reset-mbr:

=> livecd-iso-to-disk --noverify --format --reset-mbr Fedora-Xfce-Live-x86_64-25-1.3.iso /dev/sdd

Target device is now set up with a Live image!

By default, livecd-iso-to-disk verifies the MD5 hash value embedded into the ISO image. If you've already checked the image, you can include option --noverify to skip this redundant step.

When called with both options --format and --efi together, livecd-iso-to-disk formats the drive as a GPT disk and creates a FAT partition spanning the drive. When called with option --format but without option --efi, it formats the drive as an MBR disk and creates an ext4 partition over the drive. In both cases, it labels the partition LIVE and installs the Fedora Live OS into the partition.

Option --reset-mbr writes the Master Boot Record of the target USB flash drive (using mbr.bin or gptmbr.bin from SysLinux). You may be able to omit this option if you were already booting from your drive. If you've reformatted your drive (partition table and all), you'll likely want to reset the MBR. Also, if QEMU cannot find your hard drive after loading firmware, try using this option.

With a little more attention and perhaps effort, you can have livecd-iso-to-disk put Fedora Live into an existing partition on a flash drive with neighborly decorum. While livecd-iso-to-disk will create or alter directories EFI, LiveOS, and syslinux on the target partition, it will not otherwise muck around with the drive's format, partitions, and files; be sure to omit the --format option. You'll specify the partition's path (e.g., /dev/sdd1) rather than the drive's path as a whole (e.g., /dev/sdd). The partition must be marked as bootable and have a FAT, ext, or btrfs file system. Remaining details differ a little between MBR/BIOS and GPT/UEFI cases. On an MBR drive for a BIOS host:

=> livecd-iso-to-disk --reset-mbr --noverify Fedora-Xfce-Live-x86_64-25-1.3.iso /dev/sdd1
Copying live image to target device.

Target device is now set up with a Live image!

On a GPT drive for a UEFI host, the target partition must be labeled "EFI System Partition". Replace option --reset-mbr with --efi in the command above:

=> livecd-iso-to-disk --noverify --efi Fedora-Xfce-Live-x86_64-25-1.3.iso /dev/sdd1

livecd-iso-to-disk is a shell script, so you can easily read the source if you need to troubleshoot or if just want to have a deeper look.

-> file `which livecd-iso-to-disk`
/usr/bin/livecd-iso-to-disk: Bourne-Again shell script, ASCII text executable

Create a Live USB Drive: Fedora Media Writer

Fedora Media Writer (package mediawriter) is a simple GUI utility for putting a Fedora Live OS onto a USB flash drive. It offers to download a selection of live distributions for the source OS. It can also use a local ISO image of a distribution you've already grabbed; it calls this a "Custom image". To make a Fedora Live USB flash drive, open FMW (command mediawriter). From the rolling GUI, select the source distribution and the target USB flash drive. FMW offers only the destructive overwrite, so use a spare flash drive.

FMW replaces LiveUSB Creator, apparently. Its GUI is not-quite ready for prime time, IMHO, particularly its tiny fonts.

Create a Live USB Drive: LiveUSB Creator

It looks like Fedora Media Writer has replaced LiveUSB Creator.

LiveUSB Creator (package liveusb-creator) is an easy-to-use GUI utility for putting a Fedora Live OS onto a USB flash drive. It can use a local ISO image of any Fedora Live distribution for the source OS. It also offers to download a selection of live distributions. To make a Fedora Live USB flash drive, open LiveUSB Creator (command liveusb-creator) as user root. From the concise GUI, select the source distribution via browsing or downloading, the target USB flash drive, and the size of any persistent storage desired. Then choose one of two methods for installing the live OS: "Non-destructive (cp)" or "Overwrite Device (dd)". The former is similar to using livecd-iso-to-disk without the --format option. The latter uses dd on your behalf.

LiveUSB Creator appears to be blind to a drive lacking an existing FAT or ext partition.

LiveUSB Creator has a Windows version, too.

Preliminary observations for the non-destructive (cp) method: This method requires a FAT or NTFS partition (for syslinux). QEMU falters trying to boot from a flash drive made with this way.

Create a Live DVD

You can of course burn the Fedora ISO image onto a DVD (DVD+RW or DVD-RW) disc, for which you have several tools to choose from. Here's a working example on my system; YMMV:

-> cdrskin dev=/dev/sr0 Fedora-Xfce-Live-x86_64-25-1.3.iso

Track 01: Total bytes read/written: 1124073472/1124073472 (548864 sectors).

Verify Boot Medium

Once your machine boots from the Fedora Live image, the boot manager offers to check the underlying medium—your disk file, USB flash drive, or DVD disc. Choose option Test this media & and start Fedora-Xfce-Live 25. You can check this way from a virtual machine, too.

Under the hood, this test uses checkisomd5 (package isomd5sum). When you create a live medium with dd, you can invoke checkisomd5 explicitly if you wish to verify your drive or disc before booting from it. Simply provide the device path. For a USB flash drive at /dev/sdd:

=> checkisomd5 /dev/sdd
Press [Esc] to abort check.

The media check is complete, the result is: PASS.

It is OK to use this media.

For a DVD in drive /dev/sr0:

-> checkisomd5 /dev/sr0

You can even check the ISO file:

-> checkisomd5 Fedora-Live-Xfce-x86_64-25-1.3.iso

Add option --verbose for a simple progress meter.

You cannot use checkisomd5 directly as above if you created your USB flash drive with livecd-iso-to-disk because the drive's file system is not an ISO file system:

-> checkisomd5 /dev/sdd
Press [Esc] to abort check.

The media check is complete, the result is: FAIL.

It is not recommended to use this media.

In this case, boot from the USB flash drive and let the boot manager do the work on your behalf.

Alternatively, you can use generic tools like cksum and md5sum to verify the fidelity of your boot medium. But, you have to be particular in specifying what you compare because there's a surprise lurking in what seems like the obvious comparisons. See here, for example:

-> cksum Fedora-Xfce-Live-x86_64-25-1.3.iso 
1110156987 1124073472 Fedora-Xfce-Live-x86_64-25-1.3.iso
-> cksum /dev/sr0
3868348437 4700372992 /dev/sr0
=> cksum /dev/sdc
447526699 4007657472 /dev/sdc

Three different media, three different checksums; oh my. The glitch is that an ISO file may append bytes beyond the ISO image that it embeds (see isozize):

-> isosize Fedora-Xfce-Live-x86_64-25-1.3.iso 
-> wc --bytes Fedora-Xfce-Live-x86_64-25-1.3.iso  
stat --format "%s" Fedora-Xfce-Live-x86_64-25-1.3.iso
-> echo '1124073472 - 1123481600' | bc

ISO handlers like isosize account for this; they extract the ISO image and ignore extraneous bytes. Generic file tools, like wc and stat above, brook no such ISO entitlement; they slurp the whole beast.

You can have dd manage the particulars. First, get the sector count and size of the ISO image:

-> isosize -x Fedora-Xfce-Live-x86_64-25-1.3.iso
sector count: 548575, sector size: 2048

Now examine the corresponding sectors from the different media. With cksum, for example:

-> dd count=548575 bs=2048 if=Fedora-Xfce-Live-x86_64-25-1.3.iso 2>/dev/null | cksum
2668834757 1123481600
-> dd count=548575 bs=2048 if=/dev/sr0 2>/dev/null | cksum
2668834757 1123481600
=> dd count=548575 bs=2048 if=/dev/sdc 2>/dev/null | cksum
2668834757 1123481600

Or with md5sum:

-> dd count=548575 bs=2048 if=Fedora-Xfce-Live-x86_64-25-1.3.iso 2>/dev/null | md5sum
b926112a6477fcc851ed5643822f39fe  -
-> dd count=548575 bs=2048 if=/dev/sr0 2>/dev/null | md5sum
b926112a6477fcc851ed5643822f39fe  -
=> dd count=548575 bs=2048 if=/dev/sdc 2>/dev/null | md5sum
b926112a6477fcc851ed5643822f39fe  -

And so on with the SHA-2 digests (224, 256, 384, 512) if you really want to go all out.

You can also use readom to extract the ISO image, although it's a bit needy. First from the USB flash drive:

-> readom dev=/dev/sdc sectors=0-0 -f - 2>&1 | grep Sectorsize
Sectorsize: 512 Bytes
-> isosize=`isosize Fedora-Live-Xfce-x86_64-21-5.iso`
-> echo $isosize
-> echo $(($isosize / 512))
-> readom dev=/dev/sdc sectors=0-1825388 -silent -f - | cksum

3155917535 934598656
-> readom dev=/dev/sdc sectors=0-1825388 -silent -f - | md5sum

f02ca9bec6cc7b59826b84da93450764  -

Now from the DVD:

-> readom dev=/dev/sr0 sectors=0-456347 -silent -f - | cksum

3155917535 934598656
-> readom dev=/dev/sr0 sectors=0-456347 -silent -f - | md5sum

f02ca9bec6cc7b59826b84da93450764  -

Preview with QEMU

You can use QEMU to launch Fedora Live from a file, DVD, or USB flash drive. The QEMU command to invoke depends on your computer's processor. Here, qemu-kvm does the job for an Intel i3 processor, which is a 64-bit architecture and which supports virtualization technology extensions (Intel VT). How you specify the arguments to qemu-kvm depends on what medium holds the Live OS and on how the Live OS got there.

You can launch Fedora Live from its ISO image, whether that image resides on a disk drive, on a DVD disc, or on a USB flash drive. Just tell QEMU to interpret the medium as a CDROM drive. To launch Fedora Live from its on-disk ISO image:

-> qemu-kvm -m 4G -boot order=d -cdrom Fedora-Xfce-Live-x86_64-25-1.3.iso 

To instead launch Fedora Live from a disc in your computer's DVD drive (e.g., /dev/sr0):

-> qemu-kvm -m 4G -boot order=d -cdrom /dev/sr0

If dd copied the ISO image onto your USB flash drive, QEMU will see the drive as a CDROM, too. You'll likely need to be root to launch Fedora from the drive, but you can tell QEMU to run its VM as an ordinary user:

=> qemu-kvm -runas ray -m 4G -boot order=d -cdrom /dev/sdd

Adjust the paths (/dev/sr0, /dev/sdd) and allotted memory (option -m) to suit your host machine. You can omit option -boot order=d if you wish.

Left to its own volition, QEMU emulates a BIOS-based computer. Fedora Live images support UEFI-based machines, too, and you can have QEMU emulate a UEFI-based computer by providing suitable firmware. Here are the previous examples modified slightly to use Open Virtual Machine Firmware (OVMF) downloaded into local file efi.bin:

-> qemu-kvm -m 4G -bios efi.bin -boot order=d -cdrom Fedora-Xfce-Live-x86_64-25-1.3.iso 
-> qemu-kvm -m 4G -bios efi.bin -boot order=d -cdrom /dev/sr0
=> qemu-kvm -runas ray -m 4G -bios efi.bin -boot order=d -cdrom /dev/sdd

For launching Fedora Live from a USB flash drive prepared by livecd-iso-to-disk, identify the flash drive as an HDD rather than a CDROM:

=> qemu-kvm -runas ray -m 4G -drive file=/dev/sdd,format=raw,media=disk,index=0

If you called livecd-iso-to-disk with --efi, you can also use the OVMF firmware with QEMU:

=> qemu-kvm -runas ray -m 4G -bios efi.bin -drive file=/dev/sdd,format=raw,media=disk,index=0

If you abbreviate that long -drive description with '-hda /dev/sdd' instead, QEMU (version 2.4.1) will gripe:

WARNING: Image format was not specified for '/dev/sdd' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.

But then, it seems to work fine thereafter; go figure. The longer description is how you tell QEMU about the raw format.

You can change the ownership of your USB flash drive to avoid running QEMU as root. For example:

=> chown ray:ray /dev/sdd
-> qemu-kvm -m 4G -drive file=/dev/sdd,format=raw,media=disk,index=0

Import Fedora's Public Key

The Fedora project signs its ISO images so that users can verify both the validity and integrity of their downloaded copies. Each Fedora version has its own public key(s). This section shows how to add the primary public key for Fedora 25, in particular, to your GnuPG keyring.


Download and import the primary key for Fedora 25 (in section Currently Used Keys):

-> curl --silent https://getfedora.org/static/FDB19C98.txt | gpg2 --import
gpg: key 4089D8F2FDB19C98: public key "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

The filename FDB19C98.txt reflects the key's ID; discover this ID by reading the Fedora page. This ID changes with each version of Fedora.

Alternatively, download the cumulative file of keys, both primary and secondary:

-> curl --silent https://getfedora.org/static/fedora.gpg | gpg2 --import

gpg: key 4089D8F2FDB19C98: public key "Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>" imported
gpg: key 1A185CDDE372E838: public key "Fedora 25 Secondary (25) <fedora-25-secondary@fedoraproject.org>" imported
gpg: key 812A6B4B64DAB85D: public key "Fedora 26 Primary (26) <fedora-26-primary@fedoraproject.org>" imported
gpg: key 4560FD4D3B921D09: public key "Fedora 26 Secondary (26) <fedora-26-secondary@fedoraproject.org>" imported

gpg: Total number processed: 11
gpg:               imported: 4
gpg:              unchanged: 7

Either way, your keyring now includes the desired key:

-> gpg2 --list-keys 'Fedora 25 Primary'
pub   rsa4096 2016-03-31 [SCE]
uid           [ unknown] Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>

The first line shows the key's main properties: The Fedora 25 Primary key is a public key ("pub") using RSA with a length of 4096 bits ("rsa4096"); it was created on 2016-03-31; it can be used for signing, certification, and encryption ("[SCE]"). The second line gives the key's fingerprint, from which the ID FDB19C98 is taken. The third line reveals GnuPG's initial trust issues ("[unknown]") in this key; you'll reassure GnuPG in a moment.


Verify the key by visually comparing the fingerprint published by Fedora to the fingerprint reported by gpg:

C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98
-> gpg2 --fingerprint "Fedora 25 Primary"
pub   rsa4096 2016-03-31 [SCE]
      C437 DCCD 558A 66A3 7D6F  4372 4089 D8F2 FDB1 9C98
uid           [ unknown] Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>


Sign the verified keys with the password of the user specified:

-> gpg --sign-key "Fedora 25 Primary"

Really sign? (y/N) y

You need a passphrase to unlock the secret key for
user: "user root (For system administration.)"
2048-bit RSA key, ID 7267D06D, created 2015-01-13


Last, assure GnuPG that you trust the key's fingerprint:

-> gpg --fingerprint "Fedora 25 Primary" | grep fingerprint | cut -d= -f2  | tr --delete [:blank:]
-> echo "C437DCCD558A66A37D6F43724089D8F2FDB19C98:5:" | gpg2 --import-ownertrust
gpg: setting ownertrust to 5

The first command computes the fingerprint and reports it without extraneous commentary. In the second command, the appended :5: indicates full trust in the preceding fingerprint; you can use :4: for marginal trust. Now GnuPG no longer harbors trust issues:

-> gpg2 --list-keys 'Fedora 25 Primary'

pub   rsa4096 2016-03-31 [SCE]
uid           [  full  ] Fedora 25 Primary (25) <fedora-25-primary@fedoraproject.org>

More on checkisomd5

An ISO image from Fedora (and other distributions) embeds its own MD5 value, which gets mirrored onto any duplicate of the image. When verifying an image, checkisomd5 computes the MD5 sum anew and compares it to the expected MD5 value. You can have checkisomd5 just report the embedded MD5 value, if you are curious:

-> checkisomd5 --md5sumonly Fedora-Live-Xfce-x86_64-21-5.iso
Fedora-Live-Xfce-x86_64-21-5.iso:   e3ae85c13c4e8c8da9f21744fa416a21

-> checkisomd5 --md5sumonly /dev/sdc
/dev/sdc:   e3ae85c13c4e8c8da9f21744fa416a21

This usage does not establish data integrity because it merely retrieves and displays the embedded value; it does not compute anything. Of course, if these two values do not match, you've got a problem.

Beware that the MD5 value that checkisomd5 reports will not match the MD5 value that md5sum calculates for the image file. For example:

-> md5sum Fedora-Live-Xfce-x86_64-21-5.iso
87140e0f79bb1cb059f9e6081afb76af  Fedora-Live-Xfce-x86_64-21-5.iso

There's a subtlety lurking here rather than an error skulking about. The embedded digest corresponds to the distribution's original ISO image, but it is not the digest of the downloaded ISO file. What's going on? The utility implantisomd5 (package isomd5sum) modifies a distribution's penultimate ISO image by embedding an MD5 value in an otherwise unused section of the image. This modified image is the final image you download. The companion utility checkisomd5 duly accounts for this adjustment and thereby examines the same nominal data stream that implantisomd5 processed. But md5sum has no knowledge of these shenanigans and can only examine the final ISO file as-is.

Here's a wordier version of the story. First, generate an ISO image to tinker with and duplicate it for comparison later on:

-> genisoimage -input-charset utf-8 -rock -o tinker.iso -quiet ~/scratch/spool
-> cp tinker.iso tinker-orig.iso

Next, implant the MD5 sum into tinker.iso:

-> implantisomd5 tinker.iso
Inserting md5sum into iso image...
md5 = 1e00ffa9d28367b5f2512d2855c2fdc4

Now tinker.iso has an embedded MD5 sum, as reported, but tinker-orig.iso does not:

-> checkisomd5 --md5sumonly tinker.iso 
tinker.iso:   1e00ffa9d28367b5f2512d2855c2fdc4

-> checkisomd5 --md5sumonly tinker-orig.iso 

No checksum information available, unable to verify media.

Notice that implantisomd5 does not alter the file size:

-> wc --bytes tinker-orig.iso tinker.iso | head -2
1095680 tinker-orig.iso
1095680 tinker.iso

Still, the different MD5 sums for tinker.iso and tinker-orig.iso reflect the alteration, as expected.

-> md5sum tinker-orig.iso tinker.iso
855f5264cc73cc2b979d700f1076886c  tinker-orig.iso
b62455b7fe2a2ba12720fba4253dc52c  tinker.iso

This sequence incidentally reveals that the embedded digest also differs from the digest for the original and unadulterated image tinker-orig.iso.

As it turns out, implantisomd5 quietly reports the subtlety in passing. To see this, first note that tinker.iso and tinker-orig.iso now differ for only 226 bytes:

-> cmp tinker.iso tinker-orig.iso 
tinker.iso tinker-orig.iso differ: byte 33652, line 1
-> cmp --ignore-initial=$((33652+226)) tinker.iso tinker-orig.iso

The latter comparison completes without comment, thus indicating that the tails are identical. That length of 226 was determined by trial and error. Now have a look at those 226 bytes:

-> dd if=tinker.iso ibs=1 skip=33651 count=226 2>/dev/null | perl -pe 's{;}{\n}g'; echo
ISO MD5SUM = 1e00ffa9d28367b5f2512d2855c2fdc4
FRAGMENT SUMS = 41dbc1b8bbee45a73928ff6c596b95bcfa1128ffa24ce94cb6421b1d1a6f

This exhibit does not elucidate exactly what implantisomd5 and checkisomd5 examine. That exercise (perhaps through source code) is left to the reader.