Netboot a Fedora Live CD

Live CDs are useful for many tasks such as:

  • installing the operating system to a hard drive
  • repairing a boot loader or performing other rescue-mode operations
  • providing a consistent and minimal environment for web browsing
  • …and much more.

As an alternative to using DVDs and USB drives to store your Live CD images, you can upload them to an iSCSI server where they will be less likely to get lost or damaged. This guide shows you how to load your Live CD images onto an iSCSI server and access them with the iPXE boot loader.

Download a Live CD Image

$ MY_RLSE=27
$ MY_LIVE=$(wget -q -O -$MY_RLSE/Workstation/x86_64/iso | perl -ne '/(Fedora[^ ]*?-Live-[^ ]*?\.iso)(?{print $^N})/;')
$ wget -O $MY_NAME.iso$MY_RLSE/Workstation/x86_64/iso/$MY_LIVE

The above commands download the Fedora-Workstation-Live-x86_64-27-1.6.iso Fedora Live image and save it as fc27.iso. Change the value of MY_RLSE to download other archived versions. Or you can browse to to download the latest Fedora live image. Versions prior to 21 used different naming conventions, and must be downloaded manually here. If you download a Live CD image manually, set the MY_NAME variable to the basename of the file without the extension. That way the commands in the following sections will reference the correct file.

Convert the Live CD Image

Use the livecd-iso-to-disk tool to convert the ISO file to a disk image and add the netroot parameter to the embedded kernel command line:

$ sudo dnf install -y livecd-tools
$ MY_SIZE=$(du -ms $MY_NAME.iso | cut -f 1)
$ dd if=/dev/zero of=$MY_NAME.img bs=1MiB count=0 seek=$(($MY_SIZE+512))
$ MY_RVRS=$(echo $MY_SRVR | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_SRVR})
$ MY_LOOP=$(sudo losetup --show --nooverlap --find $MY_NAME.img)
$ sudo livecd-iso-to-disk --format --extra-kernel-args netroot=iscsi:$MY_SRVR:::1:iqn.$MY_RVRS:$MY_NAME $MY_NAME.iso $MY_LOOP
$ sudo losetup -d $MY_LOOP

Upload the Live Image to your Server

Create a directory on your iSCSI server to store your live images and then upload your modified image to it.

For releases 21 and greater:

$ MY_FLDR=/images 
$ scp $MY_NAME.img $MY_SRVR:$MY_FLDR/

For releases prior to 21:

$ MY_FLDR=/images 
$ MY_LOOP=$(sudo losetup --show --nooverlap --find --partscan $MY_NAME.img)
$ sudo tune2fs -O ^has_journal ${MY_LOOP}p1
$ sudo e2fsck ${MY_LOOP}p1
$ sudo dd status=none if=${MY_LOOP}p1 | ssh $MY_SRVR "dd of=$MY_FLDR/$MY_NAME.img"
$ sudo losetup -d $MY_LOOP

Define the iSCSI Target

Run the following commands on your iSCSI server:

$ sudo -i 
# MY_NAME=fc27
# MY_FLDR=/images
# MY_SRVR=`hostname`
# MY_RVRS=$(echo $MY_SRVR | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_SRVR})
# cat << END > /etc/tgt/conf.d/$MY_NAME.conf
<target iqn.$MY_RVRS:$MY_NAME>
backing-store $MY_FLDR/$MY_NAME.img
readonly 1
allow-in-use yes
# tgt-admin --update ALL

Create a Bootable USB Drive

The iPXE boot loader has a sanboot command you can use to connect to and start the live images hosted on your iSCSI server. It can be compiled in many different formats. The format that works best depends on the type of hardware you’re running. As an example, the following instructions show how to chain load iPXE from syslinux on a USB drive.

First, download iPXE and build it in its lkrn format. This should be done as a normal user on a workstation:

$ sudo dnf install -y git 
$ git clone $HOME/ipxe
$ sudo dnf groupinstall -y "C Development Tools and Libraries"
$ cd $HOME/ipxe/src
$ make clean
$ make bin/ipxe.lkrn
$ cp bin/ipxe.lkrn /tmp

Next, prepare a USB drive with a MSDOS partition table and a FAT32 file system. The below commands assume that you have already connected the USB drive to be formatted. Be careful that you do not format the wrong drive!

$ sudo -i 
# dnf install -y parted util-linux dosfstools
# echo; find /dev/disk/by-id ! -regex '.*-part.*' -name 'usb-*' -exec readlink -f {} \; | xargs -i bash -c "parted -s {} unit MiB print | perl -0 -ne '/^Model: ([^(]*).*\n.*?([0-9]*MiB)/i && print \"Found: {} = \$2 \$1\n\"'"; echo; read -e -i "$(find /dev/disk/by-id ! -regex '.*-part.*' -name 'usb-*' -exec readlink -f {} \; -quit)" -p "Drive to format: " MY_USB
# umount $MY_USB?
# wipefs -a $MY_USB
# parted -s $MY_USB mklabel msdos mkpart primary fat32 1MiB 100% set 1 boot on
# mkfs -t vfat -F 32 ${MY_USB}1

Finally, install syslinux on the USB drive and configure it to chain load iPXE:

# dnf install -y syslinux-nonlinux 
# syslinux -i ${MY_USB}1
# dd if=/usr/share/syslinux/mbr.bin of=${MY_USB}
# MY_MNT=$(mktemp -d)
# mount ${MY_USB}1 $MY_MNT
# MY_NAME=fc27
# MY_RVRS=$(echo $MY_SRVR | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_SRVR})
# cat << END > $MY_MNT/syslinux.cfg
ui menu.c32
default $MY_NAME
timeout 100
menu title SYSLINUX
label $MY_NAME
menu label ${MY_NAME^^}
kernel ipxe.lkrn
append dhcp && sanboot iscsi:$MY_SRVR:::1:iqn.$MY_RVRS:$MY_NAME
# cp /usr/share/syslinux/menu.c32 $MY_MNT
# cp /usr/share/syslinux/libutil.c32 $MY_MNT
# cp /tmp/ipxe.lkrn $MY_MNT
# umount ${MY_USB}1

You should be able to use this same USB drive to netboot additional iSCSI targets simply by editing the syslinux.cfg file and adding additional menu entries.

This is just one method of loading iPXE. You could install syslinux directly on your workstation. Another option is to compile iPXE as an EFI executable and place it directly in your ESP. Yet another is to compile iPXE as a PXE loader and place it on your TFTP server to be referenced by DHCP. The best option depends on your environment.

Final Notes

  • You may want to add the –filename \EFI\BOOT\grubx64.efi parameter to the sanboot command if you compile iPXE in its EFI format.
  • It is possible to create custom live images. Refer to Creating and using live CD for more information.
  • It is possible to add the –overlay-size-mb and –home-size-mb parameters to the livecd-iso-to-disk command to create live images with persistent storage. However, if you have multiple concurrent users, you’ll need to set up your iSCSI server to manage separate per-user writeable overlays. This is similar to what was shown in the “How to Build a Netboot Server, Part 4” article.
  • The live images support a persistenthome option on their kernel command line (e.g. persistenthome=LABEL=HOME). Used together with CHAP-authenticated iSCSI targets, the persistenthome option provides an interesting alternative to NFS for centralized home directories.

Photo by Chris Yates on Unsplash.

For System Administrators


  1. svsv sarma

    I don’t see any advantage of the Net-boot with so much technical struggle, when a full fledged Fedora live DVD is handy. Perhaps I am a lay man or it is just for fun!

  2. Leslie Satenstein

    I have external backup drives. I copy the ISO’s to the external drive.
    I also have internal drives a through f.
    I often want to install a Linux ISO on one of the b through f drives.
    What would interest me as a topic woule be a demonstration of being able, while in my installed Fedora system, to:
    mount the Linux ISO,
    do a chroot or some other action to the ISO
    run the ISO’s boot and installation software.

    In otherwords, using a “” script or a “xyz” application program, do the above avoid installing the ISO copy to a flashdrive and then booting that flashdrive to perform the evaluation or installation of the desired Linux ISO

    I want to avoid copying the ISO to a USB flash drive and booting from that flashdrive.

    • Hi Leslie,

      Thank you for your article suggestion! We are always looking for new ideas.

      The 3 steps that you describe are essentially what happens “behind the scenes” when the following command is run:

      $ qemu-system-x86_64 -machine accel=kvm -m 1024M -drive format=raw,file=,cache=none,if=virtio -cdrom .iso -boot once=d

      Does that command satisfy your criteria? If so, it may be a bit too brief to do an article for. However, we might be able to make an article out of it if we provided more examples and variations of the command or made the article about QEMU and provided the above command as one example of its usage.

      Alternatively, if you wanted to replace the currently running OS with the one from the ISO, that might be doable with the kexec command.

      I’m not sure how reliable it would be to run anaconda from the installation disk without running (booting) the provided kernel if that is what you are wanting to do.

      I once had a situation where I wanted to keep an installation ISO on a secondary drive of a server and be able to reboot the server and do a full (re)installation of the OS on the primary drive remotely through the command line (the “command line” was routed to a separate server using a serial cable). That wasn’t too difficult. All I had to do was to copy the contents of the installation CD to a partition on the secondary drive and tweak the syslinux.cfg file by adding the line:

      serial 0 115200

      at the top and append “console=ttyS0,115200n8 nomodeset inst.text” to the kernel command line (I also made a few aesthetic tweaks to the syslinux.cfg file — numer of rows, helpmsgrow, etc.). I could then access (“chain load”) syslinux on the secondary drive by pressing “c” when grub came up and entering something like:

      chainloader +1

      I’m not sure if there would be much interest in a how to for something like that, but if several people reply requesting it, I could do a detailed write up about it.

      Anyway, I’ll write a “pitch” for a QEMU article if there isn’t already one in the magazine archives.

      Suggestions are welcome. Thanks!

      • Whoops, the editor butchered by reply. I always forget that things between angle brackets need to be escaped or they will get removed when I click “post comment”. That example command line should have been:

        $ qemu-system-x86_64 -machine accel=kvm -m 1024M -drive format=raw,file=<device node>,cache=none,if=virtio -cdrom <isoname>.iso -boot once=d

      • One caveat that I should note about using qemu to install an OS to a secondary drive is that if you subsequently try to boot your physical machine directly off of that drive, the hardware might not be detected properly because the initramfs will have been build against the “virtualized” hardware at installtion time. You should be able to work around that problem by selecting the “rescue” initramfs (it includes ALL drivers), and then running “dracut -f –regenerate-all” to rebuild the initramfs against the correct hardware.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions