Bug 271881

Floppies don't work anymore -- the size of the kernel alone is more than the
size of a floppy these days.  CDs or booting from USB are the only way to go.

Ok - not an option.
But for testing purposes what about the following

1. Copy the CD's isolinux directory to /boot/f8t1
# mount -o ro -o loop /opt/tests/Fedora-8-Test-1-KDE-Live-i686.iso /mnt/loop
# cp -fr /mnt/loop/isolinux /boot/f8t1

2. Add a Grub entry
title Fedora 8 Test 1
    root (hd0,0)
    kernel /f8t1/vmlinuz ro root=Fedora-8-Test-1-KDE-Live-i686 liveimg nocoaster
    initrd /f8t1/initrd-lvm.img

3. Create a modified initrd.img for LVM/local ISO image to handle "nocoaster"
/boot/f8t1/init-lvm.ing would be a modified version of /boot/f8t1/initrd.img
containing lvm (and lvm.static?) as well as a modified init script that did the
following
if [ "x$nocoaster" == "x1" ] ; then
    echo "********************************************************************"
    echo "********************************************************************"
    echo "******************************  NO  ********************************"
    echo "***************************** COASTER  *****************************"
    echo "********************************************************************"
    echo "********************************************************************"
    echo "Scanning logical volumes"
    lvm vgscan --ignorelockingfailure
    echo "Activating logical volumes"
    lvm vgchange -ay --ignorelockingfailure  VolGroup00
    mount -t ext3 -o ro /dev/VolGroup00/LogVol00 /localdrive
    rootfstype=iso9660
    mountoptions=-o loop -o ro
    thingtomount=/localdrive/opt/tests/Fedora-8-Test-1-KDE-Live-i686.iso
    mount -n -t $rootfstype $mountoptions $thingtomount /sysroot
    echo "Dropping to a shell. "
    echo "Check /localdrive and /sysroot and exit shell to continue. Good luck!"
    bash
else
    mount -n -t $rootfstype $mountoptions $thingtomount /sysroot
fi

You should be able to tell from the last mount statement where this goes.
I got this far by copying lvm from my current kernels initrd.img.

Unfortunately I got kicked into a bash prompt before this (learning curve) but
was at least able to run the two lvm lines.

lvm couldn't get logical volumes working - missing entry in /proc/misc - missing
kernel module?

I'm sure you can see where I'm going with this - should I clone this bug using a
new summary like
"Boot ISO image from local disk"?

Created attachment 184521 [details]
A modified version of initrd.img capable of handling "nocoaster"

Lots of changes to init and even etc/fstab to run an iso image from
/opt/tests/Fedora-8-Test-1-KDE-Live-i686.iso on /dev/VolGroup00/LogVol00, using
the above addition to grub.conf.

I added 'nocoaster check' to my grub.conf - the iso image checksummed OK.

I'm sure you could do better
 - option to unsquash iso.img locally
 - better ordering of my changes in init
 - script to provide an easier means to specify the ISO location and to
   automatically determine whether it resides on a logical volume.
 - easier means of generating initrd.img (in my case initrd-lvm.img)

Notes on Fedora 8 Test 1:
1. It's _slow_. I suspect this is squashfs at work - should offer unsquash.
2. Release notes seem to refer to Fedora 7.
3. Hyperlinks don't work on release notes.
4. kpowersave still crashes with alt-click/configure kpowersave(as it does in F7)

Using this approach in combination F8 'delta' images one could make a logical
volume 'sandwich' with the F8 test 1 image at the bottom, intervening delta
images successively above it and the sparse file on top.
This could really encourage widespread testing, but I think these deltas and F8
test 1 would have to be unsquashed.

While things like this can be hacked together, doing it right has to be such
that it doesn't depend on specific partitioning schemes, etc.  Which is going to
make it quite a bit harder and I don't know that it's really realistic. 
Especially as you have to be very careful mucking around with (potentially not
cleanly unmounted filesystems, or even ones that are actively hibernated).

If you want to keep working towards it, you can send patches to
fedora-livecd-list, but I have some serious reservations up-front and I don't
think that the complication is really going to be worth it.