You just downloaded the Fedora ISO and need a bootable USB
You downloaded the latest Fedora Workstation image, plugged in a blank USB drive, and opened a terminal. The desktop environment offers a graphical burner, but you prefer the command line. You know dd gets the job done, but you also know it has a reputation for wiping the wrong disk if you mistype a single letter. This guide covers exactly how to use dd safely, why each flag matters, and how to verify the drive actually boots before you test it on production hardware.
What's actually happening
The dd command does not understand filesystems, partitions, or bootloaders. It operates at the raw block level. When you point it at an ISO file and a block device, it reads the source file in fixed-size chunks and writes those exact bytes to the destination device. Think of it like a photocopier that scans a document at the pixel level. It copies everything. The partition table, the filesystem metadata, the boot sector, and the actual files. Because it bypasses the kernel's filesystem layer, it guarantees a bit-for-bit match. That is why it works for bootable media. It is also why you must be absolutely certain about the target device.
Modern Fedora ISOs are hybrid images. They contain a valid partition table and a bootable MBR or GPT header at the beginning of the file. When dd writes the ISO to a raw device, the USB controller reads that embedded partition table and presents the drive as a standard bootable disk to the BIOS or UEFI firmware. The command does not format the drive. It does not create partitions. It simply overwrites the existing block structure with the ISO's structure.
Understanding the difference between a device node and a partition node is essential. /dev/sdb refers to the entire physical USB stick. /dev/sdb1 refers to the first partition on that stick. Writing to /dev/sdb1 will only overwrite the partition. The partition table and boot sector will remain untouched. The drive will not boot. You must always target the raw device node.
Check your device tree before typing anything. Run lsblk and match the capacity to your USB drive. Never guess based on drive letter order. USB controllers and internal NVMe drives can swap identifiers between boots. Verify the size. Verify the model name. Confirm the target.
The fix
First, unmount any automatically mounted partitions. The kernel will refuse to write to a mounted block device. Your desktop environment likely mounted the drive the moment you plugged it in.
Here is how to release the filesystem lock before writing.
sudo umount /dev/sdX1
# Replace sdX1 with your actual partition name.
# Unmounting releases the kernel lock on the filesystem.
# dd will fail with a busy error if this step is skipped.
Now run the copy command. The flags control speed, feedback, and data integrity.
Here is the exact command to write the ISO to the raw device.
sudo dd if=fedora-42.iso of=/dev/sdX bs=4M status=progress oflag=sync
# if specifies the input file path.
# of specifies the raw block device, not a partition.
# bs sets the block size to 4 megabytes for faster throughput.
# status=progress prints a live transfer counter instead of silence.
# oflag=sync forces each write to flush to the physical media.
Wait for the percentage to hit 100. The command will return to the prompt when finished. Do not pull the drive yet. The Linux page cache still holds unwritten data. Force a flush and eject the drive cleanly.
Here is how to ensure all data hits the platter and safely remove the media.
sudo sync
# Tells the kernel to write all pending cache buffers to disk.
# Prevents partial writes that corrupt the boot sector.
sudo eject /dev/sdX
# Sends the SCSI eject command to the USB controller.
# Safely powers down the drive and unmounts any remaining locks.
The oflag=sync flag in the dd command handles most of the flushing work. It tells the kernel to wait for each block write to complete before reading the next block. Some administrators prefer conv=fsync instead. The difference is subtle. oflag=sync applies to the output file. conv=fsync applies to both input and output. For USB media, oflag=sync is sufficient and slightly faster. Use whichever you prefer, but never skip the final sync command. The page cache can still hold metadata updates after dd exits.
Run sync before you unplug. A missing flush is the most common cause of corrupted boot sectors.
Verify it worked
A successful dd run does not guarantee a bootable drive. The ISO might have been corrupted during download, or the USB controller might have dropped packets. Verify the partition type and filesystem signature before testing on hardware.
Here is how to check the filesystem signature on the newly written drive.
lsblk -f /dev/sdX
# Lists the device tree with filesystem types and labels.
# Look for iso9660 or ext4 on the first partition.
# A missing FSTYPE means the write failed or the ISO is damaged.
If the output shows iso9660 or ext4 with a label like FEDORA-LIVE-..., the structure is intact. You can also verify the exact bytes written by checking the first sector.
Here is how to inspect the boot sector signature directly.
sudo file -s /dev/sdX1
# Reads the raw partition and identifies the filesystem magic bytes.
# Returns ext4 or iso9660 if the hybrid header wrote correctly.
# Returns data or unknown if the drive is empty or corrupted.
Boot the drive on a test machine or in a virtualizer. If the GRUB menu appears and the live environment loads, the media is ready. If the system drops to a grub rescue> prompt or fails to detect the disk, the write process dropped blocks or the ISO checksum is invalid.
Check the filesystem signature before you reboot. A missing label means the drive is not ready.
Common pitfalls and what the error looks like
The most frequent mistake is targeting the wrong device. If you accidentally specify /dev/sda instead of /dev/sdb, dd will overwrite your primary system disk. The command will not ask for confirmation. It will simply begin copying. Always double-check the device name with lsblk before typing of=. Keep a second terminal open with lsblk running if you are unsure.
Another common issue is a mounted partition. If your desktop environment auto-mounted the USB drive, dd will refuse to write and print a device busy error.
dd: opening '/dev/sdb': Device or resource busy
Unmount the partition first. If the error persists, check for background processes holding the device open with lsof /dev/sdb. File managers, thumbnail generators, and indexing services often grab silent locks on removable media. Kill the offending process or reboot into a TTY before retrying.
You may also encounter a slow transfer that appears frozen. The default dd output is silent. Without status=progress, you will stare at a blank terminal for minutes. The bs=4M flag is also important. The default block size is 512 bytes. Copying a 4 gigabyte ISO at 512 bytes per operation takes an excessive amount of time. Increasing the block size aligns with modern USB controller buffers and dramatically improves throughput. Do not set bs higher than 16M. Some older USB 2.0 controllers fragment large buffers and actually slow down the transfer.
If the drive fails to boot after writing, verify the ISO checksum. Fedora provides SHA256 signatures for every release. A corrupted download will produce a bootable-looking drive that crashes at the GRUB stage. Run sha256sum fedora-42.iso and compare it to the official checksum file. Mismatched hashes mean you need to redownload the image. Never force a boot on a mismatched ISO. The installer will fail silently or corrupt the target disk.
Verify the hash before you burn. A bad download wastes your time and your USB drive.
When to use this vs alternatives
Different tools serve different workflows. Choose based on your specific needs.
Use dd when you need a raw, bit-for-bit copy of an ISO without installing extra software. Use cp when you are writing a hybrid ISO that supports standard block copy operations and want slightly faster performance on modern kernels. Use Ventoy when you maintain a single USB drive with multiple ISO files and want to select the boot target from a menu. Use fedora-media-writer when you prefer a graphical interface that handles verification and safe ejection automatically. Stay on dd if you are scripting the process or working on a headless server.
Trust the package manager for daily work. Use raw block tools only when you need exact control over the media.