Fedora Live

A Fedora Live image is a hybrid ISO image designed to boot and run a Fedora distribution from a USB flash drive or a DVD, on any host computer that supports booting from such media. It supports both BIOS hosts and UEFI hosts. These notes record details for putting a Fedora Live ISO image onto a USB flash drive or a DVD disc.

Get and 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 of Fedora (e.g., 27, 28) 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 28'
pub   rsa4096/E08E7E629DB62FB1 2017-08-14 [SCE]
      Key fingerprint = 128C F232 A937 1991 C8A6  5695 E08E 7E62 9DB6 2FB1
uid                 [  full  ] Fedora 28 (28) <[email protected]>

This key applies to all editions of Fedora 28; 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/28/Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-28-1.1.iso

Or for the Workstation edition:

-> wget --continue https://download.fedoraproject.org/pub/fedora/linux/releases/28/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-28-1.1.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-28-1.1-x86_64-CHECKSUM
-> grep '#' Fedora-Spins-28-1.1-x86_64-CHECKSUM 
# Fedora-Cinnamon-Live-x86_64-28-1.1.iso: 1833959424 bytes
# Fedora-KDE-Live-x86_64-28-1.1.iso: 1924136960 bytes
# Fedora-LXDE-Live-x86_64-28-1.1.iso: 1261436928 bytes
# Fedora-LXQt-Live-x86_64-28-1.1.iso: 1282408448 bytes
# Fedora-MATE_Compiz-Live-x86_64-28-1.1.iso: 1960837120 bytes
# Fedora-SoaS-Live-x86_64-28-1.1.iso: 963641344 bytes
# Fedora-Xfce-Live-x86_64-28-1.1.iso: 1385168896 bytes

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-28-1.1-x86_64-CHECKSUM
-> grep '#' Fedora-Workstation-28-1.1-x86_64-CHECKSUM 
# Fedora-Workstation-Live-x86_64-28-1.1.iso: 1787822080 bytes
# Fedora-Workstation-netinst-x86_64-28-1.1.iso: 611319808 bytes

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-28-1.1-x86_64-CHECKSUM
gpg: Signature made Fri 27 Apr 2018 08:42:35 AM EDT
gpg:                using RSA key E08E7E629DB62FB1
gpg: Good signature from "Fedora 28 (28) <[email protected]>" [full]
Primary key fingerprint: 128C F232 A937 1991 C8A6  5695 E08E 7E62 9DB6 2FB1

-> gpg2 --verify-files Fedora-Workstation-28-1.1-x86_64-CHECKSUM
gpg: Signature made Fri 27 Apr 2018 08:42:15 AM EDT
gpg:                using RSA key E08E7E629DB62FB1
gpg: Good signature from "Fedora 28 (28) <[email protected]>" [full]
Primary key fingerprint: 128C F232 A937 1991 C8A6  5695 E08E 7E62 9DB6 2FB1

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-28-1.1-x86_64-CHECKSUM | sha256sum --check
Fedora-Xfce-Live-x86_64-28-1.1.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-28-1.1-x86_64-CHECKSUM
sha256sum: Fedora-Cinnamon-Live-x86_64-28-1.1.iso: No such file or directory
Fedora-Cinnamon-Live-x86_64-28-1.1.iso: FAILED open or read
sha256sum: Fedora-KDE-Live-x86_64-28-1.1.iso: No such file or directory
Fedora-KDE-Live-x86_64-28-1.1.iso: FAILED open or read
sha256sum: Fedora-LXDE-Live-x86_64-28-1.1.iso: No such file or directory
Fedora-LXDE-Live-x86_64-28-1.1.iso: FAILED open or read
sha256sum: Fedora-LXQt-Live-x86_64-28-1.1.iso: No such file or directory
Fedora-LXQt-Live-x86_64-28-1.1.iso: FAILED open or read
sha256sum: Fedora-MATE_Compiz-Live-x86_64-28-1.1.iso: No such file or directory
Fedora-MATE_Compiz-Live-x86_64-28-1.1.iso: FAILED open or read
sha256sum: Fedora-SoaS-Live-x86_64-28-1.1.iso: No such file or directory
Fedora-SoaS-Live-x86_64-28-1.1.iso: FAILED open or read
Fedora-Xfce-Live-x86_64-28-1.1.iso: OK
sha256sum: WARNING: 19 lines are improperly formatted
sha256sum: WARNING: 6 listed files could not be read

The six 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-28-1.1-x86_64-CHECKSUM | sha256sum --check
Fedora-Workstation-Live-x86_64-28-1.1.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-28-1.1.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-28-1.1.iso /mnt -o loop,ro 
=> ls -R /mnt
EFI  Fedora-Legal-README.txt  images  isolinux  LICENSE  LiveOS  TRANS.TBL
=> umount /mnt

Create a Live USB Drive: Direct Write

You can directly write your Fedora Live 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. You can use Fedora Media Writer, venerable dd, and Gnome Disk Utility. All format the drive and copy the ISO image onto it, thus obliterating any existing data; so choose a spare drive.

The Fedora Installation Guide encourages use of Fedora Media Writer (package mediawriter) for creating Live USB media: "Fedora Media Writer has been improved and is now the default way to make bootable media." It 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 Fedora Media Writer (command mediawriter). From the scrolling menu, select the source distribution and the target USB flash drive.

Fedora Media Writer replaced LiveUSB Creator.

You can also copy a Fedora Live ISO image to a USB flash drive using old-school dd from the command line. It will need the sector (or block) count and size, which isosize (package util-linux) can provide:

-> isosize -x Fedora-Xfce-Live-x86_64-28-1.1.iso
sector count: 676153, sector size: 2048

This example has /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-28-1.1.iso of=/dev/sdd count=676153 bs=2048
676153+0 records in
676153+0 records out
1384761344 bytes (1.4 GB, 1.3 GiB) copied, 700.088 s, 2.0 MB/s

For a quick sanity check, you can verify that the number of bytes copied by dd matches the image size reported by isosize; see note below.

You can omit that sector bookkeeping if you prefer:

 => dd if=Fedora-Xfce-Live-x86_64-28-1.1.iso of=/dev/sdd
2705408+0 records in
2705408+0 records out
1385168896 bytes (1.4 GB, 1.3 GiB) copied, 697.073 s, 2.0 MB/s

You'll get some extra but ostensibly harmless sectors appended, however:

-> echo '(1385168896-1384761344)/2048' | bc

Gnome Disk Utility (executable gnome-disks, package gnome-disk-utility) offers a GUI tool called Restore Disk Image that copies disk images. It sports 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. For example:

=> dd if=linuxmint-19-cinnamon-64bit-v2.iso of=/dev/sdd bs=2048
948416+0 records in
948416+0 records out
1942355968 bytes (1.9 GB, 1.8 GiB) copied, 902.24 s, 2.2 MB/s
=> dd if=ubuntu-18.04.1-desktop-amd64.iso of=/dev/sdd
3815136+0 records in
3815136+0 records out
1953349632 bytes (2.0 GB, 1.8 GiB) copied, 948.51 s, 2.1 MB/s

If you want to check that an ISO image will fit on your flash drive:

-> isosize Fedora-Xfce-Live-x86_64-28-1.1.iso
-> echo 'scale=2;  1384761344 / 1024^3' | bc
-> echo 'scale=2;  1384761344 / 1000^3' | bc

So, this image spans just under 1.3 GiB or 1.4 GB.

Direct-write does not support persistent overlays.

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 BIOS host:

=> livecd-iso-to-disk --noverify --resetmbr --format Fedora-Xfce-Live-x86_64-28-1.1.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. Options --format and --resetmbr together format the drive as an MBR disk, create an ext4 partition spanning most of the drive, and label that partition LIVE. The Fedora Live OS is then installed onto this partition.

For a EFI host, add option --efi:

=> livecd-iso-to-disk --noverify --resetmbr --format --efi Fedora-Xfce-Live-x86_64-26-1.5.iso /dev/sdd
Setting up /EFI/BOOT
Updating boot config files.
Installing boot loader...
Target device is now set up with a Live image!

Here, livecd-iso-to-disk formats the drive as a GPT disk and creates a FAT partition spanning most of the drive. It labels that partition "EFI System Partition" and installs the Fedora Live OS into the partition. (But see next note for versions after 26.)

For Fedora 24–26, at least, you can set-up your USB drive to boot under an EFI host as above. For Fedora 27 and 28, however, livecd-iso-to-disk with option --efi fails:

=> livecd-iso-to-disk --noverify --format --efi Fedora-Xfce-Live-x86_64-27-1.6.iso /dev/sdd
Setting up /EFI/BOOT
No BOOT*.EFI found in eltorito image. EFI will not boot

(cf. Errors creating Fedora 27 live stick)

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

You can also use livecd-iso-to-disk to put multiple Fedora Live spins on a single USB drive. This example puts the Xfce, LXQt, and Gnome (i.e., Workstation) spins on a single USB flash drive. For the first spin, include options --resetmbr and --format to format and partition the drive and to install Syslinux:

=> livecd-iso-to-disk --noverify --resetmbr --format --livedir Xfce  Fedora-Xfce-Live-x86_64-28-1.1.iso /dev/sdd

This formats the drive as an MBR disk with a single Ext4 partition spanning most of the capacity. For additional spins, use option --multi (instead of options --resetmbr and --format), and replace device /dev/sdd with partition /dev/sdd1:

=> livecd-iso-to-disk --noverify --multi --livedir Gnome Fedora-Workstation-Live-x86_64-28-1.1.iso  /dev/sdd1
=> livecd-iso-to-disk --noverify --multi --livedir LXQt  Fedora-LXQt-Live-x86_64-28-1.1.iso         /dev/sdd1

Option --livedir names and creates the directory for each spin's files on the flash drive.

For the previous example, the boot menu offers the following items:

Go to Gnome ~Fedora-Workstation-Live 28 menu
Go to LXQt ~Fedora-LXQt-Live 28 menu
Start Fedora-Xfce-Live 28
Test this media & start Fedora-Xfce-Live 28
Start Fedora-Xfce-Live 28 in basic graphics mode
Run a memory test
Boot from local drive
Return to main menu

Note the special treatment of the first spin added (Xfce in this example). You can add a "go to menu" item for the first spin as well with this tweak:

=> livecd-iso-to-disk --noverify --skipcopy --multi --livedir Xfce Fedora-Xfce-Live-x86_64-28-1.1.iso /dev/sdd1

(This adds subdirectory /Xfce/syslinux and registers its corresponding boot-menu entry—by virtue of option --multi. Option --skipcopy prevents re-copying the spin's large image file to the drive (i.e., /Xfce/squashfs.img); the first command above copied it there already.)

To customize the boot menu created by livecd-iso-to-disk, edit the Syslinux/Extlinux configuration file on the USB flash drive, /syslinux/extlinux.conf.

livecd-iso-to-disk is designed to write Fedora Live images from a running Fedora system; it does note handle live images for other distributions of GNU, Linux, and Co. It 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 DVD

You can of course burn the Fedora ISO image onto an optical disc, DVD+RW or DVD-RW, 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-28-1.1.iso
Track 01: Total bytes read/written: 1385168896/1385168896 (676352 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 an ISO file, a USB flash drive or a DVD. 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 tell QEMU to interpret the medium as an optical disc (i.e., a DVD) or a hard disk, and you tell QEMU to emulate a BIOS host or an EFI host.

The snappiest way to preview a Fedora distribution is to have QEMU launch it directly from the Live ISO image on disk. Left to its own volition, QEMU emulates a BIOS-based computer; this simple command boots Fedora:

-> qemu-kvm -m 4G -cdrom Fedora-Xfce-Live-x86_64-28-1.1.iso

To emulate an EFI host, you need to provide QEMU with suitable firmware. Here is the previous example modified slightly to use UEFI firmware from the Open Virtual Machine Firmware (OVMF) project, previously downloaded into file efi.bin:

=> ls efi.bin
-> qemu-kvm -m 4G -cdrom Fedora-Xfce-Live-x86_64-28-1.1.iso -bios efi.bin

Option -m tells QEMU how much of your system's memory it can bogart for its RAM; adjust to your tastes. Option -cdrom tells QEMU to interpret the file as an optical disc. Here's an alternative albeit wordier way to express this:

-> qemu-kvm -m 4G -drive file=Fedora-Xfce-Live-x86_64-28-1.1.iso,media=cdrom

But that's just for the record.

A USB drive written by a direct method can be interpreted as either a hard disk or an optical disc, and it can boot under both a BIOS host and an EFI host. Any of these will do:

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

These commands are invoked by user root for access to /dev/sdd. Option -runas tells QEMU to downgrade privileges to another user (e.g., ray). Or, 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

Option -runas can then be dropped.

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

=> qemu-kvm -runas ray -m 4G -hda /dev/sdd
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. (The other format appears to be Base64 encoding.)

You can launch Fedora Live from an optical disc in your computer's DVD drive, say /dev/sr0:

-> qemu-kvm -m 4G -cdrom /dev/sr0
-> qemu-kvm -m 4G -cdrom /dev/sr0 -bios efi.bin

For these emulations, you need not run QEMU as user root and can thus omit option -runas.

For launching Fedora Live from a USB flash drive prepared by livecd-iso-to-disk, identify the flash drive as an HDD. For a BIOS host:

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

If you called livecd-iso-to-disk with --efi for a UEFI host, you can use the OVMF firmware with QEMU:

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

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 29, in particular, to your GnuPG keyring.


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

-> curl --silent https://getfedora.org/static/429476B4.txt | gpg2 --import
gpg: key A20AA56B429476B4: public key "Fedora 29 (29) <[email protected]>" imported
gpg: Total number processed: 1
gpg:               imported: 1

The filename 429476B4.txt reflects the key's ID; you get this key ID from 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 E08E7E629DB62FB1: "Fedora 28 (28) <[email protected]>" not changed
gpg: key A20AA56B429476B4: "Fedora 29 (29) <[email protected]>" not changed
gpg: key EF3C111FCFC659B9: public key "Fedora (30) <[email protected]>" imported
gpg: key 3B49DF2A0608B895: public key "EPEL (6) <[email protected]>" imported
gpg: key 6A2FAEA2352C64E5: public key "Fedora EPEL (7) <[email protected]>" imported
gpg: key 7BB90722DBBDCF7C: public key "Fedora (iot 2019) <[email protected]>" imported
gpg: Total number processed: 6
gpg:               imported: 4
gpg:              unchanged: 2

Either way, your keyring now includes the desired key:

-> gpg2 --list-keys 'Fedora 29'
pub   rsa4096/A20AA56B429476B4 2018-02-17 [SCE]
      Key fingerprint = 5A03 B4DD 8254 ECA0 2FDA  1637 A20A A56B 4294 76B4
uid                 [ unknown] Fedora 29 (29) <[email protected]>

The first line shows the key's main properties: The Fedora 29 key is a public key ("pub") using RSA with a length of 4096 bits ("rsa4096"); it was created on 2018-02-17; it can be used for signing, certification, and encryption ("[SCE]"). The second line gives the key's fingerprint, from which the ID 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:

5A03 B4DD 8254 ECA0 2FDA  1637 A20A A56B 4294 76B4 copy-and-paste
-> gpg2 --fingerprint "Fedora 29"
pub   rsa4096/A20AA56B429476B4 2018-02-17 [SCE]
      Key fingerprint = 5A03 B4DD 8254 ECA0 2FDA  1637 A20A A56B 4294 76B4
uid                 [ unknown] Fedora 29 (29) <[email protected]>

Good: the two fingerprints of separate provenance match.


Sign the verified keys:

-> gpg2 --sign-key "Fedora 29"
Really sign? (y/N) y


Last, assure GnuPG that you trust the key, given by its fingerprint (without spaces):

-> echo '5A03B4DD8254ECA02FDA1637A20AA56B429476B4:5:' | gpg2 --import-ownertrust
gpg: setting ownertrust to 5

The suffix ":5:" tagging the fingerprint indicates your full trust in the corresponding key; you can use :4: for marginal trust. Now GnuPG no longer harbors trust issues:

-> gpg2 --list-keys 'Fedora 29'
pub   rsa4096/A20AA56B429476B4 2018-02-17 [SCE]
      Key fingerprint = 5A03 B4DD 8254 ECA0 2FDA  1637 A20A A56B 4294 76B4
uid                 [  full  ] Fedora 29 (29) <[email protected]>

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.