Fedora Live

A Fedora Live image is an ISO image designed to boot and run a Fedora distribution from a USB flash drive or a DVD disc. Fedora Live runs on any host computer that supports booting from such media. Dual support for both a flash drive and an optical disc make the image a hybrid ISO image. Additionally, the host's firmware can be either BIOS or UEFI. These notes record details, extra details, and gratuitous details for putting a Fedora Live ISO image onto a USB flash drive or a DVD disc.

While these notes do apply generally to DVD discs, flash drives rule this roost. (I retired my DVD drive.)

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 public key for Fedora 37, in particular, to your GnuPG keyring. This key applies to all distributions (i.e., editions, spins, labs) of Fedora 37; use it even if you prefer a distribution other than the Xfce spin or the Workstation illustrated below.

Import

Download and import the current cumulative file of Fedora keys:

⮕ curl --silent https://getfedora.org/static/fedora.gpg | gpg2 --import
gpg: key 75CF5AC418B8E74C: public key "Fedora (39) <fedora-39-primary@fedoraproject.org>" imported
gpg: key 809A8D7CEB10B464: public key "Fedora (38) <fedora-38-primary@fedoraproject.org>" imported
gpg: key F55AD3FB5323552A: public key "Fedora (37) <fedora-37-primary@fedoraproject.org>" imported
gpg: key 999F7CBF38AB71F4: "Fedora (36) <fedora-36-primary@fedoraproject.org>" not changed
gpg: key DB4639719867C58F: "Fedora (35) <fedora-35-primary@fedoraproject.org>" not changed
gpg: key 7BB90722DBBDCF7C: "Fedora (iot 2019) <fedora-iot-2019@fedoraproject.org>" not changed
gpg: key 8A3872BF3228467C: "Fedora (epel9) <epel@fedoraproject.org>" not changed
gpg: key 21EA45AB2F86D6A1: "Fedora EPEL (8) <epel@fedoraproject.org>" not changed
gpg: key 6A2FAEA2352C64E5: "Fedora EPEL (7) <epel@fedoraproject.org>" not changed
gpg: Total number processed: 9
gpg:               imported: 3
gpg:              unchanged: 6

In this case, file fedora.gpg contains nine keys. Of these, three were just imported, for Fedora 37, Fedora 38, and Fedora 39. The remaining keys had been imported already and were left unchanged.

Your keyring now includes the desired key for Fedora 32:

⮕ gpg2 --list-keys 'Fedora (37)'
pub   rsa4096/F55AD3FB5323552A 2021-08-10 [SCE]
      Key fingerprint = ACB5 EE4E 831C 74BB 7C16  8D27 F55A D3FB 5323 552A
uid                 [ unknown] Fedora (37) 

The first line shows the key's main properties: This is a public key ("pub"); its encryption uses RSA with a length of 4096 bits ("rsa4096"); its ID is F55AD3FB5323552A; it was created on 2021-08-10; it can be used for signing, certification, and encryption ("[SCE]"). The second line gives the key's fingerprint; the fingerprint's last sixteen hexadecimal digits provide the key's ID in the first line. The third line reveals GnuPG's initial trust issues ("[unknown]") in this key; you'll reassure GnuPG in a moment.

Verify

Verify the key by visually comparing the fingerprint published by Fedora to the fingerprint reported by gpg. Find the published fingerprint under section Package signing keys / Here are our current keys:

ACB5 EE4E 831C 74BB 7C16 8D27 F55A D3FB 5323 552A copy-and-paste

And here is what GnuPG reports (as above):

⮕ gpg2 --fingerprint "Fedora (37)"
pub   rsa4096/F55AD3FB5323552A 2021-08-10 [SCE]
      Key fingerprint = ACB5 EE4E 831C 74BB 7C16  8D27 F55A D3FB 5323 552A
uid                 [ unknown] Fedora (37) <fedora-37-primary@fedoraproject.org>

Good: The two fingerprints of separate provenance match.

Sign

Sign the verified key:

⮕ gpg2 --sign-key "Fedora (37)"
⋮
Really sign? (y/N) y

Endorse

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

⮕ echo 'ACB5EE4E831C74BB7C168D27F55AD3FB5323552A:5:' | gpg2 --import-ownertrust
gpg: inserting ownertrust of 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 (37)'
pub   rsa4096/F55AD3FB5323552A 2021-08-10 [SCE]
      Key fingerprint = ACB5 EE4E 831C 74BB 7C16  8D27 F55A D3FB 5323 552A
uid                 [  full ] Fedora (37) 

Get and Verify Live ISO Image

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

Download the ISO image

Download the ISO image for the Fedora distribution of your liking from the Get Fedora (for Gnome Workstation), Fedora Spins, or Fedora Labs pages. Here the Fedora Xfce spin and the Workstation (Gnome) edition are retrieved for a 64-bit desktop. For the Xfce spin:

⮕ wget --continue https://download.fedoraproject.org/pub/fedora/linux/releases/37/Spins/x86_64/iso/Fedora-Xfce-Live-x86_64-37-1.7.iso
⋮

Or for the Workstation edition:

⮕ wget --continue https://download.fedoraproject.org/pub/fedora/linux/releases/37/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-37-1.7.iso
⋮

Or for the Security Lab:

⋮
⮕ wget --continue https://download.fedoraproject.org/pub/alt/releases/37/Labs/x86_64/iso/Fedora-Security-Live-x86_64-37-1.7.iso

The handy option --continue tells wget to resume an interrupted download from where it left off, should it get disturbed. Each command fetches an ISO image into the current directory.

Download the checksum file

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. Fedora Spins share a single checksum file:

⮕ wget https://getfedora.org/static/checksums/37/iso/Fedora-Spins-37-1.7-x86_64-CHECKSUM
⋮
⮕ grep '#' Fedora-Spins-37-1.7-x86_64-CHECKSUM 
# Fedora-Cinnamon-Live-x86_64-37-1.7.iso: 2366752768 bytes
# Fedora-KDE-Live-x86_64-37-1.7.iso: 2393667584 bytes
# Fedora-LXDE-Live-x86_64-37-1.7.iso: 1492944896 bytes
# Fedora-LXQt-Live-x86_64-37-1.7.iso: 1508005888 bytes
# Fedora-MATE_Compiz-Live-x86_64-37-1.7.iso: 2271160320 bytes
# Fedora-SoaS-Live-x86_64-37-1.7.iso: 1241606144 bytes
# Fedora-Xfce-Live-x86_64-37-1.7.iso: 1703366656 bytes
# Fedora-i3-Live-x86_64-37-1.7.iso: 1480536064 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. If you're keen for more insight, you can examine the file with your favorite text reader or editor, like less or Emacs.

The workstation ISO has its own checksum file:

⮕ wget https://getfedora.org/static/checksums/37/iso/Fedora-Workstation-37-1.7-x86_64-CHECKSUM
⋮
⮕ grep '#' Fedora-Workstation-37-1.7-x86_64-CHECKSUM 
# Fedora-Workstation-Live-x86_64-37-1.7.iso: 2037372928 bytes

And Fedora Labs share their own checksum file as well:

⮕ wget https://getfedora.org/static/checksums/37/iso/Fedora-Labs-37-1.7-x86_64-CHECKSUM
⋮
⮕ grep '#' Fedora-Labs-37-1.7-x86_64-CHECKSUM 
# Fedora-Astronomy_KDE-Live-x86_64-37-1.7.iso: 4851415040 bytes
⋮
# Fedora-Security-Live-x86_64-37-1.7.iso: 2199027712 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-37-1.7-x86_64-CHECKSUM
gpg: Signature made Thu 10 Nov 2022 02:53:53 PM EST
gpg:                using RSA key ACB5EE4E831C74BB7C168D27F55AD3FB5323552A
gpg: Good signature from "Fedora (37) " [full]
Primary key fingerprint: ACB5 EE4E 831C 74BB 7C16  8D27 F55A D3FB 5323 552A

And likewise for Fedora-Workstation-37-1.7-x86_64-CHECKSUM and Fedora-Labs-37-1.7-x86_64-CHECKSUM.

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-37-1.7-x86_64-CHECKSUM | sha256sum --check
Fedora-Xfce-Live-x86_64-37-1.7.iso: OK

That simple "OK" after the ISO file's name is the reassurance you're looking for. Here, grep extracts the relevant content for input to sha256sum. That is, it tells sha256sum to directly compute the digest for image file Fedora-Xfce-Live-x86_64-37-1.7.iso and then to verify this digest against the expected digest given in the checksum file.

The grep construct above avoids irrelevant warnings when sha256sum examines the checksum file in whole:

⮕ sha256sum --check Fedora-Spins-37-1.7-x86_64-CHECKSUM
sha256sum: Fedora-Cinnamon-Live-x86_64-37-1.7.iso: No such file or directory
Fedora-Cinnamon-Live-x86_64-37-1.7.iso: FAILED open or read
sha256sum: Fedora-KDE-Live-x86_64-37-1.7.iso: No such file or directory
Fedora-KDE-Live-x86_64-37-1.7.iso: FAILED open or read
sha256sum: Fedora-LXDE-Live-x86_64-37-1.7.iso: No such file or directory
Fedora-LXDE-Live-x86_64-37-1.7.iso: FAILED open or read
sha256sum: Fedora-LXQt-Live-x86_64-37-1.7.iso: No such file or directory
Fedora-LXQt-Live-x86_64-37-1.7.iso: FAILED open or read
sha256sum: Fedora-MATE_Compiz-Live-x86_64-37-1.7.iso: No such file or directory
Fedora-MATE_Compiz-Live-x86_64-37-1.7.iso: FAILED open or read
sha256sum: Fedora-SoaS-Live-x86_64-37-1.7.iso: No such file or directory
Fedora-SoaS-Live-x86_64-37-1.7.iso: FAILED open or read
Fedora-Xfce-Live-x86_64-37-1.7.iso: OK
sha256sum: Fedora-i3-Live-x86_64-37-1.7.iso: No such file or directory
Fedora-i3-Live-x86_64-37-1.7.iso: FAILED open or read
sha256sum: WARNING: 17 lines are improperly formatted
sha256sum: WARNING: 7 listed files could not be read

The files that sha256sum could not read ("No such file or directory") 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 there, either.

Checking other images is similar:

⮕ grep Live Fedora-Workstation-37-1.7-x86_64-CHECKSUM | sha256sum --check
Fedora-Workstation-Live-x86_64-37-1.7.iso: OK
⮕ grep Security Fedora-Labs-37-1.7-x86_64-CHECKSUM | sha256sum --check
Fedora-Security-Live-x86_64-37-1.7.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-37-1.7.iso
/boot
/EFI
/Fedora-Legal-README.txt
/images
/LICENSE
/LiveOS
⋮

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-37-1.7.iso /mnt -o loop,ro 
=> ls -R /mnt
/mnt:
boot  EFI  Fedora-Legal-README.txt  images  LICENSE  LiveOS
⋮
=> 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 significantly improved and is now the official, tested and supported way to make bootable media.

It is a simple GUI utility for putting a Fedora Live distribution 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 (as above).

To make a Fedora Live USB flash drive, open Fedora Media Writer from the Systems menu or run command mediawriter from a shell. From the scrolling menu, select the source distribution and the target USB flash drive.

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-37-1.7.iso
sector count: 831722, 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 (as user root):

=> dd if=Fedora-Xfce-Live-x86_64-37-1.7.iso of=/dev/sdd count=831722 bs=2048
831722+0 records in
831722+0 records out
1703366656 bytes (1.7 GB, 1.6 GiB) copied, 19.6915 s, 86.5 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:

⮕ isosize Fedora-Xfce-Live-x86_64-37-1.7.iso
1703366656

But see note below.

You can omit that sector bookkeeping if you like:

=> dd if=Fedora-Xfce-Live-x86_64-37-1.7.iso of=/dev/sdd
3326888+0 records in
3326888+0 records out
1703366656 bytes (1.7 GB, 1.6 GiB) copied, 26.2973 s, 64.8 MB/s

You may get some extra but ostensibly harmless sectors appended, however. Here, dd used its default block size of 512 bytes (1703366656 ÷ 3326888).

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 with a countdown timer. 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 your file manager: right-click on the ISO image; choose Open With; 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:

⮕ size=$(isosize Fedora-Xfce-Live-x86_64-37-1.7.iso); echo $size
1703366656
⮕ echo "scale=2;  $size / 1024^3" | bc
1.58
⮕ echo "scale=2;  $size / 1000^3" | bc
1.70

So, this image spans 1.58 GiB or 1.70 GB.

Direct-write does not support data persistence from boot to boot. Use Live CD Tools instead.

Create a Live USB Drive: Live CD Tools

You can also use livecd-iso-to-disk (package livecd-tools) from Live CD Tools to install a Fedora Live distribution from its ISO image onto a USB flash drive. Choose this method if any of these features appeals to you:

This tool offers two modes. The destructive mode formats the entire flash drive and thus obliterates any former contents. Option --format invokes this mode. 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. Non-destructive mode does claim title to directories EFI, images, LiveOS, and syslinux, to be created and modified as needed; hence this mode is mostly non-destructive. (See also --livedir.) Either way, the drive does not retain the ISO file system of its source image.

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

Basic Usage

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-31-1.9.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 distribution is then installed onto this partition.

⮕ ls /run/media/ray/LIVE/
EFI/  images/  LiveOS/  lost+found/  syslinux/

For EFI-savvy host, add option --efi:

=> livecd-iso-to-disk --noverify --resetmbr --format --efi Fedora-Xfce-Live-x86_64-31-1.9.iso /dev/sdd
⋮
Setting up /EFI/BOOT
⋮
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 distribution into the partition.

By default, the image of your distribution's root filesystem is compressed using SquashFS; i.e., /LiveOS/squashfs.img. Have a look:

⮕ cd /run/media/ray/LIVE/LiveOS
⮕ ls *.img
squashfs.img

⮕ unsquashfs -lls squashfs.img 
⋮
… squashfs-root
… squashfs-root/LiveOS
… squashfs-root/LiveOS/rootfs.img

⮕ du --human-readable squashfs.img 
1.3G	squashfs.img

When your LiveOS boots, it must decompress squashfs.img to recover the actual image; i.e., rootfs.img. If your USB drive has enough capacity, you can add option --skipcompress to instead copy the uncompressed image to the USB drive. The picture changes:

⮕ cd /run/media/ray/LIVE/LiveOS
⮕ ls *.img
rootfs.img

⮕ du --human-readable rootfs.img 
5.1G	rootfs.img

In this case, boot-up may be faster since the kernel can get at the root filesystem without the intercession of decompression. But beware if you intend to subsequently install Fedora to the host's disk: "Can't do live image installation unless running from a live image".

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 see what's inside of squashfs.img and rootfs.img in a two-step. First, mount squashfs.img as a loop device:

=> mkdir /tmp/squashfs
=> mount /run/media/ray/LIVE/LiveOS/squashfs.img /tmp/squashfs/ -o loop
=> ls -FR /tmp/squashfs/
/tmp/squashfs.img/:
LiveOS/

/tmp/squashfs.img/LiveOS:
rootfs.img

Next, mount /tmp/squasfs/rootfs.img as a loop device:

=> mkdir /tmp/rootfs
=> mount /tmp/squashfs/LiveOS/rootfs.img /tmp/rootfs -o loop
=> ls -F /tmp/rootfs/
bin@   dev/  home/  lib64@       media/  opt/   root/  sbin@  sys/  usr/
boot/  etc/  lib@   lost+found/  mnt/    proc/  run/   srv/   tmp/  var/

And that's the root filesystem of the LiveOS. Unmount in reverse order:

=> umount /tmp/rootfs
=> umount /tmp/squashfs

Presistent Storage

You can add persistent storage for system adjustments and user data you wish to retain from boot to boot.

Here's a simple way:

=> livecd-iso-to-disk --noverify --resetmbr --format --overlayfs \
Fedora-Xfce-Live-x86_64-31-1.9.iso /dev/sdd

This creates directory /LiveOS/overlay-LIVE--<UUID>, initially empty. The initial launch of the LiveOS then adds familiar directories; for example:

⮕ ls /run/media/ray/LIVE/LiveOS/overlay-LIVE-ce866f43-8a39-47ac-bb9f-2a299d63f209/
etc/  home/  root/  srv/  usr/  var/

The LiveOS overlays this mutable filesystem onto the distribution's read-only filesystem embedded in image file /LiveOS/rootfs.img, typically compressed into /LiveOS/squashfs.img. It stores subsequent changes to the base distribution within this directory, which is free to expand as needed. (Option --overlayfs also creates helper directory /LiveOS/ovlwork, which the overlay mechanism uses in working its magic. This directory does not store data.)

Alternatively, you can let the LiveOS modify rootfs.img to achieve persistence:

⮕ livecd-iso-to-disk --noverify --resetmbr --format --skipcompress --no-overlay \
Fedora-Xfce-Live-x86_64-31-1.9.iso /dev/sdd

The USB drive must be large enough to hold portly rootfs.img, here about 5.1 GiB, in lieu of svelte squashfs.img, here about 1.8 GiB. And it should have spare capacity sufficient to your storage needs, of course.

More...

=> livecd-iso-to-disk --noverify --resetmbr --format --overlay-size-mb 1024 \
Fedora-Xfce-Live-x86_64-31-1.9.iso /dev/sdd
⋮
Initializing persistent overlay...
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 39.4648 s, 27.2 MB/s
⋮

Here, option --overlay-size-mb creates file /LIVE/overlay-<UUID> (1 GiB), where the LiveOS stores changes to its root filesystem.

You can add a home directory you wish to retain from boot to boot:

⮕ livecd-iso-to-disk --noverify --resetmbr --format --home-size-mb 1024 --unencrypted-home \
Fedora-Xfce-Live-x86_64-31-1.9.iso /dev/sdd

Multiple Live Distributions

You can also use livecd-iso-to-disk to put multiple Fedora Live distributions on a single USB drive. This example puts the Xfce spin, Workstation (i.e., Gnome) edition, and LXQt spin on a single USB flash drive.

For the initial distribution, 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-31-1.9.iso /dev/sdd
⋮

This formats the drive as an MBR disk with a single Ext4 partition spanning most of the capacity. It creates and populates directories EFI, images, syslinux, and Xfce.

For additional distributions, 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-31-1.9.iso  /dev/sdd1
⋮
=> livecd-iso-to-disk --noverify --multi --livedir LXQt  Fedora-LXQt-Live-x86_64-31-1.9.iso         /dev/sdd1
⋮

Option --livedir names the directory for each distribution's files on the flash drive, so that these commands add directories Gnome and LXQt.

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

Go to LXQt ~Fedora-LXQt-Live 31 menu
Go to Gnome ~Fedora-Workstation-Live 31 menu
Start Fedora-Xfce-Live 31
Test this media & start Fedora-Xfce-Live 31

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-31-1.9.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.

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. 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 
1123481600
⮕ wc --bytes Fedora-Xfce-Live-x86_64-25-1.3.iso  
1124073472
stat --format "%s" Fedora-Xfce-Live-x86_64-25-1.3.iso
1124073472
⮕ echo '1124073472 - 1123481600' | bc
591872

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 digest the whole enchilada.

If you're a glutton for punishment, 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
934598656
⮕ echo $(($isosize / 512))
1825388
⮕ 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 virtual machine QEMU to launch Fedora Live from an ISO file, a USB flash drive, or an optical disc. The QEMU command to invoke depends on your computer's processor. Here, qemu-kvm does the job for an Intel i3 processor, which supports virtualization technology extensions (Intel VT); YMMV. How you specify the arguments to your QEMU command depends on what medium holds the LiveOS and on how the LiveOS 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.

A snappy way to preview a Fedora distribution is to have QEMU launch it directly from the Fedora Live ISO image you downloaded to your disk. This simple command does the job:

⮕ qemu-kvm -m 4G -cdrom Fedora-Xfce-Live-x86_64-37-1.7.iso

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

⮕ qemu-kvm -m 4G -drive file=Fedora-Xfce-Live-x86_64-37-1.7.iso,media=cdrom

But that's just for the record.

Left to its own volition, as above, QEMU emulates a BIOS-based computer. You can have QEMU instead emulate an EFI host by providing 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
efi.bin
⮕ qemu-kvm -m 4G -cdrom Fedora-Xfce-Live-x86_64-37-1.7.iso -bios efi.bin

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.)

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

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

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

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

You can launch Fedora Live from an actual optical disc in your computer's DVD drive, too, 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.

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
SKIPSECTORS = 15
RHLISOSTATUS=0
FRAGMENT SUMS = 41dbc1b8bbee45a73928ff6c596b95bcfa1128ffa24ce94cb6421b1d1a6f
FRAGMENT COUNT = 20
THIS IS NOT THE SAME AS RUNNING MD5SUM ON THIS ISO!

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