When performing automated Fedora installations via USB, many administrators encounter a peculiar issue: the installation media partition containing the kickstart file becomes inaccessible during boot. This occurs because the installer automatically mounts the booted USB device, preventing subsequent access attempts.

The traditional approach of specifying ks=hd:sdb1:/ks.cfg fails because:

# Common error message observed
mount: /dev/sdb1 is already mounted or /run/install/tmpmnt0 busy
Warning: Can't get kickstart from /dev/sdb1:/ks.cfg

Method 1: Using LABEL or UUID

The most reliable solution is to avoid device names altogether and use filesystem identifiers:

# First, prepare your USB drive with a label
sudo mkfs.vfat -n FEDORA_KS /dev/sdb1

# Then use this boot parameter
linux ks=hd:LABEL=FEDORA_KS:/ks.cfg

Alternatively, with UUID:

# Find the UUID (assuming USB is /dev/sdb1)
sudo blkid /dev/sdb1

# Then use in boot parameters
linux ks=hd:UUID=1234-5678:/ks.cfg

Method 2: Embedding Kickstart in initrd

For ultimate reliability, embed the kickstart directly in the initramfs:

# On your build system
mkdir -p /tmp/ks
cp ks.cfg /tmp/ks/
cd /tmp
find ks | cpio -H newc -o | gzip -9 > /boot/ks.cpio.gz

# Modify boot parameters
linux initrd=initrd.img,ks.cpio.gz inst.ks=file:/ks.cfg

Method 3: Network Location Fallback

As a contingency, include a network fallback:

linux ks=hd:LABEL=FEDORA_KS:/ks.cfg ks=https://example.com/path/to/ks.cfg

For a production deployment using GRUB2:

menuentry 'Fedora Automated Install' {
    linux /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=FEDORA_KS \
          inst.ks=hd:LABEL=FEDORA_KS:/ks.cfg quiet
    initrd /images/pxeboot/initrd.img
}

After setting up your USB drive:

1. Boot into the installer debug shell (Ctrl+Alt+F2)
2. Verify device identification: blkid
3. Check mount points: mount | grep LABEL
4. Test file access: cat /run/install/ks.cfg

---

When attempting automated Fedora installations via kickstart from a USB drive, you'll encounter a mounting conflict when the installation media (USB) is the same device containing your kickstart file. The installer complains:

mount: /dev/sdb1 is already mounted or /run/install/tmpmnt0 busy
Warning: Can't get kickstart from /dev/sdb1:/ks.cfg

During boot, the installer mounts your USB device (typically as /dev/sdb1) to load the installation files. When you specify ks=hd:sdb1:/ks.cfg, the installer attempts to remount the same device - which is already actively mounted for the installation process.

Method 1: Using LABEL Instead of Device Path

The most reliable single-USB solution is to use filesystem labels:

linux ks=hd:LABEL=FEDORA_USB:/ks.cfg

Steps:

1. Format your USB with FAT32/NTFS/ext4
2. Set a filesystem label (e.g., FEDORA_USB) using:

   sudo dosfslabel /dev/sdX FEDORA_USB  # For FAT32
   sudo e2label /dev/sdX1 FEDORA_USB    # For ext4

3. Place ks.cfg at the root of the USB

Method 2: Embedding Kickstart in ISO

Modify the original ISO before creating USB:

# Mount original ISO
mkdir -p /mnt/iso
mount -o loop Fedora-XX.iso /mnt/iso

# Copy contents and add kickstart
mkdir /tmp/newiso
rsync -a /mnt/iso/ /tmp/newiso/
echo "# Your kickstart config" > /tmp/newiso/ks.cfg

# Update isolinux.cfg
sed -i 's/quiet/quiet ks=cdrom:/ks.cfg/' /tmp/newiso/isolinux/isolinux.cfg

# Create new ISO
mkisofs -o Fedora-XX-ks.iso -b isolinux/isolinux.bin \
  -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 \
  -boot-info-table -J -r /tmp/newiso

Method 3: Network-Based Kickstart

When USB solutions fail, fetch kickstart from HTTP:

linux ks=http://your.server/path/ks.cfg

Or from NFS:

linux ks=nfs:server:/path/to/ks.cfg

If issues persist, check:

• Device naming consistency with lsblk
• Filesystem labels with blkid
• Kickstart file permissions (should be world-readable)