Creating and Using a Live Installation Image

Chase Lau, ctrngk, The Fedora Docs Team Version unknown Last review: 2026-02-22

Downloading Fedora Linux

Download Fedora Linux from https://fedoraproject.org/.

Fedora Linux is freely available and comes in a number of different versions to meet different needs. If you are trying out Fedora Linux for the first time, the Workstation and KDE Plasma Editions are excellent choices for general-purpose desktop computing.

In addition to the flagship Editions, there are:

  • Atomic Desktops, which use modern technology to keep system files in a protected state.

  • Fedora Spins, which have a different look and feel and offer varying levels of customization.

  • Fedora Labs, which bundle software intended for specific use cases.

Visit https://fedoraproject.org/ for further information and to see all of the available options.

Creating a live USB flash drive with Fedora Media Writer

All data on the selected USB flash drive will be lost. Please relocate any important files to another location before proceeding.

Fedora Media Writer is the official and recommended tool for creating a Fedora Linux USB flash drive. You will need an internet connection and a USB flash drive with a capacity of at least 8 GB.

  1. Download and install Fedora Media Writer from https://fedoraproject.org/workstation/download/.

  2. Open Fedora Media Writer and ensure the correct USB flash drive is selected.

  3. Select "Download Automatically" or "Select .iso file" if you have previously downloaded a Fedora Linux image.

  4. Follow the prompts to select your preferred Fedora Linux option and begin writing the image to the USB flash drive.

Fedora Media Writer will automatically verify the download and check the image once it has been written to the USB flash drive. Your Fedora Linux live USB flash drive is now ready to use.

Restoring the USB flash drive

Once you have finished using your Fedora Linux live USB flash drive, you may want to use the USB flash drive to hold files again. Some operating systems may not recognize the USB flash drive until it is reformatted. For best results, use Fedora Media Writer to restore the USB flash drive so it can be used to store files.

Alternative methods for creating a live USB flash drive

Creating a live USB flash drive with the dd tool

The dd tool is installed by default on most Linux distributions, and on macOS.

The dd command results in a total loss of data on the destination drive. As such, special attention must be paid to selecting the correct destination drive. There is no option to 'undo' the action once the command has been completed.

All data on the selected USB flash drive will be lost. Please relocate any important files to another location before proceeding.

Part one - download and verify your Fedora Linux image

  1. Download your preferred version of Fedora Linux from https://fedoraproject.org/.

  2. Visit https://www.fedoraproject.org/security/ for instructions on verifying the integrity of the image.

Part two - positively identify your USB flash drive

  1. Unplug your USB flash drive.

  2. In the terminal, run:

    lsblk
  3. Plug your USB flash drive back into your device.

  4. Run lsblk again. The newly listed sdX device is your USB flash drive.

  5. You can cross-check your work by observing the output’s listed capacity for sdX, which should be consistent with your USB flash drive’s physical capacity.

Part three - prepare the drive and run the command

  1. Unmount the partition/s on the USB flash drive with:

      $ umount /dev/sdX
  2. Carefully construct the dd command. Example with breakdown listed:

    $ dd if=/path/to/Fedora-Workstation-Live.iso of=/dev/sdX bs=4M status=progress && sync
    • if=/path/... - Input file. Enter the exact path and file name.

    • of=/dev/sdX - Output file and the device it will write to. Replace X with the correct letter for your USB flash drive. Pause and double check your work here.

    • bs=4M - Block size of 4 megabytes. This value affects the total time to write as well as RAM usage (4M is recommended but not critical).

    • status=progress - Displays the estimated time to completion.

    • && sync - Flushes kernel buffers to the drive which reduces the risk of you removing the drive before the writing has been completed.

  3. Press enter and wait for the command to complete.

Your Fedora Linux Live USB flash drive is now ready to use.

If your version of dd doesn’t support the status=progress option, you may not see the write progress.

Other tools

Other tools that can be used to create a live USB flash drive include, but are not limited to, Gnome Disks, Unetbootin, Rufus, and balenaEtcher. Please refer to the respective tool’s documentation for instructions on their use.

Booting from USB sticks

Almost all modern PCs can boot from USB sticks. However, how you tell the system to boot from a USB stick varies substantially from system to system. Initially, you can try this:

  1. Power off the computer.

  2. Plug the USB drive into a USB port.

  3. Remove all other portable media, such as CDs, DVDs, floppy disks or other USB sticks.

  4. Power on the computer.

  5. If the computer is configured to automatically boot from the USB drive, you will see a screen that says "Automatic boot in 10 seconds…​" with a countdown.

    If you do a native UEFI boot, where you will see a rather more minimal boot menu.

If the computer starts to boot off the hard drive as normal, you’ll need to manually configure it to boot off the USB drive. Usually, that should work like this:

  1. Wait for a safe point to reboot.

  2. As the machine starts to reboot, watch carefully for instructions on which key to press. Usually a function key, Escape, Tab, F11, F12 or Delete is to be pressed to enter the boot device selection menu, BIOS setup, firmware, or UEFI. Press and hold that key. If you miss the window of opportunity, often only a few seconds, then reboot and try again. (If this does not work, consult the manual of your computer)

  3. Use the firmware, BIOS, interface or the boot device menu to put your USB drive first in the boot sequence. It might be listed as a hard drive rather than a removable drive. Each hardware manufacturer has a slightly different method for doing so.

    Your computer could become unbootable or lose functionality if you change any other settings. Though these settings can be reverted, you’ll need to remember what you changed in order to do so.
  4. Save the changes, exit, and the computer should boot from the USB drive.

If your system has a UEFI firmware, it will usually allow you to boot the stick in UEFI native mode or BIOS compatibility mode. If you boot in UEFI native mode and perform a Fedora installation, you will get a UEFI native Fedora installation. If you boot in BIOS compatibility mode and perform a Fedora installation, you will get a BIOS compatibility mode Fedora installation.

For more information on all this, see the UEFI page. USB sticks written from x86_64 images with Fedora Media Writer, GNOME Disk Utility, dd, other dd-style utilities should be UEFI native bootable. Sticks written with other utilities may not be UEFI native bootable, and sticks written from i686 images will never be UEFI bootable.

Identifying a stick on Linux

Most of the writing methods will require you to know the /dev name for your USB stick, e.g. /dev/sdc, when using them on Linux. You do not need to know this in order to use Fedora Media Writer. To find this out:

  1. Insert the USB stick into a USB port.

  2. Open a terminal and run dmesg.

  3. Near the end of the output, you will see something like:

    [32656.573467] sd 8:0:0:0: [sdX] Attached SCSI removable disk

    sdX will be sdb, sdc, sdd, etc.

This is the name of the disk you will use. We’ll call it sdX from now on. If you have connected more than one USB stick to the system, be careful that you identify the correct one, often you will see a manufacturer name or capacity in the output which you can use to make sure you identified the correct stick.

Troubleshooting a live USB

livecd-iso-to-disk problems

Partition isn’t marked bootable

If you get the message Partition isn’t marked bootable!, you need to mark the partition bootable. To do this, run parted /dev/sdX, and use the toggle N boot command, where X is the appropriate letter, and N is the partition number. For example:

$ parted /dev/sdb
GNU Parted 1.8.6
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Imation Flash Drive (scsi)
Disk /dev/sdX: 1062MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  1062MB  1062MB  primary  fat16

(parted) toggle 1 boot
(parted) print
Model: Imation Flash Drive (scsi)
Disk /dev/sdX: 1062MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      32.3kB  1062MB  1062MB  primary  fat16        boot

(parted) quit
Information: Don't forget to update /etc/fstab, if necessary.
Partitions need a filesystem label

If you get the message Need to have a filesystem label or UUID for your USB device, you need to label the partition: dosfslabel /dev/sdX LIVE.

Partition has different physical/logical endings

If you get this message from fdisk, you may need to reformat the flash drive when writing the image, by passing --format when writing the stick.

MBR appears to be blank

If your test boot reports a corrupted boot sector, or you get the message MBR appears to be blank., you need to install or reset the master boot record (MBR), by passing --reset-mbr when writing the stick.

livecd-iso-to-disk on other Linux distributions

livecd-iso-to-disk is not meant to be run from a non-Fedora system. Even if it happens to run and write a stick apparently successfully from some other distribution, the stick may well fail to boot. Use of livecd-iso-to-disk on any distribution other than Fedora is unsupported and not expected to work: please use an alternative method, such as Fedora Media Writer.

Testing a USB stick using qemu

You can test your stick using QEMU.

# umount /dev/sdX1
$ qemu -hda /dev/sdX -m 1024 -vga std

Mounting a Live USB filesystem

You can use the liveimage-mount script in the livecd-tools package to mount an attached Live USB device or other LiveOS image, such as an ISO or Live CD. This is convenient when you want to copy in or out some file from the LiveOS filesystem on a Live USB, or just examine the files in a Live ISO or Live CD.

Creating and using live CD

We will use Fedora release 42 exemplary in all command examples. If you need to do it for a different release, just change the number accordingly.

Getting started

To create a live image, the livecd-creator and mock packages are used. For this, super user privileges are needed.

The livecd-creator tool is part of the _livecd-tools_package. If it is not installed on your system, add it and all other tools like mock, lorax, git, pykickstart and a text editor with DNF:

# dnf install livecd-tools mock

Hint: We are creating a livecd like the fedora-live-workstation image, which is totally localized, but has english as default. There is no need to install any localization support on your own. You can change it in the created kickstart.cfg if necessary.

Configuring your system

We need to add you current user to the mock group, or you need to do anything as root user.

# sudo usermod -aG mock $(whoami)

The $(whoami) adds your current user, as we do not know what username you are currently using ;)

A relogin to make the change effective, would be wise, or you switch to root now.

Let’s create the mock group:

# newgrp mock

If you now enter:

# groups

it shall output your username together with the old groups and the new group "mock". If this is not the case, you did something wrong.

Creating your build environment

Now we can init the build environment. In this example we use the most likely x86_64, but if you build it for ARM or PowerPC, you can just use a different config by changing the ARCH-Type to the desired platform!

# mock -r /etc/mock/fedora-42_x86_64.cfg --init

Mock creates us an empty toolbox for this, so we need to fill it with packages, which we will need to create the image later in the process. If you now think "Why so complicated?" you are only partly right, as a toolbox is a simple container, which we need to separate the work for different releases of Fedora, otherwise you have to overwrite and mixing different builds on your own.

Make sure you have enough free disk space for all these files and the ones, the livemedia-creator will download later. We suggest at least 10 GB free diskspace for this.

# mock -r /etc/mock/fedora-42_x86_64.cfg --install lorax anaconda git pykickstart vim lorax anaconda git pykickstart vim libblockdev-lvm libblockdev-btrfs libblockdev-swap libblockdev-loop libblockdev-crypto libblockdev-dm libblockdev-mdraid libblockdev-part libblockdev-fs libblockdev-nvme libblockdev-mpath

If you wanne use a different texteditor then "vim", you need to install it now, otherwise you are stuck to a not so well integrated basic "vim" installation, which will be a bit unpleasant to use. Don’t panic, we don’t do much editing inside the toolbox, vim will do :)

Now we enter the toolbox for the first time …​

# mock -r /etc/mock/fedora-42_x86_64.cfg --shell --isolation=simple --enable-network

This gives us a shell and networksupport, so the scripts inside the toolbox can access the internet and install packages from the repo.

You will see something like this output:

INFO: mock.py version 6.3 starting (python version = 3.13.7, NVR = mock-6.3-1.fc42), args: /usr/libexec/mock/mock -r fedora-42-x86_64 --shell --isolation=simple --enable-network
Start(bootstrap): init plugins
INFO: selinux enabled
Finish(bootstrap): init plugins
Start: init plugins
INFO: selinux enabled
Finish: init plugins
INFO: Signal handler active
Start: run
Start(bootstrap): chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start(bootstrap): cleaning package manager metadata
Finish(bootstrap): cleaning package manager metadata
INFO: Package manager dnf5 detected and used (fallback)
Finish(bootstrap): chroot init
Start: chroot init
INFO: calling preinit hooks
INFO: enabled root cache
INFO: enabled package manager cache
Start: cleaning package manager metadata
Finish: cleaning package manager metadata
INFO: enabled HW Info plugin
INFO: Package manager dnf5 detected and used (direct choice)
Finish: chroot init
Start: shell
<mock-chroot> sh-5.2#

Now we need to download the kickstart files, which previous Fedora releases had as a package, from the Fedora Servers:

# git clone https://pagure.io/fedora-kickstarts -b f42

You can access the page with a normal browser, to see which tags aka 'branches' like "f42" are available, in case you wanne do another version. What happens now is a git checkout into the current directory of your toolbox. Big advantage: no danger of overwriting files on your os.

ATTENTION: before you continue, make sure you have at least 10 GB of free storage on your systems partition as we will download a lot of rpms and create an image that is at least 2,3 GB in size. If you don’t have enough space, all future steps can fail with the wildest error messages and your will waste A LOT of time with it!

What we now need is a kickstart file. Never heard of it, don’t panic :D

A kickstart file contains information about the size of the tmp drive in the later started live image, it mounts, its packages and so on. You will not need to reinvent the wheel, relax. Here is an example:

%include fedora-live-workstation.ks
%packages
# Packages we want to have
thunderbird
# Package groups excluded from @workstation-product-environment
-@guest-desktop-agents
-@libreoffice
-@multimedia
# Packages excluded from @workstation-product
-rhythmbox
-unoconv
# Packages excluded from @gnome-desktop
-gnome-boxes
-gnome-connections
-gnome-text-editor
-baobab
-cheese
-gnome-clocks
-gnome-logs
-gnome-maps
-gnome-photos
-gnome-remote-desktop
-gnome-weather
-orca
-rygel
-totem
%end

What you see is a subsection of all possible options, because that git checkout before, downloaded a full set of already working kickstart files, which we will join up to one new kickstart.cfg file.

The above file will remove packages and groups of packages from the later created image, compared to the normal Fedora-Live-Workstation image. We call this a DELTA-file, because we just define the differences between our image and the original Fedora Live Workstation image.

You see this:

%include fedora-live-workstation.ks

This includes the original kickstart (ks) config for the original Fedora-Live-Workstation Image as a base file. The rest of the lines "overwrite" the sections in the original file. So you just tell kickstart what you want and not want compared to the Fedora-Live-Workstation image.

Building the kickstart files

In this example, we removed some gnome-apps and end up what you know as "Fedora-Minimal-Workstation" Image.

Take that example and save it to a file you can name i.E. "example-START.ks". Make sure you can distinguish your file later as the starting point of your work. Because now, we will "join" aka. "flatten" the included files to one big kickstart.cfg file, that we will need for livemedia-creator later.

$ ksflatten -c as-you-like-START.ks -o kickstart.cfg

The problem you are now facing is, it doesn’t work out-of-box, because ksflatten does not find all the includes it needs. You can solve this in two ways:

a) you move your ks file to the directory named "fedora-kickstarts" and switch to it with cd, or

b) you execute the above command and copy all files it names in the errormessage from "fedora-kickstarts" to "." until it stops complaining.

From now on, you should only edit the created kickstart.cfg file for changes, otherwise you have to repeat the next step over and over again.

Fixing the "Mount"-bug

Either way, you end up with a defective cfg file, because the used include files define the mountpoint "/" two times, which lead to an error. That’s easily fixed:

# vim kickstart.cfg

search for "# Disk partitioning information" and change the two lines, that start with "part /" to this ONE line:

part / --fstype="ext4" --size=8576

We will try to fix this, but it could take until Fedora 45.

Creating the ISO

Now the part you are waiting for: Let’s create the iso image.

livemedia-creator --ks kickstart.cfg --no-virt --resultdir /var/lmc --project MYPROJECTNAME --make-iso --volid MY_ID --iso-only --iso-name <FILENAME>.iso --releasever 42 --macboot

Please replace the following terms:

"MYPROJECTNAME" That is your internal project name, that ends up in /etc/os-release "MY_ID" that is the name of the mounted ISO file AND VERY IMPORTANT if you wanne refer to that iso in GRUB "<FILENAME>" thats the name of the created iso file under /var/lmc

In approximitly 15 minutes, if everything works, you have a created <filename>.iso image IN YOUR TOOLBOX.

To get it out there, you enter …​

# exit

and copy it to the desired place. In example:

# cp /var/lib/mock/fedora-42-x86_64/root/var/lmc/<filename>.iso /home/themasteruser/Downloads/Images/

Now you can test your image in different ways:

a) you can use Gnome-Boxen to just run it in your desktop environment, which is way easier.

or

b) use the QEMU line in the next section.

Congratulations: You are done creating our own live-image. Some tips on the way:

  • If you need services running, check kickstart.cfg for syslive.service

  • If you want to drop-in config files for the services, you have to build your own rpm.

  • If you want to have your own packages inside the image, you need to add a custom repo. See "repo" in kickstart.cfg .

Testing your live CD using KVM or qemu

QEMU running Fedora 17

As root:

# qemu-kvm -m 2048 -vga qxl -cdrom filename.iso

If you do not have KVM support, you have to use qemu instead.

# qemu-system-x86_64 -m 2048 -vga qxl -cdrom filename.iso

Replace filename.iso with the name of your created Live CD image and qemu-system-x86_64 with an appropriate qemu binary for the target system, e.g. qemu-system-i386.

Live image media verification

The live image can incorporate functionality to verify itself. To do so, you need to have isomd5sum installed both on the system used for creating the image and installed into the image. This is so that the implantisomd5 and checkisomd5 utilities can be used. These utilities take advantage of embedding an md5sum into the application area of the iso9660 image. This then gets verified before mounting the real root filesystem.